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

"Выпуск операционной системы Redox OS 0.6, написанной на языке Rust "	+/–
Сообщение от opennews (??), 26-Дек-20, 11:54
После полутора лет разработки опубликован выпуск операционной системы Redox 0.6, разработанной с использованием языка Rust и концепции микроядра. Наработки проекта распространяются под свободной лицензией MIT. Для тестирования Redox OS  предложены готовые загрузочные образы (61 МБ). В отличие от прошлых выпусков, ветка 0.6 рассматривается как пригодная для экспериментов на реальном оборудовании, а не только в QEMU и VirtualBox... Подробнее: https://www.opennet.ru/opennews/art.shtml?num=54316
Ответить | Правка | Cообщить модератору

Сообщения

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

1. Сообщение от Аноним (1), 26-Дек-20, 11:54	+35 +/–
Великолепная ось на божественном языке!
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #3, #125, #275

2. Сообщение от Я (??), 26-Дек-20, 11:55	+6 +/–
Ждём нашествие растофобов
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #23, #59, #302

3. Сообщение от Аноним (3), 26-Дек-20, 11:56	+11 +/–
Фроктааааал!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #54

5. Сообщение от Аноним (5), 26-Дек-20, 11:58	–6 +/–
Вот бы кто-нить сказал зачем это нужно.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #11, #21, #47, #81, #127, #141, #218

6. Сообщение от Аноним (6), 26-Дек-20, 11:58	–1 +/–
Вот оно будущее! Уже сейчас.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #366

7. Сообщение от Аноним (7), 26-Дек-20, 12:01	+21 +/–
Её уже рассматривают как замену CentOS?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #106

8. Сообщение от Растобой (?), 26-Дек-20, 12:02	+2 +/–
Отличная новость.
Ответить | Правка | Наверх | Cообщить модератору

9. Сообщение от Аноним (9), 26-Дек-20, 12:04	+1 +/–
Как там дела с производительностью? Это наверное единственно что сейчас актуально. Далее можно обсудить фракталов и целесообразность выбора языка, раз он позволяет такие фракталы, можно будет посчитать статистику относительно конкурентов.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #24

10. Сообщение от Аноним (10), 26-Дек-20, 12:05	+1 +/–
зачем писать все? почему не сделать свое ядро и libc нормально, а потом переписывать остальное?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #13, #30

11. Сообщение от Alex (??), 26-Дек-20, 12:09	+12 +/–
А так непонятно? Для популяризации языка как языка системного уровня. Создания сообщества, стандартных библиотек, развития самого раста и т.д. Никто систему эту ставить на десктопы или серверы не будет. Сейчас это скорее как "я могу я сделаю!", чтобы позволить утвердится языку. А если получится что-то хорошее, через лет 5 возможно уже будет у кого-то основной ОС.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5 Ответы: #17, #32, #99, #112, #318

12. Сообщение от Аноним (12), 26-Дек-20, 12:10	–1 +/–
интересно сравнить с ReactOS, который давно и неспешно пилится на языке Си
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #61, #68, #145, #223

13. Сообщение от Аноним (9), 26-Дек-20, 12:10	–1 +/–
Может быть это не очевидно, но делать новое проще чем сделать нормально или исправить и доделать старое (это вообще не реально).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10 Ответы: #85

14. Сообщение от Ivanr (?), 26-Дек-20, 12:14	+1 +/–
Монолитные ядра быстрее. Если в микроядерной системе упадет планировщик процессов или файловая система или сетевой стек, что толку будет от работающего ядра?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #19

15. Сообщение от Аноним (15), 26-Дек-20, 12:18	–1 +/–
И открыт NetSurf (С) с SDL2 (С) backend'ом. Libc у них тоже на С?)
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #18, #20, #42

16. Сообщение от Enamel (ok), 26-Дек-20, 12:22	+4 +/–
Весьма бесполезная штука конечно, но как proof of concept низкоуровневой системности Хруста - маст хэв!
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #51

17. Сообщение от alex312 (?), 26-Дек-20, 12:22	+4 +/–
> А если получится что-то хорошее, через лет 5 возможно уже будет у кого-то основной ОС. Я конечно за раст, и все такое, но 5 лет до основной ОС - это фантастика. Что более реально за 5 лет - это как ОС в какой нибудь телек или другой умный гаджет. Что тем не менее будет офигенно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11 Ответы: #136

18. Сообщение от Аноним (18), 26-Дек-20, 12:24	+1 +/–
> NetSurf (С) с SDL2 (С) то есть их надо переписывать просто потому что ты сказал? они ОС пишут, а не всё-всё-всё, на всё-всё-всё пяти землекопов не хватит, даже если цель переписать будет > Libc у них тоже на С? на 35%, остальное на расте
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15

19. Сообщение от vaekahch (?), 26-Дек-20, 12:25	+/–
Микродро может их перезапустить, вспоминаем дедушку Таненбаума и Миникс его.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14 Ответы: #25

20. Сообщение от Аноним (20), 26-Дек-20, 12:25	+1 +/–
relibc is a portable POSIX C standard library written in Rust.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15 Ответы: #367

21. Сообщение от nomad__ (ok), 26-Дек-20, 12:34	+5 +/–
> Вот бы кто-нить сказал зачем это нужно. Чтобы было. Тебе жалко что ли? Ну так займись тем, что нужно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5

22. Сообщение от Аноним (22), 26-Дек-20, 12:34	+17 +/–
> Язык сфокусирован на безопасной работе с памятью, обеспечивает автоматическое управление памятью > В новой реализации удалось избавиться от утечек памяти
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #26, #27, #34, #39, #43, #70, #86, #139, #143

23. Сообщение от Аноним (23), 26-Дек-20, 12:39	–2 +/–
А std то на си почему-то написана. Ай-яй-яй. Ждём нашествия Си-фобов.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #44

24. Сообщение от Аноним (24), 26-Дек-20, 12:41	+1 +/–
На производительность микроядернвх ОС сильно влияют DAC, MAC. Пока их нет с производительностью все должно быть хорошо.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9

25. Сообщение от Аноним (23), 26-Дек-20, 12:41	–3 +/–
Только концепция дедушки как-то не прижилась и на то были причины.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19 Ответы: #36, #48, #347

26. Сообщение от Аноним (26), 26-Дек-20, 12:42	+/–
Да, такое бывает, год назад сделал утилиту мониторинга и оставил её работать на недельку-две. Результат конечно был забавный, но утилита вместо десятка мегабайт была за полгига. Полностью избежать всех утечек можно только на ручном управлении. Мне лично нравится rust, но топить за полную 100% безопасность и утечек памяти глупо, хотя некоторые вещи на этапе компиляции отлавливаются.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22 Ответы: #29, #37, #41

27. Сообщение от Аноним (23), 26-Дек-20, 12:42	+/–
С языка снял :^) Ну что, растофаноманы, чем будете отвечать?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22 Ответы: #40, #140, #239, #309, #361

28. Сообщение от Аноним (24), 26-Дек-20, 12:43	+/–
> верификация источника по цифровой подписи, контроль целостности, возможность повторяемой сборки, Годно.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #33

29. Сообщение от Аноним (23), 26-Дек-20, 12:44	–1 +/–
> Мне лично нравится rust, но топить за полную 100% безопасность и утечек памяти глупо, хотя некоторые вещи на этапе компиляции отлавливаются. Посему надо объявить раст устаревшим и выпив смузи, закурив это вейпом, идти писать свой нескучный язык, математически никак его не обосновывая, но говоря что он 100% безопастный и не повторяет ошибок C\C++ и Rust!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26 Ответы: #35, #195

30. Сообщение от Ordu (ok), 26-Дек-20, 12:47	+1 +/–
> зачем писать все? just for fun? > почему не сделать свое ядро и libc нормально, а потом переписывать остальное? А зачем это делать последовательно? Если бы эту Redox пилил бы один программист, то ему бы может и было бы удобнее делать последовательно. Но программистов больше одного, возможна параллелизация усилий, а раз так то удобнее заниматься всем сразу, чтобы друг у друга под ногами не болтаться.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10 Ответы: #55

31. Сообщение от uis (ok), 26-Дек-20, 12:47	–10 +/–
>Полностью переписана система управления памятью ядра (rmm, kernel memory manager). Когда некрофилу нечем заняться, он дристает >В новой реализации удалось избавиться от утечек памяти Никогда такого не было и вот опять. Так что там говорили про память? >Значительно доработана развиваемая проектом стандартная Си-библиотека Relibc, способная работать не только в Redox, но и в дистрибутивах на базе ядра Linux. И зачем им stdlib? Хотят без сей, пусть страдают без сей. А то биполярочка какая-то. >Напомним, что операционная система развивается в соответствии с философией Unix и заимствует некоторые идеи из SeL4, Minix и Plan 9. Redox использует концепцию микроядра, при котором на уровне ядра обеспечивается только взаимодействие между процессами и управление ресурсами, а вся остальная функциональность вынесена в библиотеки, которые могут использоваться как ядром, так и пользовательскими приложениями. Все драйверы выполняются в пространстве пользователя в изолированных sandbox-окружениях. Чем оно лучше GNU/HURD?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #49, #312

32. Сообщение от Аноним (32), 26-Дек-20, 12:47	–7 +/–
Если без написания ненужных ОС язык не может утвердиться, то это - ненужный язык. Иными словами - ненужный язык - это язык, от которого не зависит нужное ПО. К расту, к счастью, это не относится, на нём уже написаны тонны нужного ПО и один ненужный браузер-банкрот, который некому финансировать, потому что всем оплату рекламой и шпионажем подавай.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11

33. Сообщение от Аноним (24), 26-Дек-20, 12:49	+/–
https://gitlab.redox-os.org/redox-os/redox/-/jobs/31100/arti.../ А где подписи самих исошек?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28

34. Сообщение от Аноним (201), 26-Дек-20, 12:49	–2 +/–
Ну а чего ещё ожидать, когда неосиляторы, выбравшие себе язык с автоматическим управлением памятью, берутся писать менеджер памяти?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22

35. Сообщение от Аноним (26), 26-Дек-20, 12:50	+2 +/–
С тем же успехом можно хоронить Kotlin "патамушта" есть java Очень глупо объяснять людям, что разные языки под разные нужды. В расте действительно есть множество полезных инструментов, которые в С++ добавили только в 20 версии (и то, если не ошибаюсь, модулей туда не занесли) или их попросту нет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29 Ответы: #107, #149

36. Сообщение от Анонас (?), 26-Дек-20, 12:51	+6 +/–
> Эндрю Таненбаум, труды которого в своё время вдохновили Линуса Торвальдса на создание ядра Linux, опубликовал открытое письмо к компании Intel, в котором высказал благодарность за использование операционной системы MINIX в составе прошивки чипа Intel ME 11 (Management Engine). Intel ME 11 поставляется во всех современных ПК и ноутбуках с процессорами Intel, что делает MINIX наиболее широко используемой ОС в мире. + Google Fuchsia + Huawei HarmonyOS + QNX Я бы не сказал, что совсем уж не прижилась.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25 Ответы: #50, #80, #138

37. Сообщение от Аноним (201), 26-Дек-20, 12:52	+1 +/–
Ну вот это исключительно твоя попорукость, нечего её на rust сваливать. Или кривые unsafe, или копятся где-то указатели (которые "умные", в rust, вроде, за пределами unsafe других и нет).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26 Ответы: #46

38. Сообщение от Fracta1L (ok), 26-Дек-20, 12:55	+1 +/–
УРРРАААААААААААА
Ответить | Правка | Наверх | Cообщить модератору

39. Сообщение от Аноним (41), 26-Дек-20, 12:56	–1 +/–
И? Ни один язык не спасет от утечек, в частности языки с gc
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22

40. Сообщение от Аноним (41), 26-Дек-20, 12:57	+/–
Отсутствием сегфолтов каждый день разработки
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #27 Ответы: #115

41. Сообщение от Аноним (41), 26-Дек-20, 12:59	+1 +/–
> Полностью избежать всех утечек можно только на ручном управлении Это шутка такая?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26

42. Сообщение от Ordu (ok), 26-Дек-20, 13:02	+1 +/–
> Libc у них тоже на С?) libc сложно написать без C, потому что libc наполовину состоит из заголовков для C.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15 Ответы: #137

43. Сообщение от Аноним (43), 26-Дек-20, 13:02	+/–
Чуть погодя и уязвимоси латать будут.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22

44. Сообщение от Wilem82 (?), 26-Дек-20, 13:03	+3 +/–
Что такое std?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23 Ответы: #52, #104

46. Сообщение от Ordu (ok), 26-Дек-20, 13:14	+1 +/–
> Или кривые unsafe, или копятся где-то указатели (которые "умные", в rust, вроде, за пределами unsafe других и нет). rust не даёт гарантий насчёт утечек памяти. Откройте наконец документацию и почитайте её. std::mem::forget работает без всяких unsafe, и при этом позволяет создать утечку в полпинка:     {         let leak: Vec<u8> = Vec::with_capacity(1_000_000);         std::mem::forget(leak);     } Вот тебе и утечка мильона байт, потому как за пределами блока уже нет указателей на них. И, обрати внимание, ни одного unsafe. Есть и менее очевидные способы утечь память -- скажем Rc вполне это может делать, достаточно циклическую структуру собрать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37 Ответы: #151, #152, #300

47. Сообщение от Wilem82 (?), 26-Дек-20, 13:18	+3 +/–
В документации сказано: https://doc.redox-os.org/book/ch01-05-why-redox.html
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5

48. Сообщение от alex312 (?), 26-Дек-20, 13:20	+3 +/–
> ... были причины. именно что были. А сейчас куда не плюнь попадешь то в песоцницу, то в контейнер какой или вообще в виртуалку.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25

49. Сообщение от Wilem82 (?), 26-Дек-20, 13:26	+2 +/–
> И зачем им stdlib? Хотят без сей, пусть страдают без сей. А то биполярочка какая-то. Для поддержки программ, написанных под libc. Не на языке Си, а под libc. То есть для совместимости со старьём.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31 Ответы: #203

50. Сообщение от Аноним (50), 26-Дек-20, 13:29	–3 +/–
>Google Fuchsia Ещё не родилась, а уже сдохла >Huawei HarmonyOS Назло маме отморожу импортозамещение >QNX Сдохла вместе с Blackberry, несмотря на полтора мегаспецзакрытых девайса, которые её пытались пользовать. Примеры так себе, если честно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #36 Ответы: #75

51. Сообщение от 6аппппп (?), 26-Дек-20, 13:39	+1 +/–
> . В новой реализации удалось избавиться от утечек памяти, которые создавали проблемы при использовании старого менеджера памяти. Оно же не течёт???
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16 Ответы: #56

52. Сообщение от A.Stahl (ok), 26-Дек-20, 13:49	–114 +/–
Si table of dannye.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #44 Ответы: #283

53. Сообщение от Ted (?), 26-Дек-20, 13:52	–1 +/–
Почему у линуксоидов раздирает жопу под каждой новостью о других операционных системах: проприетарных, свободных, закрытых, открытых — всё равно. Вы — отбросы мира Open Source.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #63, #67

54. Сообщение от n00by (ok), 26-Дек-20, 13:56	+4 +/–
Он собирает шаблон "от утечек памяти".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #207

55. Сообщение от n00by (ok), 26-Дек-20, 14:05	+/–
А ей разве нужна libc? Насколько я понимаю, для самой ОС и базового окружения не нужна, только что бы сторонний софт (который на Си) запускать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #30 Ответы: #79, #222

56. Сообщение от n00by (ok), 26-Дек-20, 14:10	+/–
Это как с консервативными сборщиками мусора или обычной кучей. Они как бы не текут, но иногда память заканчивается, поскольку дефрагментировать не удаётся.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #51 Ответы: #113, #219

57. Сообщение от VINRARUS (ok), 26-Дек-20, 14:12	+2 +/–
Как пропатчить KDE 5 под Redox OS 0.6?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #153

58. Сообщение от Dzen Python (ok), 26-Дек-20, 14:13	–5 +/–
Ядро математически верифицировано? Значит есть дырени. В расте есть дырени! И кстати да, оно по прежнему тормозит или растанавты <двуличненько> разрешили использовать блоки unsafe? И как, много памяти натеклоу? В растовые дырени.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #64

59. Сообщение от Dzen Python (ok), 26-Дек-20, 14:15	–3 +/–
А что их ждать, если одного unsafe достаточно, чтобы похерить все крики растовцев о Безапашности(тм)? До сих пор помню, как затравили того автора, что для критических частей своего растового веб-сервера их заюзал (ради +150% к скорости) и огреб от токсичного растового коммунити.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #87, #144, #183, #235, #269, #298, #399

60. Сообщение от Аноним (60), 26-Дек-20, 14:16	–3 +/–
> В новой реализации удалось избавиться от утечек памяти - В Rust не может быть утечек памяти, - говорили они...
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #62, #74

61. Сообщение от Dzen Python (ok), 26-Дек-20, 14:20	+/–
...которая ограничена снаружи закостенелой мвязкой WinNTs + WinNTApi + Common WinAPI и спецификой проекта как свободного внешнего клона для запуска РЕ? Сравнивать надо бы с какой-нибудь сисярп-ос (как она там называлась?), где подобного нету, а так же встроен фреймворк, сборщик мусора, и менеджер модулей (не путать с пакетами для софта)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12

62. Сообщение от Dzen Python (ok), 26-Дек-20, 14:27	+3 +/–
Справедливости ради, даже в самом безопасном языке со встроенным GC может течь память. Иногда из-за неоптимальности стратегии сборки мусора. Иногда из-за того, что разрабы GC забыли обнулить где-то счетчик и пустые линки могут считаться как полноценный живой линк на память. Но в подавляющем большинстве случаев это все кривые руки кодеров, думающих что по выходу из блоки все их new() автоматом заdelete()'ит. Или просто играются самописными коллекциями, забывая обнуть неиспользуемое. Короче, тут даже самая совершенная связка язык-компилятор-сборщик потечет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #60 Ответы: #118, #122

63. Сообщение от Dzen Python (ok), 26-Дек-20, 14:31	+/–
Толстовато. Вернись обратно в свой загончик
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #53 Ответы: #65

64. Сообщение от ю (?), 26-Дек-20, 14:38	+10 +/–
питонист рассуждает о том что раст тормозит, забавно!)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #58 Ответы: #69

65. Сообщение от Ted (?), 26-Дек-20, 14:42	–1 +/–
Ну вот, типичный линаксоед.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #63 Ответы: #73

66. Сообщение от user90 (?), 26-Дек-20, 14:42	+/–
Ну чо, уже попробовали на "реальном оборудовании"?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #72

67. Сообщение от user90 (?), 26-Дек-20, 14:45	+/–
> у линуксоидов У комментаторов на Опеннете в смысле?))
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #53 Ответы: #76

68. Сообщение от Анончик99999 (?), 26-Дек-20, 14:50	–1 +/–
как там дела с беткой?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12

69. Сообщение от Dzen Python (ok), 26-Дек-20, 15:02	–4 +/–
Lewd. А ведь до сих пор процветает постановка диагноза по аватарке и вангование по нику.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #64 Ответы: #157

70. Сообщение от Мама Анонима (?), 26-Дек-20, 15:03	+/–
Утечка памяти — это логическая ошибка, от них тебя даже Раст не спасёт.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22 Ответы: #370

72. Сообщение от Аноним (41), 26-Дек-20, 15:04	+/–
А надо? Мне и Линукса хватает, пускай он уже и устаревшее легаси
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #66 Ответы: #78

73. Сообщение от Dzen Python (ok), 26-Дек-20, 15:04	+1 +/–
Тоньше надо быть, тоньше. Толстые набросы прекрасно работают в SJW-новостях, а не в чисто технической
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #65

74. Сообщение от Сишник (?), 26-Дек-20, 15:04	+6 +/–
> - В Rust не может быть утечек памяти, - говорили они... Кто говорил? Опять таблетки не пьёшь?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #60 Ответы: #131

75. Сообщение от Здрасьте (?), 26-Дек-20, 15:12	+3 +/–
QNX используется почти всеми ведущими производителями автомобилей.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #50 Ответы: #93, #108, #142, #276, #407

76. Сообщение от Ted (?), 26-Дек-20, 15:15	–1 +/–
>> у линуксоидов > У комментаторов на Опеннете в смысле?)) У больных сектантов, по каким-то причинам избравших линукс объектом своей фалометрии.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #67

78. Сообщение от user90 (?), 26-Дек-20, 15:23	–1 +/–
Мне - нет, это я у местных растома.. тьфу, растофанов спрашиваю)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #72 Ответы: #159

79. Сообщение от Ordu (ok), 26-Дек-20, 15:24	+/–
> А ей разве нужна libc? Насколько я понимаю, для самой ОС и > базового окружения не нужна, только что бы сторонний софт (который на > Си) запускать. Да. Чтобы сторонний софт запускать. Было бы обломно иметь OC и не иметь под неё браузера, IDE и всех прочих прелестей. Но сейчас всё равно рано о чём-то говорить, они, как я понимаю, usb hid так и не поддерживают, поэтому клавиатуры/мышки не работают. Разве что искать доисторическое железо с PS/2.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #55 Ответы: #128, #234

80. Сообщение от Dzen Python (ok), 26-Дек-20, 15:25	+1 +/–
> MINIX - ОС в составе *прошивки* [определенного набора ревизий, к которому можно сделать harend] чипа Intel ME 11. Прекрасно работает как firmware И как обучающее наглядное пособие из книги Танненбаума "Опыт Создания ОС или сказ о том, на какие грабли девелоперы уже наступили", на десктопе для общих задач неприменима. > QNX - RTOS для *прошивок*, Скорее мертва, по разработке. Прекрасно работает как firmware для требовательных железок, легко hardend'ится, но на десктопе для общих задач неприменима > Google Fuchsia - Пре-пре-пре-альфа концепт, о будущем которого гугл говорит, как  для firmware IoT и мобильных *потребительских устройств*, заменяя собой связку луникс+jwm. Позиционируется как неотъемлимая часть монолитного блоба прошивки, где рут есть только у сервисника и црушника (в этом фатальный недостаток ляликса - там рут получить сравнительно легко, приходится извращаться с бутлоадерами и А/В-разделами с постоянной проверкой чексумм всего и вся) > Huawei HarmonyOS - Пре-пре-пре-альфа концепт, о будущем которого хуавей говорит, как для firmware IoT и мобильных *потребительских устройств*, заменяя собой потенциально запрещенную к поставке торгово-экспортной комиссией штатов связку луникс+jwm. Позиционируется как неотъемлимая часть монолитного блоба прошивки, где рут есть только у сервисника и кагэбиста (оба члены КПК и ККА не ниже лейтенанта в звании) (в этом фатальный недостаток ляликса - там рут получить сравнительно легко, приходится извращаться с бутлоадерами и А/В-разделами с постоянной проверкой чексумм всего и вся) > GNU HURD + 100500 других микроядерных ОС - или свободная реплика миникса, или студенческие поделки без сферы применения. ------------------------- Все из них ИЛИ есть ранние proof-of-concept, ИЛИ имеют очень-очень узкую нишу и как правило, требуют заточки под железо. Макинтош не предлагать, там та же самая проблема с работой кекстов. ------------------------- Такое вот себе, не думаю, что имей микроядра прямо такие киллер-фичи перед гибридами или монолитами, то не имели бы они свою долю рынка.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #36 Ответы: #101, #173

81. Сообщение от Аноним (81), 26-Дек-20, 15:26	+/–
для убийства линукса
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5

85. Сообщение от alexrayne (?), 26-Дек-20, 15:47	–1 +/–
если бы это было так, то природа давно реализовала бы этот подход массово. Но нет, эволюция рулит.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13 Ответы: #90, #91, #92, #95

86. Сообщение от Аноним (20), 26-Дек-20, 15:52	+/–
А из-за чего они взялись?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22 Ответы: #371

87. Сообщение от банан (?), 26-Дек-20, 15:52	+3 +/–
Перед вами два стула, на одном производительность, а на другом - безопасность
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #59 Ответы: #103, #133, #193, #333

88. Сообщение от Аноним (20), 26-Дек-20, 15:53	–1 +/–
>В новой реализации удалось избавиться от утечек памяти, которые создавали проблемы при использовании старого менеджера памяти. А из-за чего появились утечки ведь в rust автоматическое управление памятью и встроенный статический анализатор.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #97, #184

89. Сообщение от Аноним (20), 26-Дек-20, 15:59	+/–
Каждая новость о программе на rust вызывает такой сильный пароксизм ненависти, что лучше просто запрещать комментарии сразу.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #100, #105, #163

90. Сообщение от Аноним (9), 26-Дек-20, 16:00	+3 +/–
Эволюция действует более широкими категориями, на больших временных периодах. Миллионы никому не нужных проектов умирают на разных стадиях завершённости, люди же десятилетиями используют и подпирают сотнями костылей очевидно хреновые решения без возможности их исправить, поскольку любое исправление потребует большой вовлечённости десятков и сотен квалифицированных индивидуумов.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #85

91. Сообщение от Аноним (91), 26-Дек-20, 16:03	+/–
есть такое понятие как эволюционный тупик, тогда природа делает несколько шагов назад к другой ветке которая изначально вроде казалась менее жизнеспособной
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #85 Ответы: #94

92. Сообщение от Аноним (9), 26-Дек-20, 16:05	–1 +/–
Вероятно даже точнее будет утверждать о многих тысячах и миллионах, рассматривая всю популяцию, поскольку придётся не только разработать и внедрить, но и убедить остальных, что это лучше и правильнее (а это возможно самое сложное).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #85

93. Сообщение от Аноним (91), 26-Дек-20, 16:05	+1 +/–
не разрушай его карточный домик
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #75

94. Сообщение от Аноним (9), 26-Дек-20, 16:06	–3 +/–
Я не вижу как это применимо к разработке ПО. У нас нет столько ресурсов и возможностей.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #91 Ответы: #155

95. Сообщение от еман (?), 26-Дек-20, 16:09	+2 +/–
на самом деле, природа это делает каждый раз, когда у одной матери появляется несколько детёнышей: такой себе природный форк, на случай если сиблинги зафейлятся.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #85

96. Сообщение от еман (?), 26-Дек-20, 16:14	–5 +/–
всё правильно делают: давно уже пора избавляться от этой сишной помойки но есть два замечания: 1. не URL, а URI 2. у URI есть одна проблема - это древовидная структура - такой подход уже показал свою негибкость по сравнению с теговой системой.
Ответить | Правка | Наверх | Cообщить модератору

97. Сообщение от Arsenicium album argentum asparagus (?), 26-Дек-20, 16:16	–2 +/–
В любом языке можно устроить утечку. Создать вектор размером в 999999999999 элементов и не удалять его до конца жизни программы. Компилятор не телепат, откуда ему знать, ошибка это или фича?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #88 Ответы: #116, #123, #241

99. Сообщение от Аноним (99), 26-Дек-20, 16:20	–3 +/–
Чтобы доказать что язык можно использовать в других системах, мы не будем его использовать в других системах, а создадим свою ненужную систему которой никто не будет пользоваться. Видимо целевая аудитория должна поверить на слово что если водород работает в дерижабле, то и в самолёте будет работать точно также.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11

100. Сообщение от Доктор Психиатор Котлетоватян (?), 26-Дек-20, 16:20	–1 +/–
Отрицание Гнев  <----- вы находитесь здесь Торг Депрессия Принятие
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #89 Ответы: #175, #375

101. Сообщение от Михрютка (ok), 26-Дек-20, 16:44	–7 +/–
картинка с профессором Преображенским и риторическим вопросом >>>не думаю, что имей микроядра прямо такие киллер-фичи перед гибридами или монолитами, то не имели бы они свою долю рынка. товарищ, скокатибелет? уже годам к 20 - 25 любому прямоходящему и регулярно занимающемуся высшей нервной деятельностью сапиенсу должно быть очевидно из опыта, данного ему в ощущениях, что киллер-фич для ПО есть всего три: 1. киллерфича просто скопировать 2. киллерфича недорого или нисколько стоить 3. киллерфича просто пользоваться на этих киллерфичах выросли микрософт, гугель, япель, линуксь и амозонт. все остальные киллерфичи - мнимые величины. гибриды-хрениды, монолиты-шмонолиты. это все, разумеется, для массового ни за что не отвечающего ПО. там, где подразумевается хоть какая-то ответственность типа выплат по страховке, наблюдаем внезапно куникс, как в автопроме. или аду, как в ввс сша.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #80 Ответы: #165

102. Сообщение от псевдонимус (?), 26-Дек-20, 16:48	+/–
Интересная система. Ее бы ещё на нормальном языке переписать. Ну там С, asm.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #111, #214

103. Сообщение от Аноним (103), 26-Дек-20, 16:50	+/–
Очень спорная аналогия с двумя стульями 😂😂😂
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #87 Ответы: #110

104. Сообщение от Михрютка (ok), 26-Дек-20, 16:54	+14 +/–
sexually transmitted disease
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #44 Ответы: #171

105. Сообщение от user90 (?), 26-Дек-20, 17:04	+2 +/–
Просто некоторые видели синтаксис этого ЯП, видимо хватило ;)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #89 Ответы: #114, #119, #132

106. Сообщение от Аноним (106), 26-Дек-20, 17:16	+3 +/–
нет, только для фуксии с гармонью
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7

107. Сообщение от Аноним (20), 26-Дек-20, 17:21	+/–
Только большая часть возможностей котлина будет в новой java. Имеет ли смысл котлин только из-за более копактного синтаксиса и @nonnull на уровне языка?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #35 Ответы: #150

108. Сообщение от Аноним (106), 26-Дек-20, 17:21	+/–
Да лана, в моей калине нет никакого куникса
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #75

109. Сообщение от borbacuca (ok), 26-Дек-20, 17:22	+/–
а как со скоростью генерации новых уязвимостей
Ответить | Правка | Наверх | Cообщить модератору

110. Сообщение от Урри (ok), 26-Дек-20, 17:22	–8 +/–
правильный ответ: сам сяду на производительность, а мать посажу себе на колени.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #103

111. Сообщение от Аноним (111), 26-Дек-20, 17:25	+/–
Лучше сразу ОС писатьй в байт кодах под конкретный процессор / конкретного вендора!! Это самый оптимальный путь для ОС
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #102 Ответы: #129

112. Сообщение от Урри (ok), 26-Дек-20, 17:25	+1 +/–
> А если получится что-то хорошее, через лет 5 возможно уже будет у кого-то основной ОС. И каждые полгода придется все переписывать наново, ввиду очередных ломающих совместимость изменений языка. >  Много времени при подготовке новой версии было потрачено на борьбу с нарушающими совместимость изменениями в ночных сборках Rust, связанными с переработкой макроса Asm.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11

113. Сообщение от Урри (ok), 26-Дек-20, 17:28	–6 +/–
Что ты там дефрагментировать в куче собрался, дефрагментатор мамкин?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #56 Ответы: #146, #148, #231

114. Сообщение от Аноним (20), 26-Дек-20, 17:29	–1 +/–
Вы не в состоянии выучить отличия одного си-подобного языка от другого?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #105 Ответы: #120, #278

115. Сообщение от Урри (ok), 26-Дек-20, 17:32	+3 +/–
Я уже который год пишу на С, мне за это даже денежки платят. И у меня нету сегфолтов, совсем, я уже забыл как они выглядят. Может просто надо хоть чуть-чуть научиться программировать и руки из _опы достать? А то повылазят всякие обезьяны, и ничего не изучая лезут в профессию.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #40 Ответы: #224, #236

116. Сообщение от Аноним (20), 26-Дек-20, 17:32	–1 +/–
Ваш пример это как сделать утечку специально Интересно было откуда они возникли конкретно в redox
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #97 Ответы: #198

118. Сообщение от Аноним (20), 26-Дек-20, 17:37	+/–
в java сборщик мусора может даже "острова изоляции" удалять, которые простой подсчет ссылок никогда не найдет. При этом в больших программах на java всё равно происходят утечки памяти, просто где-то случайно осталась ссылка объект и всё
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #62

119. Сообщение от SubGun (??), 26-Дек-20, 17:38	+/–
Ну всяко лучше питоновского
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #105 Ответы: #121

120. Сообщение от user90 (?), 26-Дек-20, 17:38	+2 +/–
> отличия Ога, незначительные такие)) И давайте-ка без всяких "си-подобных".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #114

121. Сообщение от user90 (?), 26-Дек-20, 17:41	+/–
А чего вдруг петон-то? Из-за попсовости? Такая аргументация - это уровень днища.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #119

122. Сообщение от Урри (ok), 26-Дек-20, 17:41	–1 +/–
> Справедливости ради, даже в самом безопасном языке со встроенным GC может течь память. Справедливости ради все же есть языки, где память не может течь в принципе. Чисто функциональные лиспы с GC не занимаются подсчетом ссылок и у них не может быть, ввиду парадигмы языка, циклических зависимостей. GC пробегает от корня, строит однонаправленное дерево живых объектов и быстро компактифицирует кучу. Не смотря на функциональность, эти языки вообще ничем не уступают всем остальным языкам, так как нужная мутабельность (если она действительно нужна) легко реализуется сопрограммами. Ну разве что надо научиться предварительно обдумывать программу, прежде чем начинать программировать. > Но в подавляющем большинстве случаев это все кривые руки кодеров Да, тут вы 100% правы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #62 Ответы: #189

123. Сообщение от Урри (ok), 26-Дек-20, 17:42	+/–
А что, раст уже перестал сам удалять неиспользуемое? Надо вручную это делать?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #97

124. Сообщение от Урри (ok), 26-Дек-20, 17:44	–3 +/–
Хороший язык, годный. Каждые два месяца ломающие синтаксис изменения.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #126, #134, #135

125. Сообщение от Урри (ok), 26-Дек-20, 17:45	+8 +/–
Божественный язык - это лисп. Не смейте называть вашу смузинедоделку божественным.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #130, #201

126. Сообщение от Мама Анонима (?), 26-Дек-20, 17:50	+/–
Примеры?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #124 Ответы: #378

127. Сообщение от лютый жабби__ (?), 26-Дек-20, 17:51	+/–
>сказал зачем это нужно. зря они распыляются на реальное железо. на сервере всё равно виртуализация в 99% случаев. для того чтобы стремительным домкратом всех подвинуть на серверах достаточно было бы написать 1 путний webсервер, 1 dns-сервер и 1 субд.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5

128. Сообщение от лютый жабби__ (?), 26-Дек-20, 17:55	–1 +/–
>Было бы обломно иметь OC и не иметь под неё браузера весьма тупо пилить микроядерную десктопную ось в условиях дикой конкуренции и непонимания 99.9% населения зачем дескпопной оси быть микроядерной. линух свой успех с серверов начал, похоже редокс убьет идиотский маркетинг, а жaль
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #79 Ответы: #147

129. Сообщение от псевдонимус (?), 26-Дек-20, 17:56	–1 +/–
Естественно лучше. К сожалению человеку слишком тяжело воспринимать байт-код. (
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #111 Ответы: #242

130. Сообщение от хацкер (ok), 26-Дек-20, 17:58	+1 +/–
Божественный язык -- машинный код.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #125 Ответы: #255

131. Сообщение от Аноним (144), 26-Дек-20, 18:11	+1 +/–
Утечки памяти являются безопасными по причине того что это НЕ НАРУШАЕТ ПАМЯТЬ ПРОГИ/ИНСТРУКЦИЙ, в расте это не запрещено. Если есть неопределенное поведение то это запрещено. Да и утекала память в их планировщике озу, там реализация не совсем от гарантий языка зависит...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #74 Ответы: #162, #204

132. Сообщение от Аноним (144), 26-Дек-20, 18:13	+/–
Синтаксис данного ЯП специально задумывался таким, для еще больших возможностей языка.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #105 Ответы: #161

133. Сообщение от Аноним (-), 26-Дек-20, 18:13	–1 +/–
А просто взять и написать производительно и безопасно уже нельзя, ну совсем никак ? Разгневаются боги хрустоманов...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #87

134. Сообщение от Аноним (144), 26-Дек-20, 18:15	–1 +/–
Да, действительно какие примеры? Что сломано то? Редакция 2018 года? или 2015? И вы вообще вкурсе редакций?? И то что код времен 2015 года компилируется и под редакцией современного 2018 без изменений?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #124

135. Сообщение от Аноним (143), 26-Дек-20, 18:15	+6 +/–
Всегда было любопытно: огромное множество удивительных баек про Rust на opennet - это целенаправленная кампания по дискредитации языка в неокрепших умах ридонли-анонимов, не способных самостоятельно проверять факты, или это просто какая-то локальная мифология, сотканная из сказок, которые анонимы тут друг другу рассказывают, а потом все вместе начинают в совокупность этих историй верить - этакое порождение коллективного невежества. Просто, если второе, то это довольно забавный социальный феномен: уверен, примерно так появлялись первые религии.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #124 Ответы: #160, #307, #379

136. Сообщение от Аноним (-), 26-Дек-20, 18:16	–6 +/–
Для этого им прийдется изучить нормальные языки программирования, чего не случится в ближайшие 5 лет, так что мечты
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17

137. Сообщение от Аноним (144), 26-Дек-20, 18:16	+1 +/–
Их libc является rust + c. Вызовы ядра просто на C, а все остальное покрыто безопасными обертками, кодом и все только на расте.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42 Ответы: #368

138. Сообщение от Аноним (144), 26-Дек-20, 18:18	+2 +/–
Хорошо что напомнили об этом. ``` 1 мая 2017 года корпорация Intel подтвердила и исправила в своей прошивке Management Engine[23] ошибку удаленного повышения привилегий (CVE-2017-5689), наличие которой давно предполагалось членами сообществ Coreboot и Libreboot[24][25]. Каждая платформа Intel с любой из технологий Intel Standard Manageability, Active Management Technology или Small Business Technology и с микроархитектурой центрального процессора от Nehalem (2008) до Kaby Lake (2017) содержит «дыру безопасности» с удаленным взломом в IME (Intel Management Engine)[26][27]. Ещё одним предполагаемым риском безопасности в IME является технология Intel vPro cellular radio[28], с помощью которой аппаратные компоненты могут быть доступны удаленно или компьютер может даже быть поврежден, однако нет никаких доказательств, что такая способность существует в самом чипе (vPro предназначен для использования службами внешних радиоустройств, отчего и пошел этот слух)[29]. ``` Источник https://ru.wikipedia.org/wiki/Libreboot
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #36

139. Сообщение от Аноним (144), 26-Дек-20, 18:21	–1 +/–
Еще раз, причемтут язык? Язык все свои гарантии дал. Здесь, нет ни std, ни какого рантайма. Вы его пишите взаимодействуя с небезопасным оборудованием. Чтобы на расте сделать безопасным тотже C надо писать безопасные обертки над структурами, памятью, вещами. Если обертки написаны хорошо то утечек (НЕ СО СТОРОНЫ ЯЗЫКА, а с СИ стороны) нет. И утечки не являются НЕ безопасной работой с памятью, уймитесь уже. Не безопасная работа с памятью вызывает неопределенное поведение, если утечка безопасна для всей проги то она является БЕЗОПАСНОЙ.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22

140. Сообщение от Аноним (144), 26-Дек-20, 18:22	–1 +/–
https://www.opennet.ru/openforum/vsluhforumID3/122777.html#139 вот.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #27

141. Сообщение от Аноним (141), 26-Дек-20, 18:22	–2 +/–
> Вот бы кто-нить сказал зачем это нужно. Исходя из https://doc.redox-os.org/book/ch01-05-why-redox.html этого: > There are numerous places in the MINIX 3 source code where we would like to make changes, > so many that perhaps a rewrite in Rust makes the most sense. Для того чтоб написать на хрусте.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5

142. Сообщение от Аноним (302), 26-Дек-20, 18:23	+1 +/–
В автопроме сейчас используется Automotive Grade Linux (AGL).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #75 Ответы: #256

143. Сообщение от Аноним (143), 26-Дек-20, 18:23	+2 +/–
Даже safe-семантика Rust не гарантирует защиту от утечек памяти, как не гарантирует остутствие дедлоков (хотя существенно снижает вероятность обеих ошибок). Ни утечка пямяти, ни дедлок не являются по своей сути нарушениями безопасности работы с памятью и не приводят к UB.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22 Ответы: #240, #373

144. Сообщение от Аноним (144), 26-Дек-20, 18:26	+4 +/–
Того автора затравили действительно из-за unsafe, но не от факта его наличия. А от того что данный unsafe ДЕЙСТВИТЕЛЬНО был не безопасен и автора за это чморили, а автор не мог быстро и красиво решить данную проблему без потери производительности. Как итог, автор свою проблему решил, с другим unsafe, другими вещами, а та уязвимость исправлена и производительность уже не 150% а гдето 140%:)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #59 Ответы: #421

145. Сообщение от Аноним (141), 26-Дек-20, 18:26	–1 +/–
> интересно сравнить с ReactOS, к Нельзя сравнивать, реакт пытается реализовать стандарты и быть совместимой. Суть редоха в нескучных сисколах, и этим все сказано.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12

146. Сообщение от Аноним (144), 26-Дек-20, 18:28	–1 +/–
Вы того? Не знаете как организуется память в оперативной памяти? Понятно, понятно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #113 Ответы: #315

147. Сообщение от Ordu (ok), 26-Дек-20, 18:29	+3 +/–
>>Было бы обломно иметь OC и не иметь под неё браузера > весьма тупо пилить микроядерную десктопную ось в условиях дикой конкуренции и непонимания > 99.9% населения зачем дескпопной оси быть микроядерной. Кому какое дело до 99.9%? > линух свой успех с серверов начал, похоже редокс убьет идиотский маркетинг, а жaль О каком маркетинге ты говоришь? Чтобы говорить о маркетинге, надо сначала заявить о каком-то преимуществе перед конкурентами. Какие преимущества редокс предлагает или мог бы предложить? Конкурировать с linux'ом на серверах? Хаха. С вендой на десктопах? Хахаха. С андройдом на мобилках? Это просто лол. Редоксу нет никакой потенциальной ниши, кроме крacнoглaзых фанатиков, типа меня. И он на эту нишу очень неплохо заточен. Я с радостью соскочу с linux'а, который давно превратился в корпоративное уг, чья сложность зашкаливает из-за того, что корпоративное уг и из-за того, что он во всех бочках затычкой пытается быть. Который написан на окаменелом C. Вокруг которого сформировалось дебильное сообщество 99.9%, которые разницу между микроядерностью и монолитностью понимают на основании неполных пересказов исторического cpaча между Торвальдсом и Танненбаумом, и при этом не отличают убунты от линукса, а высшим достижением считают способность собрать LFS (впрочем 99.9% из них никогда даже не пытались). Оставшиеся 0.01% -- это старпёры типа местного поха, которые давно линукс используют для зарабатывания денег, и любые изменения экосистемы для них PITA, потому что перечёркивает их знания и навыки доведённые до рефлексов. Я сегодня не хочу иметь ничего общего ни с линуксом, ни с его сообществом. Redox же -- позволяет уйти от C, используя его исключительно для легаси кода. Redox -- это не миллиарды строк кода, а гораздо меньше, разобраться в этом проще. Redox -- это дружелюбное сообщество. Просто няшка, ради которой можно потерпеть и отсутствующие драйвера. Я когда пришёл в linux, драйверов не было, и ничего, жил же как-то. Поживу и ещё.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #128 Ответы: #210, #211, #227, #321

148. Сообщение от Аноним (141), 26-Дек-20, 18:29	–3 +/–
Иногда надо запускать программы дефрагментации, чтоб память быстрее была. Там красные квадратики инода появляются, надо чтоб они были синие и желтых не должно быть, но это когда свежеотформатированная память .
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #113 Ответы: #170, #232

149. Сообщение от Аноним (144), 26-Дек-20, 18:30	+/–
Интересно под какие это другие вещи Kotlin был придуман?:) Если Kotlin появился ответом гугла на Oracle/(что там еще)Sun судебные тяжбы. И является именно ПСЕВДО заменой джавы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #35 Ответы: #168

150. Сообщение от Аноним (144), 26-Дек-20, 18:32	+/–
Да, @nonnull в джаве былобы очень кстати
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #107

151. Сообщение от Аноним (144), 26-Дек-20, 18:33	+/–
Вот именно, ваша утечка памяти является ПОЛНОСТЬЮ безопасной как для ПАМЯТИ так и для всей проги.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #46 Ответы: #158

152. Сообщение от Аноним (-), 26-Дек-20, 18:34	–2 +/–
> std::xxx Так это же проклятый C++ из-за которого горят дыры. Только истинный Rust !
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #46 Ответы: #154

153. Сообщение от Аноним (302), 26-Дек-20, 18:38	+1 +/–
Может, быстрее наоборот? Пропатчить Redox на C++ под KDE.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #57

154. Сообщение от Ordu (ok), 26-Дек-20, 18:41	+/–
>> std::xxx > Так это же проклятый C++ из-за которого горят дыры. Только истинный Rust > ! Чё? Где ты там увидел C++, родный?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #152 Ответы: #359

155. Сообщение от Аноним (91), 26-Дек-20, 18:43	+/–
возможностей не было 30 лет назад, сейчас программистов как собак не резанных, чем они все занимаются ? бабловыжиманием ? где тот энтузиазм создателя ? пока не проплатят то не пошевелим и пальцем для общего блага ?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #94 Ответы: #167, #196

156. Сообщение от Козлетто (?), 26-Дек-20, 18:43	+1 +/–
>В отличие от прошлых выпусков, ветка 0.6 рассматривается как пригодная для экспериментов на реальном оборудовании, а не только в QEMU и VirtualBox. Я вот попробовал его в virtualbox запустить, оно на "Redox Loader - Stage TWO 00000007#007F 0000:8A00" зависло. Уже минут 10 висит.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #164

157. Сообщение от Аноним (302), 26-Дек-20, 18:45	+/–
Ну вообще, да https://www.factorname.ru/index.php?option=content&task=view... :) PS К Python отношусь лояльно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #69

158. Сообщение от Ordu (ok), 26-Дек-20, 18:47	+1 +/–
> Вот именно, ваша утечка памяти является ПОЛНОСТЬЮ безопасной как для ПАМЯТИ так > и для всей проги. It depends... Всё зависит от того, как ты определяешь понятие safety. Rust определяет так, что утечка памяти не считается unsafe. И это не потому, что нет ничего плохого в утечке, и не потому, что разработчики раста не хотели обезопасить программиста от утечек памяти, а потому, что они не нашли способа обезопасить программиста от утечек памяти. И на фоне этого, мне не нравится твоя позиция, она мне напоминает позицию "зелен виноград": если раст не избавляет от утечек, значит утечки -- это хорошо. По Фрейду это рационализация, то есть целенаправленное искажение реальности с целью уложить факты в красивую картину мира. Картина мира в твоей голове не должна быть красивой, она должна максимально соответствовать миру.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #151 Ответы: #289

159. Сообщение от Аноним (302), 26-Дек-20, 18:51	+/–
Делаем ставки, что быстрее взлетит: ReactOS или Redox.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #78 Ответы: #205

160. Сообщение от Аноним (-), 26-Дек-20, 18:52	–1 +/–
А когда в очередной раз доказывают что хруст - помойка, все начинается с начала или правописания. Сам говоришь что об "адекватности" растофанов ходят басни и вские сказы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #135 Ответы: #215

161. Сообщение от Аноним (302), 26-Дек-20, 18:53	+1 +/–
Но тогда какие возможности у BrainFuck!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #132 Ответы: #306

162. Сообщение от Вы забыли заполнить поле Name (?), 26-Дек-20, 19:13	+/–
IRL, суровые мемлики заканчиваются для процесса фатально. Возможно "в тот самый момент", когда принудительная терминация закончится потерей данных. Мемлик в коре ОС, заканчивающийся терминацией, ну, вы поняли. Но у растаманов оно безопасно, угу.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #131 Ответы: #172

163. Сообщение от Вы забыли заполнить поле Name (?), 26-Дек-20, 19:15	+/–
> лучше просто запрещать комментарии сразу Или просто не постить эти новости, что будет куда меньшим неудобством.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #89

164. Сообщение от Вы забыли заполнить поле Name (?), 26-Дек-20, 19:16	–2 +/–
О боже, ассемблерщики от хруста - это химера...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #156

165. Сообщение от anonymous (??), 26-Дек-20, 19:17	–1 +/–
Сказать-то что хотел?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #101 Ответы: #169

166. Сообщение от Аноним (302), 26-Дек-20, 19:27	+/–
>Выпуск операционной системы Redox OS 0.6, написанной на языке Rust Придётся Мелкомягким ещё и WSR себе запилить ;)
Ответить | Правка | Наверх | Cообщить модератору

167. Сообщение от qwerty (??), 26-Дек-20, 19:28	–2 +/–
Капитализм, детка. Кровавый совок захотели? Дак вы не по адресу.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #155 Ответы: #226

168. Сообщение от qwerty (??), 26-Дек-20, 19:37	+/–
Kotlin детище JetBrains и очень сомнительно, что по заказу гугля.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #149

169. Сообщение от Михрютка (ok), 26-Дек-20, 19:37	–3 +/–
что ты букв не знаешь
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #165 Ответы: #277

170. Сообщение от Михрютка (ok), 26-Дек-20, 19:44	+/–
> быть, но это когда свежеотформатированная память . а это надо компьютер после выключения заземлять хотя бы минут 15 в выключенном состоянии, чтобы заряд из ячеек памяти как следует ушел, тогда форматировать не обязательно. у меня 16 гиг памяти, это часа два форматируется на ddr3, а если мемтестом форматировать, то еще дольше.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #148 Ответы: #250

171. Сообщение от Аноним (171), 26-Дек-20, 19:47	+4 +/–
Life?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #104

172. Сообщение от Михаил Анонима (?), 26-Дек-20, 20:03	+2 +/–
А ещё можешь себе яйца дверью нарочно прищемить, и Раст тебя от этого не защитит. Ужасный язык.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #162 Ответы: #174

173. Сообщение от Анон332 (?), 26-Дек-20, 20:05	+1 +/–
Недавно выпустили вторую версию DevKit HarmonyOS, саму операционную систему уже полностью показали, в Китае доступен закрытый бета тест, уже продают телевизоры с HarmonyOS на борту.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #80

174. Сообщение от Вы забыли заполнить поле Name (?), 26-Дек-20, 20:34	–4 +/–
Ваши растофетиши мне мало интересны, проделывайте это над собой сами.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #172

175. Сообщение от Аноним (175), 26-Дек-20, 20:40	+/–
Дохтур последний пункт - это не Принятие, а Безразличие.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #100 Ответы: #245

176. Сообщение от Аноним (176), 26-Дек-20, 20:43	–2 +/–
А почему при установке раст компилятора и его std либы месте аж больше 300 мегабайт занимает? Скомпилил хелоу ворлд, охренел - экзешник 11 мегабайт. Ещё компилятор думол полторы секунды, а gcc и g++ компилят моментально. Как так?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #179, #182, #191, #213

177. Сообщение от Аноним (175), 26-Дек-20, 20:44	–2 +/–
>Для совместимости с существующими приложениями предоставляется специальная POSIX-прослойка, позволяющая запускать многие программы без портирования. Можно поподробнее. Я ставлю Редокс, качаю *.deb файл и спокойно его запускаю? А штатные родные пакеты имеют какой суффикс?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #212, #258

178. Сообщение от Аноним (-), 26-Дек-20, 21:02	–1 +/–
>В новой реализации удалось избавиться от утечек памяти, которые создавали проблемы при использовании старого менеджера памяти. Фрактал! Зацени Растовые дырени!
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #216

179. Сообщение от анонн (ok), 26-Дек-20, 21:15	+/–
> Скомпилил хелоу ворлд, охренел - экзешник 11 мегабайт. > Ещё компилятор думол полторы секунды, а gcc и g++ компилят моментально. > Глянул на руки - кривоваты. > Как так? Кто ж его знает? $ cat hello_world.rs && time  rustc -O hello_world.rs &&  wc -c ./hello_world fn main() {                                                                         println!("Hello Wrot!"); } rustc -O hello_world.rs  0,26s user 0,11s system 140% cpu 0,262 total   392000 ./hello_world cat hello_world.rs && time rustc -C prefer-dynamic -O -C link-args=-s  hello_world.rs && wc -c ./hello_world fn main() {     println!("Hello Wrot!"); } $ rustc -C prefer-dynamic -O -C link-args=-s hello_world.rs  0,19s user 0,11s system 137% cpu 0,213 total     6592 ./hello_world $ time gcc -O2 hello.c gcc -O2 hello.c  0,09s user 0,03s system 87% cpu 0,138 total
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #176 Ответы: #186

181. Сообщение от qwertKI (ok), 26-Дек-20, 21:59	–3 +/–
...все прочитал ... х...ю мелете, ... бетка а все есть ... и все URL ... интересно ... интересно ... надо пробовать, набить шишек, поюзать ... х.з. пробую ...
Ответить | Правка | Наверх | Cообщить модератору

182. Сообщение от ю (?), 26-Дек-20, 22:20	+/–
статическая линковка + отладочная сборка по-умолчанию
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #176

183. Сообщение от Wilem82 (?), 26-Дек-20, 22:26	+5 +/–
> А что их ждать, если одного unsafe достаточно, чтобы похерить все крики растовцев о Безапашности(тм)? Ансейф отключает некоторые проверки, но не все. Кроме того, небольшую ансейфовую часть легче проверить, чем когда вся программа - ансейф.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #59 Ответы: #194

184. Сообщение от Wilem82 (?), 26-Дек-20, 22:33	+/–
> А из-за чего появились утечки ведь в rust автоматическое управление памятью и встроенный статический анализатор. Не знаю, но документация на std::mem::forget: > https://doc.rust-lang.org/std/mem/fn.forget.html#safety
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #88

185. Сообщение от Аноним (185), 26-Дек-20, 22:33	–3 +/–
"Полностью переписана система управления памятью ядра (rmm, kernel memory manager). В новой реализации удалось избавиться от утечек памяти, которые создавали проблемы при использовании старого менеджера памяти. Кроме того, повышена стабильность поддержки многоядерных систем. " я канэшна дико извиняюсь, Раст как раз для того и придумывали чтобы этих утечек не было в принципе - или я сильно ошибаюсь?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #190, #197

186. Сообщение от Wilem82 (?), 26-Дек-20, 22:43	+/–
Gcc меньше проверок делает, конечно он быстрее. Чем меньше программа делает, тем быстрее она работает. Тоже самое и с размером - бинари раста толще потому, что там больше кода который даёт больше фич, чем hello world на сях. Разматывание стека на панике с выводом где в коде была ошибка (типа жавовских стек трейсов), и тд. Кроме того, он содердит растовский libstd, в то время как сишные программы по-умолчанию не содержат, а линкуются с libc. Всё это можно отключить и сделать бинарь такого же размера, как на сях. Подробнее тут https://github.com/johnthagen/min-sized-rust Но лучше всего почитать блог где чел пишет операционку с нуля на расте, где всё это как раз отключается и показывается чё к чему: https://os.phil-opp.com/
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #179 Ответы: #187

187. Сообщение от анонн (ok), 26-Дек-20, 22:50	+1 +/–
> Gcc меньше проверок делает, конечно он быстрее. Чем меньше программа делает, тем > быстрее она работает. > Тоже самое и с размером - бинари раста толще потому, что Комментарий не читай, сразу бодро отвечай? >> 11 мегабайт. >> полторы секунды, > $ rustc -C prefer-dynamic -O -C link-args=-s hello_world.rs  0,19s user 0,11s system 137% cpu 0,213 total >    6592 ./hello_world > $ time gcc -O2 hello.c > gcc -O2 hello.c  0,09s user 0,03s system 87% cpu 0,138 total Выжимка: ___ > 6592 (6.5KB) ./hello_world (rust) > rustc 0,19s user 0,11s system 137% cpu 0,213 total > gcc 0,09s user 0,03s system 87% cpu 0,138 total --- В общем, вышеотписавшийся в 176 анонимный "критик" выставил себя еще тем "знатоком" ;)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #186 Ответы: #290

189. Сообщение от Вы забыли заполнить поле Name (?), 26-Дек-20, 22:56	+1 +/–
> Чисто функциональные лиспы с GC Можно пример?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #122

190. Сообщение от Аноним (191), 26-Дек-20, 23:09	–7 +/–
Ты все правильно говоришь Раст это маркетинговый булшит.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #185

191. Сообщение от Аноним (191), 26-Дек-20, 23:11	–2 +/–
ЗОтО безОпаснОсть!!!!11111
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #176 Ответы: #274

193. Сообщение от Аноним (193), 26-Дек-20, 23:22	+6 +/–
Возьму производительность и срублю безопасность
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #87

194. Сообщение от Dzen Python (ok), 26-Дек-20, 23:22	–2 +/–
Если так все просто и ансейф теперь не совсем ансейф и вообще, его легко проконтролировать блоком, то простой вопрос: почему была такая травля того кодера? Использование вполне аргументированно и, как тут ты красиво поёшь, вообще ничего не меняет, как комарик укусит, то что так много злобы на него вылилось?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #183 Ответы: #206

195. Сообщение от Аноним (193), 26-Дек-20, 23:29	+/–
Уже исть язык Pony, но там математически обосновано все
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29

196. Сообщение от Аноним (196), 26-Дек-20, 23:29	+/–
Пишут веб сайты же
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #155 Ответы: #209

197. Сообщение от Мама Анонимуса (?), 26-Дек-20, 23:32	+1 +/–
Ты сильно ошибаешься. https://doc.rust-lang.org/reference/behavior-not-considered-... https://doc.rust-lang.org/book/ch15-06-reference-cycles.html https://doc.rust-lang.org/nomicon/leaking.html
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #185 Ответы: #221

198. Сообщение от Аноним (198), 26-Дек-20, 23:33	+/–
Откуда ты знаешь, что специально?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #116

199. Сообщение от Аноним (185), 26-Дек-20, 23:39	+/–
и да - у меня на железе сабж не загрузился, видимо ржавое.
Ответить | Правка | Наверх | Cообщить модератору

201. Сообщение от Аноним (201), 26-Дек-20, 23:56	+1 +/–
> Божественный язык - это лисп. <ссылка на xkcd>
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #125

203. Сообщение от uis (ok), 27-Дек-20, 01:10	+/–
> Для поддержки программ, написанных под libc. Не на языке Си, а под libc. То есть для совместимости со старьём. "Написать под libc"? Так теперь называется использование стандартной библиотеки? И я знаю, что язык отдельно, stdlib отдельно, но прикладные программы напрямую syscall'ы не дёргают, аллокаторы тоже стандартные используют. man 7 libc
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #49 Ответы: #208

204. Сообщение от uis (ok), 27-Дек-20, 01:15	+/–
Растоманы не умеют в mmu или хотя-бы mpu?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #131 Ответы: #374

205. Сообщение от uis (ok), 27-Дек-20, 01:17	–1 +/–
Чернобыль
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #159

206. Сообщение от Qwerty123456 (?), 27-Дек-20, 01:20	+/–
Да примерно по тем же причинам, по которым ты тут троллить пытаешься. Кто-то ЧСВ повышал.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #194

207. Сообщение от InuYasha (??), 27-Дек-20, 01:23	+2 +/–
Я удивлён что не нашёл заветных слов "Новость прислал: Fracta1L" )
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #54 Ответы: #220

208. Сообщение от Wilem82 (?), 27-Дек-20, 01:34	+/–
> прикладные программы напрямую syscall'ы не дёргают Скорее всего, у редокса свой API для прикладных программ. В таком раскладе libc - это для совместимости с программами, написанными для API под названием libc.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #203

209. Сообщение от масло на хлебе (?), 27-Дек-20, 01:49	+/–
Пишут коменты
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #196

210. Сообщение от Аноним (210), 27-Дек-20, 02:48	–3 +/–
> Редоксу нет никакой потенциальной ниши, кроме крacнoглaзых фанатиков, типа меня. И он на эту нишу очень неплохо заточен. хммм... > Я сегодня не хочу иметь ничего общего ни с линуксом, ни с его сообществом. У вас противоречие тут закралось. Феномен фанатизма встречается именно и только лишь в рамках Linux и прочей религии вокруг него. Вам будет очень трудно найти такое в сообществах других ОС. Разве что только Apple... Ни BSD, ни даже Windows от такого не страдают. > Я с радостью соскочу с linux'а, который давно превратился в корпоративное уг, чья сложность зашкаливает из-за того, что корпоративное уг и из-за того, что он во всех бочках затычкой пытается быть. Справедливости ради, Linux очень плохо справляется со своей вновь приобретенной корпоративностью. Его сложность продиктована отсутствием стандартизации и автоматизации. То что в нем появилось - мало, а работает как попало, потому что нет архитектуры ОС. > Который написан на окаменелом C. А вот это одна из причин его убогости в корпоративном сегменте. Видите ли, корпоративный программист это такой человек, у которого все мысли и концепты объектно-ориентированы. Их речевой центр мозга превращает всё это не в звуковые сигналы, а сразу сериализирует в XML. Вместо рукопожатия используется SOAP Envelope. И вот у вас есть Linux написанный на С. Оно конечно годится для запуска JVM и даже свежего .NET 5, но работать с компонентами ОС. "Компонентами" сказал я, ха-ха. С зоопарком библиотек к которым надо линковаться без высокоуровнего API, если таковым не считать dbus, который фанатики не жалуют, да и сам он мягко говоря звёзд с неба не хватает. А еще люди на Linux на полном серьёзе пытаются писать софт на Python. Каждый раз переизобретая по 2-3 раза полурабочие биндинги к сишным либам для каждой версии своего несовместимого барахла. "Открытая система", блин. Когда куча софта в системе написана на питоне в котором маршалинг не происходит дальше локально установленного интерпретатора, а сериализация объектов не поддерживает нативно ни XML, ни даже JSON. Все через конвертацию и полный DOM. Зато есть либок 5-6 которые делают это наполовину и одинаково хреново. Своего SDK для С++ в Linux нет, если таковым не считать Qt, но вот только не понятно, зачем себя тогда через Linux наказывать... У Linux вообще нет SDK. И всё же главная проблема, которая сдерживает развитие unix-like ОС - это не столько С, сколько POSIX. Я в курсе что MS со своими WTF-16 помесями - это жесть, но setlocale... а какие там треды. А если setlocale и треды одновременно. И ACL, которые в нем не стандартизированы, но Linux их использует. Причем адепты культа реально уверены, что это стандарт. А на самом деле есть NT ACL - эксклюзивны для Windows. Псевдо-Posix ACL. Специфичные для Linux и то не обязательные. И есть NFSv4 ACL, которыми пользуются все остальные ОС. Из-за этого, кстати файлопомойку на Linux делают только дураки-фанатики. Я бы сообществу Rust пожелал от всей души не с С сражаться а с POSIX. Потому что эта штука не актуальна для разработки надёжного софта. Тут даже не столько в С дело. Вот подумайте сколько linux-программ на С обрабатывают ошибки malloc? Полтора землекопа? А со стороны ядра что при этом? Что-то адекватное возвращается. Нет. Memory overcommitment и потом полный OOM. И это воспитывает соответствующих программистов. Запросить 146GB памяти и форкнуться, а ОС потом разберется. А ОС она типа умная? Нет такая же. Методом тыка грохну что хочу. Но ведь можно костылик написать, переподнимем процесс, который убивается OOM-киллером. А лучше напишем питон-скриптик перепинывания, сборки деплоя и сразу в докер. Это еще и полностью решает проблему полного отсутствия setup.exe. Ведь не пользователь должен решать, какой у него софт, не разработчик, которые его написал, а меинтейнер. Самая важная вахтёрша, суть которой собирать и поставлять софт в ОС, в которой нет стандартизации и автоматизации для развертывания консьмерского софта и поэтому разработчики не собирают одну программу под 500 несовместимых на пустом месте дистров, которые ломают совместимость с самими собой со следующим мажорным апдейтом. И вот вахтёрша решит, как правильно доставлять твой софт до пользователя и еще откажется это делать, потому что фильтрует софт по религиозно-лицензионным признакам. В корпоративной среде нужно еще свою вахтершу содержать для таких задач. Она думает о себе как об инженере, а на самом деле эникей по линуксу. Ой всё... я 15 лет это жрал. Просто уже подросло новое поколение фанбоев, а воз и ныне там.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #147 Ответы: #265

211. Сообщение от Аноньимъ (ok), 27-Дек-20, 03:19	+/–
Добра :3
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #147

212. Сообщение от Anonimowy cz322owiek (?), 27-Дек-20, 05:29	+/–
.deb это не про POSIX. Это ж формат пакета, для .deb надобно ещё dpkg запускать, ну сами понимаете. А позикс - это про API для программ
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #177

213. Сообщение от Anonimowy cz322owiek (?), 27-Дек-20, 05:36	+/–
Там надо для боевого компилинга включить оптимизации и выключить отладочные фигулины. И будет норм. По умолчанию там дебажно без оптов
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #176

214. Сообщение от Аноним (41), 27-Дек-20, 06:23	+/–
Ты не умеешь в юмор, извини
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #102 Ответы: #217

215. Сообщение от Аноним (41), 27-Дек-20, 06:24	+/–
Естественно хруст помойка, но с ж ещё хуже
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #160

216. Сообщение от Аноним (41), 27-Дек-20, 06:27	+/–
Главный прикол в том, что растовые дырени на опеннете - ажиотаж и небывальщина, что как бы намекает ;)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #178

217. Сообщение от псевдонимус (?), 27-Дек-20, 07:13	+/–
Я на полном серьёзе. А если ты про сраст, то если он и юмор, то черный. Черней пердона.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #214 Ответы: #328

218. Сообщение от powerc (??), 27-Дек-20, 08:01	+/–
для чего вообще все существует в этой реальности?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5

219. Сообщение от Аноним (219), 27-Дек-20, 08:05	+/–
это как болячка у Linux - когда оно вызывает такой дефрагментатор?.. только его завуалировано назвали компактофикатор...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #56 Ответы: #229

220. Сообщение от заминированный тапок (ok), 27-Дек-20, 08:07	+10 +/–
при чём даже новость написал бы на Расте, тк тест на русском языке может содержать ошибки
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #207

221. Сообщение от Аноним (-), 27-Дек-20, 08:25	–3 +/–
Ты нам показал, что на Расте возможны утечки. Хорошо. Но на какой такой чёрт растаманы чмырят ЯП Си за дырени и утечки. Бревно в своём глазу не видят, а соломинку в чужок глазу видят. И тут я вспомнил слова Кена Томпсона, о том, что "Си не может быть опасным или безопастным". Сама постановка вопроса не правильная. Всё зависит от программиста. Много программистов не умеют грамотно писать на чистом Си, и при возниконовении утечок или ошибок они и их окружение проклинают чистый Си. Но ведь Си тут не причём, эта рука программиста растёт из жопы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #197 Ответы: #238, #246, #340, #350

222. Сообщение от Wilem82 (?), 27-Дек-20, 08:52	+/–
> только что бы сторонний софт (который на Си) запускать Не который на Си, а который подгружает libc и делает вызовы к его фукнциям. Это можно сделать на любом языке, который умеет C ABI FFI.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #55 Ответы: #233, #334

223. Сообщение от powerc (??), 27-Дек-20, 08:54	+2 +/–
интереснее с haiku os например
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12

224. Сообщение от Wilem82 (?), 27-Дек-20, 09:00	+1 +/–
> Я уже который год пишу на С, мне за это даже денежки платят. И у меня нету сегфолтов, совсем, я уже забыл как они выглядят. https://www.cvedetails.com/vulnerability-list/vendor_id-33/p... Лично ты никого не интересуешь, интересует сишный софт который так или иначе дырявый. Дыры находят постоянно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #115

226. Сообщение от Соляридзе (?), 27-Дек-20, 09:10	–1 +/–
Да совок в любом случае говно
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #167

227. Сообщение от Аноним (227), 27-Дек-20, 09:13	–1 +/–
Если там будет нормальный GUI и жрать будет ресурсов хотя бы как WIN XP, то в пекло все эти разжиревшие Линуксы в которых без командной строки работать практически невозможно. А вообще тут все переходят на ARM и если ребята впишутся в этот переход могут солидную долю рынка у Мелкософта отжать. Ну и без мобильной версии тоже никак.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #147

229. Сообщение от n00by (ok), 27-Дек-20, 09:33	+/–
> это как болячка у Linux - когда оно вызывает такой дефрагментатор?.. Кто "оно"? > только > его завуалировано назвали компактофикатор... "Компакт" подразумевает перемещение блоков, что не всегда возможно (поскольку требует коррекции ссылок). Это не единственная стратегия дефрагментации. Если моменты освобождения смежных блоков детерминированы, возможно обеспечить выделение памяти с учётом того, что при освобождении блоков произойдёт слияние свободного места.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #219

231. Сообщение от n00by (ok), 27-Дек-20, 09:39	+/–
> Что ты там дефрагментировать в куче собрался, дефрагментатор мамкин? На фоне слов "консервативный сборщик мусора" и "дефрагментация", как правило, появляется мысль о варианте mark-and-compact, но иногда только о поколениях.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #113

232. Сообщение от n00by (ok), 27-Дек-20, 09:49	+2 +/–
> Иногда надо запускать программы дефрагментации, чтоб память быстрее была. Вы ткнули пальцем в небо и угадали. Копирующий сборщик мусора за счёт расположения логически близких блоков в одной линейке кеша может дать выигрыш по скорости по сравнению с консервативным.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #148

233. Сообщение от n00by (ok), 27-Дек-20, 09:52	+/–
>> только что бы сторонний софт (который на Си) запускать > Не который на Си, а который подгружает libc и делает вызовы к > его фукнциям. Это можно сделать на любом языке, который умеет C > ABI FFI. Вы готовы показать ссылку на проект "который подгружает libc", а не слинкован с ней статически, поскольку у того "любого языка" рантайм написан на Си?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #222 Ответы: #337

234. Сообщение от n00by (ok), 27-Дек-20, 09:59	+/–
>> А ей разве нужна libc? Насколько я понимаю, для самой ОС и >> базового окружения не нужна, только что бы сторонний софт (который на >> Си) запускать. > Да. Чтобы сторонний софт запускать. Было бы обломно иметь OC и не > иметь под неё браузера, IDE и всех прочих прелестей. Но сейчас > всё равно рано о чём-то говорить, они, как я понимаю, usb > hid так и не поддерживают, поэтому клавиатуры/мышки не работают. Значит они всё правильно делают. Кто-то пишет ядро, потому что может. Кто-то занимается прослойками совместимости с существующим софтом, а в ядро не лезет раньше времени. > Разве что > искать доисторическое железо с PS/2. Есть и новое такое. Но там, вероятно, и остальное поддерживается примерно на том уровне.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #79 Ответы: #257

235. Сообщение от red75prim (?), 27-Дек-20, 09:59	+/–
> До сих пор помню, как затравили того автора А помните как Боинг затравили за 737MAX? Такая-же история: не будем ставить индикатор рассогласования датчиков углов атаки - напишем в инструкции как распознать ситуацию, пилоты умные, справятся. Так и тут. Не буду ставить unsafe - умные программисты, которые будут дорабатывать мой код, определят нужные прекондишны без всяких unsafe и не будут стрелять в ногу пользователям.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #59 Ответы: #262

236. Сообщение от red75prim (?), 27-Дек-20, 10:11	+/–
Что и silent memory corruption и потенциальных buffer overrun и double free нет? Фаззер, ASAN, UBSAN, TSAN, MSAN когда последний раз запускали?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #115

237. Сообщение от paulus (ok), 27-Дек-20, 10:15	–1 +/–
И как это чудо подсунуть grub4dos? Запустится ли? :)
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #243, #310

238. Сообщение от red75prim (?), 27-Дек-20, 10:21	+3 +/–
Осталось найти способ клонировать пряморуких никогда не ошибающихся программистов и всё будет в ажуре.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #221 Ответы: #254

239. Сообщение от llolik (ok), 27-Дек-20, 10:22	+/–
Rust даёт гарантии memory safety. memory leaks к этому не относятся и гарантий относительно их никто не давал. Так что по ссылке выше от анона всё правильно написано.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #27 Ответы: #369

240. Сообщение от n00by (ok), 27-Дек-20, 11:09	+/–
> Ни утечка пямяти, > ни дедлок не являются по своей сути нарушениями безопасности работы с > памятью и не приводят к UB. Угу, поведение определённое: на машине разработчика с 64 ГБ ОЗУ работает, а у пользователя с 8ГБ не работает.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #143

241. Сообщение от n00by (ok), 27-Дек-20, 11:23	+/–
> В любом языке можно устроить утечку. Создать вектор размером в 999999999999 элементов > и не удалять его до конца жизни программы. Компилятор не телепат, > откуда ему знать, ошибка это или фича? Из отсутствия доступа к вектору.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #97 Ответы: #244

242. Сообщение от n00by (ok), 27-Дек-20, 11:26	+/–
Байт-код у виртуальных процессоров (Лисп-машина). У "железной" машины машинный код.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #129

243. Сообщение от Аноним (243), 27-Дек-20, 11:26	+/–
Не, надо переписать grub4dos на расте
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #237

244. Сообщение от red75prim (?), 27-Дек-20, 11:33	+/–
> Из отсутствия доступа к вектору. А кто сказал, что доступа нет? Программа может раз в год читать значение нулевого элемента, например.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #241 Ответы: #247

245. Сообщение от Аноним (9), 27-Дек-20, 11:33	+/–
Это первый.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #175

246. Сообщение от Аноним (246), 27-Дек-20, 11:43	+2 +/–
Потому что при существенное утечке памяти... у тебя закончится память (и возможно апп кильнут). А при выходе за границы массива аппа напр. получит рут. Абсолютно никакой разницы, правда?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #221

247. Сообщение от n00by (ok), 27-Дек-20, 12:02	+/–
>> Из отсутствия доступа к вектору. > А кто сказал, что доступа нет? Программа может раз в год читать > значение нулевого элемента, например. Вы сами написали, что доступа к вектору нет, только к одному его элементу.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #244 Ответы: #248

248. Сообщение от red75prime (?), 27-Дек-20, 12:07	+/–
> Вы сами написали, что доступа к вектору нет, только к одному его > элементу. А дальше? Как компилятор об этом узнает?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #247 Ответы: #249

249. Сообщение от n00by (ok), 27-Дек-20, 12:19	+/–
>> Вы сами написали, что доступа к вектору нет, только к одному его >> элементу. > А дальше? Как компилятор об этом узнает? Произведёт семантический анализ.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #248 Ответы: #251

250. Сообщение от n00by (ok), 27-Дек-20, 12:31	+/–
Chunks of memory are maintained using a `boundary tag' method as     described in e.g., Knuth or Standish.  (See the paper by Paul     Wilson ftp://ftp.cs.utexas.edu/pub/garbage/allocsrv.ps for a     survey of such techniques.)  Sizes of free chunks are stored both     in the front of each chunk and at the end.  This makes     consolidating fragmented chunks into bigger chunks very fast.  The     size fields also hold bits representing whether chunks are free or     in use.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #170

251. Сообщение от red75prime (?), 27-Дек-20, 12:50	+/–
> Произведёт семантический анализ. Теорема Райса: нельзя доказать, что программа обладает неким семантическим свойством в общем случае. Так что не сработает.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #249 Ответы: #260

252. Сообщение от Аноним (252), 27-Дек-20, 13:00	+/–
Надо такие же истерики устраивать в языках с gc 'Они обещали что gc сам всё удалит, а он не удалил. Они врали!!!!!!111111'
Ответить | Правка | Наверх | Cообщить модератору

254. Сообщение от Ingener (??), 27-Дек-20, 13:09	–1 +/–
Все таки Си создает риск что код получится с утечкой. Раст наоборот. То есть надо уходить от Сей. На РАст или что еще. Кэп
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #238 Ответы: #259

255. Сообщение от Аноним (255), 27-Дек-20, 13:24	+8 +/–
Но да будет слово ваше: «да, да»; «нет, нет»; а что сверх этого, то от лукавого. Евангелие от Матфея 5:37 – Мф 5:37
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #130

256. Сообщение от Аноним (201), 27-Дек-20, 13:35	+1 +/–
Ты не путай магнитолку с автопилотом.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #142 Ответы: #297

257. Сообщение от Ordu (ok), 27-Дек-20, 13:36	+/–
> Есть и новое такое. Но там, вероятно, и остальное поддерживается примерно на > том уровне. Это даже по фану. Можно написать драйвер для своей сетевушки. Поддержка usb hid -- это уровень абстракции, чтоб его написать надо быть высоколобым разработчиком понимающим принципы ядра, под которые это делается. А драйверок запилить по аналогии с существующим -- это и Васян из 9б справится.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #234

258. Сообщение от Аноним (201), 27-Дек-20, 13:43	+1 +/–
Нет, ты берёшь исходники, пытаешься их собрать и обламываешься либо потому что сборочная система ничего не знает про сабж, либо потому что разрабы использовали расширения, выходящие за рамки POSIX (скорее всего, и то и другое).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #177 Ответы: #308

259. Сообщение от Аноним (201), 27-Дек-20, 13:45	+/–
> Си создает риск что код получится с утечкой. Раст наоборот. Раст создаёт риск, что код получится без утечки?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #254 Ответы: #272

260. Сообщение от n00by (ok), 27-Дек-20, 14:05	+/–
Вы описали частный случай.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #251

261. Сообщение от Аноним (-), 27-Дек-20, 14:36	+/–
Что насчет реального железа, кто нибудь запускал?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #351

262. Сообщение от Аноним (262), 27-Дек-20, 14:55	+3 +/–
Упустили предысторию. Давайте поставим более экономичные двигатели (большей степени двухконтурности) большего диаметра с минимальными затратами. Только они не влезают под крыло 737-го. Переделывать шасси дорого, поэтому вынесем их вперед, перед крылом. -> У самолета уплыл центр тяжести, и на продувках моделей он стал срываться в штопор на больших углах атаки. -> Ограничим углы атаки системой корректирующей тупых пилотов. -> Чтобы не переделывать тренажеры, и не переобучать летчиков, скажем что он ничем не отличается от предыдущего боинга. Профит! Разбивается первый боинг! Причем летчики очень долго боролись с машиной, что явно видно. Скажем что, нужно было выполнить несколько простых действий. Летчики виноваты! Разбивается второй боинг! Летчики выполнили указанные простые действия, и разбились в три раза быстрее. Акции боинга упали. Отлично, начинаем самовыкуп акций. Все равно рынок скоро все забудет, акции возрастут, профит!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #235 Ответы: #267

263. Сообщение от KroTozeR (ok), 27-Дек-20, 14:59	+1 +/–
Эх... Эщё язык-то не допилили, а уже ОСь лабают ради понта. Ну что за кодеры пошли? Лучше бы решали проблему "стыка" между либами на разных ЯП-ах, а то конь уж лет двадцать как не валялся... Или пилили бы ЯП для бинарного кода LLVM под окружение браузерного API, чтобы выдать сие как распределённую платформу для приложух, поддерживая полиморфизм во всех позах и обмен исполняемым кодом в рантайме, но это ж религия не позволяет, Касперский не велит, Microsoft не одобряЕ, Google нИАсилил, Линус глаза выпучил, Ябло послал на хутор близ Диканьки, ибо у них менеджерский распил в самом разгаре. Про Завалишна все дружно забыли, ибо хайпо-жвачная публика не любит самоделкиных (на их фоне сама фальшиво выглядит).
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #264, #266, #284, #293, #305, #330

264. Сообщение от Аноним (264), 27-Дек-20, 15:37	–1 +/–
Ядро Linux тоже ради понта было. Или вон GTK с гимпом.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #263 Ответы: #316

265. Сообщение от Ordu (ok), 27-Дек-20, 16:03	–1 +/–
> Я бы сообществу Rust пожелал от всей души не с С сражаться а с POSIX. Когда софт пишется на rust'е, POSIX не особо актуален. Если даже если он и есть где-то внизу под всеми абстракциями, он закопан глубоко. Rust использует utf8 в качестве внутренней кодировки. Под дефолту он предполагает, что внешняя тоже utf8. Я к тому, что тут и бороться-то особо не нужно. > Вот подумайте сколько linux-программ на С обрабатывают ошибки malloc? Полтора землекопа? Их очень сложно обрабатывать осмысленно. Когда malloc обломался, значит что и следующий malloc не пройдёт. Когда malloc обломался, значит что у системы не осталось свободной памяти. Разадресация нуля, как способ прибить программу -- это вполне себе способ. Я сталкивался с аргументацией о том, что именно так и надо, потому как при отсутствии свободной оперативки крайне сложно что-то осмысленное делать, даже упасть контролируемо сложно. То есть, может быть как-то можно сделать иначе, но это нужен какой-то другой подход к менеджменту виртуальной памятью. Общесистемно другой, и я даже не представляю какой. Я лишь из самых общих соображений допускаю, что как-то можно сделать лучше. > Это еще и полностью решает проблему полного отсутствия setup.exe. Ведь не пользователь должен решать, какой у него софт, не разработчик, которые его написал, а меинтейнер. Это, как раз, мне кажется правильным -- программиста вообще надо от пользователя отстранять как можно дальше, и втыкать между ними специально обученных людей, которые умеют общаться и с программистом, и с пользователем, потому как программист умеет писать программы, а вот UX обеспечивать -- нет. Бывают исключения, но они именно что исключения. Вот то, что стандартизация осталась на уровне наколенной поделки никому неизвестного финского студента, вот это реально плохо.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #210

266. Сообщение от Ken Tomson (?), 27-Дек-20, 16:31	+3 +/–
Вообще-то мы в свое время сделали еще круче - СПЕРВА написали ОС (на чем под руку попало и кое-что вообще прямо в кодах, благо pdp7 имела человекочитаемый код) а потом написали язык для ее написания (и таки переписали на нем ОС, пару раз по дороге и язык поправив, потому что не все с первой попытки вышло удобно). Но есть одна мелкая деталь: мы это делали не чтобы всех удивить и осчастливить, а для себя, любимых - просто pdp7 была настолько унылая, что никакой ос для нее вообще не было, только монитор, а нам ТАК трахаться не хотелось. Ну а потом нам еще захотелось пользу другим причинить, да и как-то оправдать отжатую 11ю вместо совсем уж сдохшей седьмой - мы еще текстовый форматтер сочинили и он тоже частью той ОС стал. На нем потом еще долго доки к этой самой PDP печатали. Почувствуйте, как у вас когда-то говорили, разницу. А обои, вообще-то, ничего так вышли, веселенькие...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #263 Ответы: #271, #317

267. Сообщение от red75prime (?), 27-Дек-20, 16:34	+1 +/–
> Разбивается первый боинг! Причем летчики очень долго боролись с машиной, что явно > видно. Скажем что, нужно было выполнить несколько простых действий. Летчики виноваты! Не совсем так. Команда летевшая на предыдущем рейсе (рейс перед крушением) замечает странное поведение стабилизатора высоты. Стабилизирует самолёт вручную и смотрит в quick reference handbook. Идентифицирует ситуацию как runaway stabilizer (идентифицирует неправильно, но описанные там действия позволяют исправить ситуацию), выполняет предписанные действия и сажает самолёт. Техники проверяют стабилизатор, ничего не находят. Следующая команда замечает странное поведение стабилизатора высоты, несколько раз возвращает стабилизатор в нормальное положение с помощью ручного управления электроприводом стабилизатора (это прекращает работу MCAS на 10 секунд после каждого ручного воздействия). Потом, похоже, команда начинает паниковать: ручное управление приводом стабилизатора больше не трогают и пилот просто тянет штурвал на себя (стабилизатор как-раз нужен, чтобы снять нагрузку со штурвала). MCAS, которой теперь никто не мешает, перекладывает стабилизатор полностью на пикирование и пилотам не хватает силы противодействовать. А действия простые - каждые 10 секунд дергать рычажок stab trim в направлении nose up, пока второй пилот листает quick reference handbook.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #262 Ответы: #268

268. Сообщение от red75prime (?), 27-Дек-20, 16:37	+1 +/–
> А действия простые - каждые 10 секунд дергать рычажок stab trim в > направлении nose up, пока второй пилот листает quick reference handbook. Этот самый рычажок находится на штурвале под большим пальцем левой руки. Снять нагрузку со штурвала - это часто используемое действие.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #267 Ответы: #402

269. Сообщение от topin89 (ok), 27-Дек-20, 16:47	+2 +/–
Видел я этот момент. Сначала кто-то выкатил большущий тест http-клиентов на Расте, раскатал всех в стиле "все п-сы, а я д'Артаньян". Но актиксу реально сильнее всех досталось. Потом начилась дискуссия на гитхабе, где этот д'Артаньян продолжал раздувать гребешок, но большинство вроде были более-менее адекватны и спокойны. Тем не менее, одного оказалось достаточно, чтобы нормальный, но не стойких духом разработчик забросил довольно неплохой фреймворк. Жаль, если честно. С такими нервами это всё равно бы случилось рано или поздно, но жаль. Собственно, все эти Code of Conduits создаются, чтобы такое происходило пореже, а не ради черножизненной дичи.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #59 Ответы: #270

270. Сообщение от red75prime (?), 27-Дек-20, 17:00	+1 +/–
Не, там вылез какой-то тип со стороны, не имеющий отношения ни к тестам, ни к актиксу, и выдал что-то вроде "Не хрен тебе на расте писать с такими замашками". Этому сообщению понаставили минусов, а в остальном цивильно убеждали автора актикса, что как-то нехорошо получается, надо бы поправить.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #269

271. Сообщение от Аноним (272), 27-Дек-20, 17:18	–2 +/–
Все что вы сделали это показали как не надо. И потом все пришлось писать с нуля как надо!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #266

272. Сообщение от Аноним (272), 27-Дек-20, 17:19	+2 +/–
Растаманам бы сначала разговорный язык подтянуть, потом уже ЯП изучать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #259

273. Сообщение от ИмяХ (?), 27-Дек-20, 17:30	–1 +/–
Отличный проект! Благодаря ему всплывает куча проблем в языке и становится понятно, почему раст никогда не заменит С.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #281, #294, #342

274. Сообщение от ИмяХ (?), 27-Дек-20, 17:36	+/–
Статическая линковка - это безопасно? А прикинь в стандартной библиотеке найдут критическую уязвимость. Вся их хваленная безопасность мигом накроется медным тазом.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #191 Ответы: #314, #339

275. Сообщение от ИмяХ (?), 27-Дек-20, 17:39	–2 +/–
И что в ней великолепного? Ни киберпунк ни автокад не запустить, даже блютуз наушники не работают. Оxepеть, такая великолепная, что вообще ничего сделать в ней нельзя - только включить, полюбоваться на рабочий стол и выключить.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

276. Сообщение от Sem (??), 27-Дек-20, 17:47	+/–
Версия 7.0 выпущена в марте 2017 года, 7.1 в июле 2020. Она точно живая такими темпами? Или просто на столько совершенна, что не требует улучшений и исправлений больше 3 лет?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #75 Ответы: #299

277. Сообщение от Sem (??), 27-Дек-20, 17:50	–1 +/–
Ты бы это... завязывал бы уже с веществами.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #169

278. Сообщение от Аноним (-), 27-Дек-20, 17:59	–1 +/–
> Вы не в состоянии выучить отличия Лол, вот занятся болше нечем
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #114 Ответы: #285

279. Сообщение от Аноним (279), 27-Дек-20, 18:05	+/–
> файловая система TFS, развиваемая на основе идей ZFS (модульный вариант ZFS на языке Rust) Ширится зоопарк "наших ответов" ZFS. И, конечно же, каждый уверен, что вот уж его-то ФС порвёт всех, как тузик грелку :)
Ответить | Правка | Наверх | Cообщить модератору

280. Сообщение от Аноним (280), 27-Дек-20, 18:05	–4 +/–
Вообще Rust, имхо, это попытка совместить в одну химеру C++ и Golang. Получилось забавно и стоит изучения, но примерно как Haskell - мозги и общий кругозор развивает, но денег на этом практически не заработать (по крайней мере, сейчас). Насчет того, что не защищает от утечек памяти - для идиотов там черным по белому написано, что сам Rust - это энфорсинг RAII парадигмы из C++. Пока тебе для работы достаточно стековых объектов и movable семантики обычных референсов и ты работаешь через референсы - память гарантированно не утечет, т.к. компилятор вместе с borrow checker поймают утечку "за хвост" через lifespan-ы. А вот если тебе нужна динамическая память, например связный список или дерево в хипе, то простите, тут только старые-добрые смартпоинтеры, расставляемые кодером вручную и утечка памяти через Rc<> циклы. В целом, где-то читал, что создать язык программирования для фон-Неймановской архитектуры, который бы своим синтаксисом и семантикой полностью ликвидировал случаи протечки, эквивалентно проблеме останова. Так что Rust и его memory management - не более чем best effort по водружению задачек на внимательность со стороны программиста на плечи компилятора.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #282, #295

281. Сообщение от Аноним (-), 27-Дек-20, 18:06	+1 +/–
> Благодаря ему куча вкатывальщиков в ойти смогут почувтвовать себя программистами, потешить свое самомнение, рассказать что умеют писать на языке на котором пишут ось. Ну и потом с чистой совестью вернуться к папе/маме под крылышко или как часто бывает - гос паёк и учить всех жизни.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #273 Ответы: #323

282. Сообщение от Растишка (?), 27-Дек-20, 18:13	+2 +/–
> C++ и Golang — единственные языки, которые знает анонимус, лол. Потому что Rust — это практически ML с C-подобным синтаксисом (плюс боров-чекер). Первые версии rustc вообще на OCaml были написаны.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #280 Ответы: #287, #291

283. Сообщение от Аноним (283), 27-Дек-20, 18:14	+/–
Кажется, тв только что поставил рекорд по "-"
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #52 Ответы: #286

284. Сообщение от Растишка (?), 27-Дек-20, 18:17	+1 +/–
> Или пилили бы ЯП для бинарного кода LLVM под окружение браузерного API ... сказал KroTozer и ушёл в криокамеру ещё на 30 лет. PNaCl уже успели запилить и закопать, а сейчас пилят Wasm, в который Rust умеет компилироваться искаропки.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #263 Ответы: #311, #320

285. Сообщение от Аноним (285), 27-Дек-20, 18:21	+/–
>> Вы не в состоянии выучить отличия > Лол, вот занятся болше нечем Некогда изучать матчасть, нужно комментарии c особо ценным мнением на опеннете ваять!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #278

286. Сообщение от A.Stahl (ok), 27-Дек-20, 18:32	+1 +/–
Скорее всего это работа одного человека со скриптом. Наверное кому-то на больную мозоль наступил или ещё чего. Время от времени у совершенно случайных моих сообщений бывают такое вот необычное количество минусов.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #283

287. Сообщение от Аноним (280), 27-Дек-20, 18:55	+/–
Вперед, покажи где в Rust монады, стрелки Клейсли, continuation passing style и тайпклассы. Тоже мне ML-потомок. Rust не поддерживает параметрический полиморфизм высших порядков (в частности, никаких родОв произвольной арности, как в Haskell/Scala). Это Golang с кучей "академических" идей и эксплуатацией бест практисов из C++.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #282 Ответы: #288, #292

288. Сообщение от Растишка (?), 27-Дек-20, 19:04	+2 +/–
Аноним слышал звон, но не отличает ML от гопник хаскеля, так и запишем.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #287

289. Сообщение от Аноним (144), 27-Дек-20, 19:15	+/–
Еще раз, 1. unsafe не считается безопасно/не_безопасно, оно считается как Сделай что-то но игнорируя проверки, играй с указателями как Я скажу, ломай поведение проги только лишь потаму что это захотел я. При использовании unsafe к данной функции ЧИТАЙТЕ зачем там unsafe... и уже потом используйте. Итоговое поведение можно покрыть тестами и оно ВОЗМОЖНО будет полностью safe, а возможно и  нет. Да и на случай проверок по коду данный момент будет отмечен. 2. Утечки плохи для памяти в плане, ну течет:) ну не контролируемо, память может закончится. Но еще раз, причем тут раст? Раст вам дал все гарантии какие смог и утечку в safe rust действительно сделать трудно, но это возможно (банально вызвать forget, ManuallyDrop, Box::leak, ...) .Раст дал безопасную работа с памятью (move sematic, borrow checker, ...) как смог безопасно? безопасно. 3. "а потому, что они не нашли способа обезопасить программиста от утечек памяти." Вы же понимаете что вы написали ровно то как и unsafe, "программиста нельзя обезопасить от unsafe, бо раст не умеет определять safe код это или действительно unsafe", как решается подобное? только тестами. которые в расте хороши, но и всеже к этому приближается +- clippy, ... возможно что-то в этом плане еще улучшат.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #158 Ответы: #296

290. Сообщение от Аноним (290), 27-Дек-20, 19:16	+/–
С этим понятно. Компилятору нужно правильные опции задавать. А как быть с перенесёнными с плюсов либами? Их в расте можно заметить по вызову типа С_function_name.unwrap(). Так напримёр все функции OpenGL на расте вызываются. Как это вообще работает? Происходят ли какие-то потери в производительности?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #187 Ответы: #338

291. Сообщение от Anonimowy cz322owiek (?), 27-Дек-20, 19:19	–1 +/–
Rust всё же не ML и не вполне функциональный язык (я спрашивал у проженных ML-хаскельщиков). Ну то есть да, в Rust есть ML-подобные типы алгебраические, но в целом-то он не особо сопротивляется мутабельности, например. Это всё же скорее обязательный энфорсинг RAII с некоторыми плюхами ML'я, как один аноним сказал выше. Для меня Rust выглядит как экая такая попытка переосмыслить C и C++ с учётом уроков и шишек за более чем 40 лет развития. Ну естественно, что народившееся за это ФП тоже оставило на нём немалый след
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #282 Ответы: #415

292. Сообщение от Anonimowy cz322owiek (?), 27-Дек-20, 19:21	+/–
Монаду можно в принципе эмулировать на любом языке. Это, считай, просто для Хаскела они стали идиоматической конструкцией для выполнения многих вещей, а так-то перенести хаскеловский интерфейс монад, чтобы те же монадические комбинаторы парсеров забацать, на другой язык никто не мешает
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #287

293. Сообщение от Аноним (144), 27-Дек-20, 19:25	+1 +/–
1. Эх... Эщё язык-то не допилили, а уже ОСь лабают. В языке есть действительно много моментов которые КАКТО вас ущемляют. Но нет ни одной преграды написать на нем ось, драйвер к линуксу, прогу с граф интерфейсом QT/GTK... Да и ядро языка никак не ломает ни 2015 редакцию языка, не 2018 (все компилируется и работает как надо) Ясно, понятно? 2. Ну что за кодеры пошли? Пошли и пошли:) 3. Лучше бы решали проблему "стыка" между либами на разных ЯП-ах, а то конь уж лет двадцать как не валялся Я не знаю в чем проблема. Есть автогенератор сырых C в сырые Rust структуры и наоборот, единственное это всеже будут не по растовским правилам писаные структуры, без safe оберток. Есть Java/Wasm/Python/JavaScript с ними взаимодействие двухстороннее как желается. Часто чтобы связать например Postgres exep на C++ и Rust надо: 1. сгенерировать сырые extern C структуры АВТОМАТИЧЕСКИ, 2. Написать безопасные и красивые Rust Api для этих С структур, 3. Используй, красиво и понятно и на растовском. И где тут вопросы о проблемах взаимодейсвия? 4. Или пилили бы ЯП для бинарного кода LLVM под окружение браузерного API, А раст завязан только под Firefox, браузеры и виртуальные машины?:) Не-не. Да и растоманы хотели когда-нибудь от LLVM отойти в сторону MIR, но пока не выходит. Далее нейкий странный бред у вас идет, еще раз Раст язык системного программирования (на нем хоть ОсЬ лепи, хоть с JavaScript общяйся, хоть Embedded)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #263 Ответы: #324

294. Сообщение от Аноним (144), 27-Дек-20, 19:26	+/–
1. "Благодаря ему всплывает куча проблем в языке" расскажите? А то нам не понятно... КАКИЕ ПРОБЛЕМЫ?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #273 Ответы: #313

295. Сообщение от Аноним (144), 27-Дек-20, 19:33	+/–
1. Вообще Rust, имхо, это попытка совместить в одну химеру C++ и Golang. Мне интересно почему вы решили совместить C++ и Go и получить Rust?:) Если: 1. C++: C + ... вот не помню что 2. GO: C++ + Java + ... 3. Rust: Haskell + OCaml + ... И GO никак не ложится в эту мешанину). 2. "Насчет того, что не защищает от утечек памяти - для идиотов там черным по белому написано, что сам Rust - это энфорсинг RAII парадигмы из C++. Пока тебе для работы достаточно стековых объектов и movable семантики обычных референсов и ты работаешь через референсы - память гарантированно не утечет, т.к. компилятор вместе с borrow checker поймают утечку "за хвост" через lifespan-ы. А вот если тебе нужна динамическая память, например связный список или дерево в хипе, то простите, тут только старые-добрые смартпоинтеры, расставляемые кодером вручную и утечка памяти через Rc<> циклы." Вот это уже хорошо, правильно!. 3. "Так что Rust и его memory management - не более чем best effort по водружению задачек на внимательность со стороны программиста на плечи компилятора." Знаете, уже сколько языков за плечами: Java/PHP/C++/Delphi... а от всех после Rust хочется плеваться. Так как в расте все поиному, не то что на этих ваших... Здесь во время написания ПО и душа радуется, код хорошо масштабируется, нет старых практик с этими NullPointer, за все что надо платить тебе рассписано, компилятором проверится, unsafe выделен, репозиторий библиотек (похожий на свалку, но:)).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #280 Ответы: #327

296. Сообщение от Ordu (ok), 27-Дек-20, 19:56	+1 +/–
Я не понимаю, чего ты не понимаешь и почему ты упорствуешь. Есть гипотеза, что ты пытаешься осмыслить мир постфактум, игнорируя историю этого мира, которая привела к сложившемуся положению дел. Весьма математический подход к проблеме, который иногда подходит и технарю/инженеру, но лишь иногда. Многие инженерные системы невозможно понять, игнорируя историю их создания и применения. Раст возник не спонтанно в вакууме, а из некоей исходной задумки Стива Клабника. Которая развивалась вместе с растом. Потом к Стиву присоединились другие люди, и у них были свои идеи, которые конфликтовали местами с идеями Клабника, всё это довольно долго варилось, и в результате получилось то, что получилось. Если смотреть с этой точки зрения, то говорить, что раст не предохраняет программиста от утечек, потому что в утечках нет никакой опасности -- это совершенно не верно. Он не предохраняет от утечек, потому что нет способа дать динамически выделяемую память и предохранить от утечек, не ограничивая программиста серьёзно в том, как он будет эту память использовать. > 3. "а потому, что они не нашли способа обезопасить программиста от утечек памяти." Вы же понимаете что вы написали ровно то как и unsafe, "программиста нельзя обезопасить от unsafe, бо раст не умеет определять safe код это или действительно unsafe" Возможно. То есть да, в некотором смысле я именно это и написал. Невозможно создать действительно безопасный язык программирования. Поэтому "безопасность" раста -- это ограниченная безопасность, некий компромисс между языком, который не позволяет ничего, но абсолютно безопасен, и языком, который позволяет много чего, но не совсем безопасен. Мне кажется, что ты пытаешься определить понятие safety как "те гарантии которые даёт rust". Это в некотором смысле правильно, но по хорошему это следовало бы называть Rust Safety, потому что safety в общем -- это более широкое понятие. Хочешь пример опасности утечек памяти? Представь себе автопилот, который падает в OOM в самый ответственный момент. Да хрен с ним с автопилотом: OOM это возможный вектор для DoS атаки.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #289

297. Сообщение от Заноним (?), 27-Дек-20, 19:58	+/–
аПтопилот вообще на ubuntu (лук ат тесла)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #256 Ответы: #301

298. Сообщение от Lex (??), 27-Дек-20, 20:07	–2 +/–
> В новой реализации удалось избавиться от утечек памяти А что их ждать, если даже сама новость намекает на некоторую фундаментальную дырявость и неспособность решать за проггера часть проблем, которые сабж типо_решает
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #59 Ответы: #304

299. Сообщение от Oxyd76 (?), 27-Дек-20, 20:27	+/–
Это-ж не линух.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #276

300. Сообщение от Аноним (201), 27-Дек-20, 20:32	+/–
> std::mem::forget Ну ок, ещё один способ отстрелить ногу. Прибегание к нему без учёта последствий разве не точно так же обуславливается криворукостью.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #46

301. Сообщение от Аноним (-), 27-Дек-20, 20:38	+/–
> аПтопилот вообще на ubuntu (лук ат тесла) У тесла есть рабочий (в реальности, а не сказках маркетолухов) автопилот? Да еще и на бубунте? Ну-ну.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #297

302. Сообщение от Аноним (302), 27-Дек-20, 20:38	+/–
>Ждём нашествие растофобов Нашествие-то растофанов уже в самом разгаре.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2

304. Сообщение от Аноним (-), 27-Дек-20, 20:51	+1 +/–
>> В новой реализации удалось избавиться от утечек памяти > А что их ждать, если даже сама новость намекает на некоторую фундаментальную > дырявость и неспособность решать за проггера часть проблем, которые сабж типо_решает Сразу видно отличное знание матчасти и сути проблемы, как и отличное понимание принципов и нюансов работы и реализации ядерного менеджера памяти (это ведь типичная проблема всех местных экспертов в целом и жопоскриптозников в частности)! Поэтому следует ценить это особо ценное мнение!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #298

305. Сообщение от Аноним (252), 27-Дек-20, 21:11	–1 +/–
Почему вы всё это не делаете?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #263 Ответы: #319

306. Сообщение от Аноним (144), 27-Дек-20, 22:12	+1 +/–
Правильно, в BrainFuck, никакие. А в расте дженерики и навороты на типах.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #161

307. Сообщение от Аноним (144), 27-Дек-20, 22:13	+/–
Это просто попытка отыгратся на комто (на расте) с целью самоутверждения. Человек натура дикая.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #135

308. Сообщение от Аноним (144), 27-Дек-20, 22:17	+/–
Если у вас статическая линковка, собирайте). Если у вас динамическая, возможно подменив названия у вас чето и заведется.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #258 Ответы: #322

309. Сообщение от Аноним (-), 27-Дек-20, 22:17	+1 +/–
> С языка снял :^) > Ну что, растофаноманы, чем будете отвечать? А зачем вам, жопоскриптозникам, не способным хотя бы смутно понять, что за утечки могут быть в _ядерном_менеджере_памяти_, отвечать? Если вы всерьез считаете, что там, в реализации менеджера аллоцировали память в heap, то ... медицина тут бессильна.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #27

310. Сообщение от Аноним (144), 27-Дек-20, 22:18	+/–
По идее, они работают же с обычным грубом. Но могу и ошибаться.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #237

311. Сообщение от Аноним (144), 27-Дек-20, 22:20	+/–
Вы ошиблись, не пилят. А ДАВНО запускают и интегрируют.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #284

312. Сообщение от Аноним (-), 27-Дек-20, 22:24	–1 +/–
>>В новой реализации удалось избавиться от утечек памяти > Никогда такого не было и вот опять. Так что там говорили про память? Ох уж эти жопоскриптозники. Все они знают, обо всем имеют свое ценное мнение! Еще бы хоть немного представляли себе принцип работы kernel memory manager и о каких утечках памяти там может быть речь (hint: динамично выделять память в реализации менеджера памяти немного ... сложновато), да шкурки от бананов не бросали где попало - цены бы им не было.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31

313. Сообщение от Аноним (198), 27-Дек-20, 22:55	+1 +/–
Он не защищает от утечек памяти. *BA DUM TSS*
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #294 Ответы: #401

314. Сообщение от Аноним (176), 27-Дек-20, 23:08	+/–
Ну тогда в эту категорию попадают все те, кто вовремя не обновляет софт. Даже при динамической линковке у юзера может быть устаревшая система с кучей уязвимостей.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #274 Ответы: #336

315. Сообщение от Урри (ok), 27-Дек-20, 23:22	+/–
Я, вообще-то, сам писал сборщики мусора и очень хорошо знаю как оно работает. Ну так что там аноним дефрагментировать собрался?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #146 Ответы: #332, #335

316. Сообщение от KroTozeR (ok), 27-Дек-20, 23:57	+1 +/–
Там был не столько понт, сколько протест, выраженный в массовом коддинге, когда куча студентов, коснувшихся Unix, решила понавтыкать AT&T за злобный монополизм. Но тогда и не было распространённой альтернативы. Теперь же нужно рожать новую концепцию, а не повторять пройденный путь только потому, что "оно на Rust-е".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #264

317. Сообщение от KroTozeR (ok), 28-Дек-20, 00:01	+1 +/–
Так в том-то и дело, что мотив нынче не слишком убедителен. Я, вот, не могу придумать сферу применения для Redox кроме демонстрации пруфа для Rust-пиара.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #266 Ответы: #400

318. Сообщение от marios (ok), 28-Дек-20, 00:02	+/–
Что значит никто не будет ставить на десктопы? Автор изначально её пилил для своего ноута, поскольку его не удовлетворял линукс.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11

319. Сообщение от KroTozeR (ok), 28-Дек-20, 00:09	+1 +/–
>> Почему вы всё это не делаете? А ещё глупее вопрос чем этот можно? Наверное потому, что решаю прямые рабочие задачи, а свободное время уделяю семье, а не сношанию Клавы Мышкиной на разных языках. Хотя Rust, как идея, выглядит всё же получше GoLang-а. Там совсем уж процедурно укурились.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #305 Ответы: #345

320. Сообщение от KroTozeR (ok), 28-Дек-20, 00:20	+/–
>> PNaCl Продукт от, извиняюсь за матерное слово, "Google", который пилили с понтом под зонтом до 2013, потом посеяли, потом откопали и обиженно ограничили ChromeOS, которой оно по идеологии не впёрлось? Замечательный продукт. Запихните его обратно в криокамеру и не вынимайте оттуда.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #284

321. Сообщение от adolfus (ok), 28-Дек-20, 00:28	+2 +/–
> на окаменелом с Пока лучше языка то и нет. Уже и не помню, когда у меня с ним были проблемы с той же паятью или еще с чем либо. Каких-то вещей не хватает, например сдвигов. Просто есть задачи, которые на чем то другом писать бессымсленно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #147

322. Сообщение от Аноним (201), 28-Дек-20, 00:53	+/–
Причём здесь линковка? Ты где вообще таких слов нахватался, мальчик?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #308

323. Сообщение от Аноним (201), 28-Дек-20, 00:57	+/–
> гос паёк и учить всех жизни. А, так ты на госпайке…
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #281 Ответы: #325

324. Сообщение от KroTozeR (ok), 28-Дек-20, 01:03	+/–
>> В языке есть действительно много моментов которые КАКТО вас ущемляют. Вокруг все ездят на электромобилях? При том, что нет никакой проблемы сделать электромобиль под любые нужды. Неужели история ничему не учит? Ни один техдир не потянет в проект Rust, пока под него не появится выбор SDK и IDE хоть как-то сопоставимый с уже имеющимся у того же дизориентрованного C/C++, наркоманского Java, фашистского Python-а, безалаберного ECMAScrypt и остального зоопарка. Нормального языка нет и вряд ли когда будет. В среднем Rust ни лучше, ни хуже, но он — зародыш в яйце. Даже загнанный за плинтус D и то взрослее будет. Ясно, понятно? >> Пошли и пошли:) как в том анекдоте: - Да пошёл ты!!! - Да, я посол, посол! >> Есть автогенератор сырых C в сырые Rust структуры и наоборот И ради мнимого "стандарта" повторяется анахронизм на новый лад. Стандарты же бинарей общие. Может стоило развивать стандарт линковки функций? А то где у нас ООП? в Караганде. Не вылезает за пределы объектника вообще. >> И где тут вопросы о проблемах взаимодейсвия? Показываю на автомобиль с деревянными колёсами, а в ответ: "И чё? Он не ездит, что ли???". >> А раст завязан только под Firefox, браузеры и виртуальные машины?:) Не-не. Вот тут, пожалуй, справедливо. Но, как выше и упоминал, на рынке, где старые решения покрывают все потребности, развивать надо что-то новое. А среди нового — дать замену глумлению над железом коммуникаторов, которые Google (опять матерюсь...) обозвали "смартфонами". Да, замыкать на браузере может и не надо, но сейчас куда важнее сменить Java-бред на коммуникаторах чем-то нативным или полунативным, как упомянутые LLVM и MIR, чем сиюминутно выгонять СИ из модулей Linux-а. А то блудливый GC роняет "андрюшу" на любом аппарате раз в неделю обязательно вне зависимости от производительности последнего и версии ОСи. >> Раст язык системного программирования (на нем хоть ОсЬ лепи, хоть с JavaScript общяйся, хоть Embedded) Да ради Бога! Кто запрещает-то? Просто допилить его прежде надо. Так-то Rust много приятнее укурства под названием "GoLang", хоть и кочевыряжится с облостями видимости. К тому же, если язык проектировался как "системный", то может разрабы уже решат, что именно они хотят заменить: СИ или C++ (это далеко не одно и то же). Сама проблема C++ кроется в попытке быть "хорошим" для СИ-кода. Так может не надо тащить этот горб Квазимодо в новый ЯП?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #293

325. Сообщение от KroTozeR (ok), 28-Дек-20, 01:11	–1 +/–
Когда капитаклизменные войны закончатся разрухой уровня "ядрён-батон США против китайского Huawei" на фоне взаимного пожирания друг друга за ошмётки рынка, а граждане за упоминание слова "IT" будут бить в рожу не предупреждая, тогда только "госпаёк" и будет решать, куда чего и как развивать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #323

327. Сообщение от NaN (?), 28-Дек-20, 05:55	+/–
> 2. GO: C++ + Java + ... Go: Plan 9 C on steroids with smoothy and GC > 3. Rust: Haskell + OCaml + ... 3. Rust: C++ + 2 bottles of vodka
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #295

328. Сообщение от Аноним (41), 28-Дек-20, 06:19	–2 +/–
После Раста писать на Си - это как с Ламборджини на Жигуль вернуться
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #217

330. Сообщение от Аноним (330), 28-Дек-20, 06:42	+/–
>Лучше бы решали проблему "стыка" между либами на разных ЯП-ах, а то конь уж лет двадцать как не валялся... .NET
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #263 Ответы: #398

332. Сообщение от n00by (ok), 28-Дек-20, 09:54	+2 +/–
Вы, наверное, слишком много пишете последнее время, и код через чур сложный, а уже конец года, это всё равно что релизить ночью в пятницу... Куча сама "дефрагментируется" https://www.opennet.ru/openforum/vsluhforumID3/122777.html#250 и возможно намудрить с последовательностью alloc() free() так, что слияние при освобождении части кучи окажется невозможным. На это и был намёк у меня изначально. Но я не заявлял, что являюсь менеджером кучи и буду дефрагментировать за него. Если хотите, что бы именно "дефрагментация" было написано, извольте, тоже про память: /* * The defrag ratio allows a configuration of the tradeoffs between * inter node defragmentation and node local allocations. A lower * defrag_ratio increases the tendency to do local allocations * instead of attempting to obtain partial slabs from other nodes. * * If the defrag_ratio is set to 0 then kmalloc() always * returns node local objects. If the ratio is higher then kmalloc() * may return off node objects because partial slabs are obtained * from other nodes and filled up. * * If /sys/kernel/slab/xx/remote_node_defrag_ratio is set to 100 * (which makes defrag_ratio = 1000) then every (well almost) * allocation will first attempt to defrag slab caches on other nodes. * This means scanning over all nodes to look for partial slabs which * may be expensive if we do it every time we are trying to find a slab * with available objects. */ /* * By default, transparent hugepage support is disabled in order to avoid * risking an increased memory footprint for applications that are not * guaranteed to benefit from it. When transparent hugepage support is * enabled, it is for all mappings, and khugepaged scans all mappings. * Defrag is invoked by khugepaged hugepage allocations and by page faults * for all hugepage allocations. */
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #315

333. Сообщение от pofigist (?), 28-Дек-20, 10:24	+/–
Три. Третий - удобство использования
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #87

334. Сообщение от n00by (ok), 28-Дек-20, 10:34	+/–
Ну и вот. Кстати, вместо "статически" в моём вопросе выше должно быть другое слово.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #222

335. Сообщение от Аноним (201), 28-Дек-20, 14:06	+/–
> Я, вообще-то, сам писал сборщики мусора и очень хорошо знаю как оно работает. Хорошо будешь знать после того, как сам напишешь malloc.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #315

336. Сообщение от Аноним (201), 28-Дек-20, 14:10	+/–
При динамической линковке достаточно обновить одну разделяемую библиотеку. При статической надо пересобирать всё, что слинковано с библиотекой. Чувствуешь разницу?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #314

337. Сообщение от Wilem82 (?), 28-Дек-20, 14:35	+/–
> Вы готовы показать ссылку на проект "который подгружает libc", а не слинкован с ней статически $ ldd /bin/ls         libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fcccfb9f000) > поскольку у того "любого языка" рантайм написан на Си Этот пункт не понял. Почему у языка рантайм должен быть на Си, при чём тут это?  Берём любой язык и делаем из него вызов к libc.so, при этом без разницы что за язык и какой у него рантайм. Это просто вызов функции произвольной динамической библиотеки, что на Линуксе что на Винде.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #233 Ответы: #352

338. Сообщение от Wilem82 (?), 28-Дек-20, 15:07	+1 +/–
> типа С_function_name.unwrap(). Скорее так:     unsafe { C_function_name() }; unwrap() - это метод растовских типов std::result::Result и std::option::Option, сишные функции его не возвращают. > Как это вообще работает? Происходят ли какие-то потери в производительности? Никаких потерь. Просто вызов функции, как и в Си.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #290

339. Сообщение от Wilem82 (?), 28-Дек-20, 15:18	+2 +/–
> А прикинь в стандартной библиотеке найдут критическую уязвимость. Так и обратное верно - прикинь, в новую версию библы занесут баг и все программы окажутся уязвимы. Динамическая линковка это здорово и жаль, что Cargo по-умолчанию её не делает. Но клёвая не тем, что можно зависимости на лету поменять (и потенциально сломать программу), а тем, что не надо один и тот же код сто раз в память загружать. То есть идеальный подход - это как в Винде: вот бинарь, вот рядом с ним DLL-ки. Хочешь - заменяй, хочешь - шарь их на всю систему. А не хочешь - ничё не делай, бинарь будет их использовать из текущей директории только для себя, и ни с кем в системе не будет пересекаться, не будет проблем с несовместимостями версий и тд.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #274

340. Сообщение от Wilem82 (?), 28-Дек-20, 15:22	+/–
> Но на какой такой чёрт растаманы чмырят ЯП Си за дырени и утечки. За дырени. Что касается утечек, то их в Расте сделать сильно сложнее - надо специально постараться. Ну и плюс сам язык Си адски устарел и не умеет множества полезных вещей. Си++ умеет, но всё равно уступает в простоте и удобстве.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #221 Ответы: #344

341. Сообщение от Аноним (-), 28-Дек-20, 15:25	+/–
Rust - модный язык. Кто хочет быть модным?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #343

342. Сообщение от Wilem82 (?), 28-Дек-20, 15:28	+3 +/–
> Отличный проект! Благодаря ему всплывает куча проблем в языке Это правда. Язык допиливают по ходу возникающих нужд для нетривиальных задач. Не пытаясь выполнить эти задачи не всегда можно обнаружить как и что необходимо в языке запилить. И это касается любого проекта, а не только ЯП. >  и становится понятно, почему раст никогда не заменит С. Разработчикам Раста непонятно, а тебе - понятно. Это здорово, всегда интересно встретить умных людей, которые додумались до чего-то, до чего не додумались остальные.  Осталось только поделиться с окружающими - что же именно стало понятно, расскажи.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #273

343. Сообщение от Wilem82 (?), 28-Дек-20, 15:29	+4 +/–
> Rust - модный язык. Кто хочет быть модным? Модный - javascript/golang/python.  Там ваще думать не надо, берёшь да идёшь в ногу с модой. А rust - немодный, там думать надо, это тяжело.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #341 Ответы: #348, #362

344. Сообщение от Аноним (-), 28-Дек-20, 15:31	+/–
>сам язык Си адски устарел Язык следующй структурной парадигме устареть не может никогда. Си вечнозелённый.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #340 Ответы: #349

345. Сообщение от Аноним (-), 28-Дек-20, 15:34	+/–
>а свободное время уделяю семье Не ври, ты ведь в свободное время мощно бухаешь. >Там совсем уж процедурно укурились. Ага, так и запишем: "KroTozeR не знает алгоритмы".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #319

346. Сообщение от что дозволено быку (?), 28-Дек-20, 15:35	+/–
s/удалось избавиться от утечек памяти/есть некоторые основания надеяться, что проблема не воспроизведётся на достаточно заметном количестве инсталляций/
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #358

347. Сообщение от Ананимас008 (?), 28-Дек-20, 15:36	+/–
Миникс же в каждом проце от интел, шпиенит за вами прямо сейчас. Очень даже прижилась.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25

348. Сообщение от Аноним (-), 28-Дек-20, 15:37	+/–
>А rust - немодный, там думать надо, это тяжело. Раст - это высокая мода, ты знаешь что-такое высокая мода.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #343

349. Сообщение от Wilem82 (?), 28-Дек-20, 15:57	+/–
> Язык следующй структурной парадигме устареть не может никогда Налицо подмена понятий. Парадигма может и не устарела, а язык - да. В нём очень мало фич, что приводит к усложнению разработки. За 50 лет много полезного и удобного успели придумать, мягко говоря.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #344 Ответы: #353

350. Сообщение от Аноним (350), 28-Дек-20, 16:49	+/–
> Всё зависит от программиста. Вот Растофанатики и усвоили урок что язык не имеет никакого значения. Программируешь ты на С++ или Расте, ни тот ни другой язык не даст тебе никакой безопасности если думать не умеешь. И встречный вопрос если все зависит от программиста зачем нужен Раст? Ответ очевиден. Раст не нужен.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #221 Ответы: #383

351. Сообщение от Аноним (350), 28-Дек-20, 16:50	+/–
Не будет его это как РеактОС. Нужен только для того чтобы показать смотрите как мы умеем, а не для того чтобы реально где-то применять.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #261 Ответы: #382

352. Сообщение от n00by (ok), 28-Дек-20, 17:21	+/–
>> Вы готовы показать ссылку на проект "который подгружает libc", а не слинкован с ней статически > $ ldd /bin/ls >         libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fcccfb9f000) Здесь "погружает" не ls, а системный загрузчик (ld-linux), выполняя динамическое связывание. ls начинает исполняться после этой фазы. Если бы ls подгружал, там происходил бы вызов функции dlopen(), примерно как в man dlopen. Но есть нюанс. libdl.so сама импортирует libc.so, а значит опять всё сделал системный загрузчик. Если подходить формально, мой вопрос содержит ошибку ("статически"), за которую Вы ухватились. По существу, она ничего не меняет, от техники связывания поведение не изменится: libc в обоих случаях загружена и инициализирована до вызова точки входа (и тем более main()) из ls. Наверное, Вы имели ввиду "использует libc". >> поскольку у того "любого языка" рантайм написан на Си > Этот пункт не понял. Почему у языка рантайм должен быть на Си, > при чём тут это? Он не должен. Но почему-то по факту так (не всегда, но примеров пока нет). > Берём любой язык и делаем из > него вызов к libc.so, при этом без разницы что за язык > и какой у него рантайм. Это просто вызов функции произвольной динамической > библиотеки, что на Линуксе что на Винде. Вот, уже без "подгружаем", а просто "делаем" вызов... софта на Си, к которому "любой язык" сбоку прикручен системным загрузчиком, который тоже на Си.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #337 Ответы: #354, #356

353. Сообщение от Аноним (353), 28-Дек-20, 17:47	+/–
Мягко говоря все фичи к "процедурному стилю программирования" никакого отношения не имеют. Все фичи пилятся в рамках ООП или функциональщины.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #349 Ответы: #355

354. Сообщение от Wilem82 (?), 28-Дек-20, 19:10	+/–
> Вот, уже без "подгружаем", а просто "делаем" вызов... софта на Си, к которому "любой язык" сбоку прикручен системным загрузчиком, который тоже на Си. Не понимаю про что спорим. Да, с dlopen() я перепутал, чё с меня взять - я тупой жавер, а не сишник - я ваще не должен знать разницы между "сокетом" и "процессом" (это один чел в Мейлру так однажды пошутил про жаверов). Смысл в том, что вызов к libc.so может сделать любой процесс, не важно из какого языка он скомпилен. И этому процессу будет также не важно, какая у libc реализация - его интересуют только сигнатуры функций и поведение по контракту. О чём я и говорю - libc нужен программам, которые пользуются этим API и не более. На редоксе этот API предоставляется через relibc, на линуксе через GNU libc. Ещё бывает musl. И так далее. При этом программам под редокс либц может быть вообще не нужен, т.к. между ядром и программой используется другая обёртка над этим ядром.  А может быть и ваще без обёртки - херач сразу сисколлы и не горюй, на расте для линуксовых сисколлов тупо есть либа, как есть либа для сисколлов виндовых.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #352 Ответы: #381

355. Сообщение от Wilem82 (?), 28-Дек-20, 19:13	+/–
Эта мысль для меня слишком глубока, извините, не осилил понять какое это имеет отношение к тезису "си - устарел".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #353 Ответы: #363

356. Сообщение от Аноним (-), 28-Дек-20, 19:33	+/–
> Вот, уже без "подгружаем", а просто "делаем" вызов... софта на Си, к > которому "любой язык" сбоку прикручен системным загрузчиком, который тоже на Си. hexdump -C /libexec/ld-elf.so.1 | (head -n3 ;tail)     00000000  7f 45 4c 46 02 01 01 09  00 00 00 00 00 00 00 00  |.ELF............| 00000010  03 00 3e 00 01 00 00 00  00 90 00 00 00 00 00 00  |..>.............| 00000020  40 00 00 00 00 00 00 00  d8 47 02 00 00 00 00 00  |@........G......| 00024c50  00 00 00 00 00 00 00 00  aa 00 00 00 01 00 00 00  |................| 00024c60  30 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |0...............| 00024c70  48 46 02 00 00 00 00 00  da 00 00 00 00 00 00 00  |HF..............| 00024c80  00 00 00 00 00 00 00 00  01 00 00 00 00 00 00 00  |................| странный какой-то Cи. Наверное, новый стандарт.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #352 Ответы: #372

357. Сообщение от Rf4567785433 (?), 28-Дек-20, 22:41	–1 +/–
Просто хочу сказать что РеактОС все еще топчется на месте. Тут уже и Раст возник, и продвинулся, и ОС возникла, много воды утекло..
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #385

358. Сообщение от Rf4567785433 (?), 28-Дек-20, 22:43	–2 +/–
Это оператор яп? Что-то из Перл?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #346 Ответы: #389

359. Сообщение от Аноним (359), 28-Дек-20, 23:13	+/–
www.google.com/search?q=std%3A%3A
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #154 Ответы: #360

360. Сообщение от Ordu (ok), 28-Дек-20, 23:47	+/–
> www.google.com/search?q=std%3A%3A И что гугл пишет? Я просто стараюсь с ним не общаться без большой надобности. А первая страница результатов ddg при поиске std:: о какой-то венере Sexually Transmitted Diseases.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #359

361. Сообщение от PetrG (ok), 29-Дек-20, 03:06	+/–
Можно сказать что вы невнимательно прочитали новость. А можно по существу - утечка памяти которую допускает реализация mm - это логическая ошибка mm а не проблема с памятью самого mm.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #27

362. Сообщение от Аноним (362), 29-Дек-20, 03:50	+1 +/–
> А rust - немодный, там думать надо, это тяжело. Вот теперь полный ступор. Кричали же что Си это тяжело, а на расте даже домохозяйка может ось написать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #343 Ответы: #386

363. Сообщение от Аноним (-), 29-Дек-20, 06:37	+/–
>Эта мысль для меня слишком глубока, извините, не осилил понять Ну хорошо, смотри. Алмаз может устареть? Он всегда ценен, и люди во все времена хоят его добывать. Чистый Си - это процедурный алмаз.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #355

364. Сообщение от luis2 (?), 29-Дек-20, 06:57	–1 +/–
Скажите пожалуйста, а какой собственно профит кроме выеженов со стороны растофилов, ведь уже давно есть всякие KolibriOS, что почти машинный код.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #387

366. Сообщение от Аноним (366), 29-Дек-20, 09:42	–1 +/–
> утечек памяти, которые создавали проблемы > стандартная Си-библиотека > борьбу ... в сборках Rust ... макроса Asm Знаете, что лишнее в этой недооси? Раст!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6

367. Сообщение от Аноним (366), 29-Дек-20, 09:46	+/–
Вызовы ядра на C, Карл, потому что на расте это сделать невозможно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20 Ответы: #391

368. Сообщение от Аноним (366), 29-Дек-20, 09:48	–1 +/–
> покрыто безопасными обертками вот только почему-то были утечки памяти на расте :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #137 Ответы: #393, #418

369. Сообщение от Аноним (366), 29-Дек-20, 09:53	+/–
растаманы потекли :))) но это, внезапно, нормальное их состояние.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #239 Ответы: #376

370. Сообщение от Аноним (366), 29-Дек-20, 09:55	–1 +/–
Ух, ты... как запели растаманы!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #70

371. Сообщение от Аноним (366), 29-Дек-20, 09:57	+/–
> из-за чего из-за раста, очевидно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #86

372. Сообщение от n00by (ok), 29-Дек-20, 10:00	+/–
>[оверквотинг удален] > 00024c50  00 00 00 00 00 00 00 00  aa > 00 00 00 01 00 00 00  |................| > 00024c60  30 00 00 00 00 00 00 00  00 > 00 00 00 00 00 00 00  |0...............| > 00024c70  48 46 02 00 00 00 00 00  da > 00 00 00 00 00 00 00  |HF..............| > 00024c80  00 00 00 00 00 00 00 00  01 > 00 00 00 00 00 00 00  |................| > > странный какой-то Cи. Наверное, новый стандарт. Бывает нечто, о чем говорят: «смотри, вот это новое»; но это было уже в веках, бывших прежде нас. Figure 3-11: ELF header char magic[4] = "\177ELF";// magic number char class; // address size, 1 = 32 bit, 2 = 64 bit char byteorder; // 1 = little-endian, 2 = big-endian char hversion; // header version, always 1 char pad[9]; short filetype; // file type: 1 = relocatable, 2 = executable, // 3 = shared object, 4 = core image short archtype; // 2 = SPARC, 3 = x86, 4 = 68K, etc. int fversion; // file version, always 1 int entry; // entry point if executable int phdrpos; // file position of program header or 0 int shdrpos; // file position of section header or 0 int flags; // architecture specific flags, usually 0 short hdrsize; // size of this ELF header short phdrent; // size of an entry in program header short phdrcnt; // number of entries in program header or 0 short shdrent; // size of an entry in section header short phdrcnt; // number of entries in section header or 0 short strsec; // section number that contains section name strings (с) Linkers & Loaders by John R. Levine
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #356 Ответы: #390

373. Сообщение от Аноним (366), 29-Дек-20, 10:00	+/–
Для растаманов течка - нормальное состояние :) то, что проги падают от нехватки утекшей памяти - это норма :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #143

374. Сообщение от Аноним (366), 29-Дек-20, 10:03	+/–
растаманы вообще хоть во что-то умеют?! написали микроядро, которое уже течёт?!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #204

375. Сообщение от Аноним (366), 29-Дек-20, 10:07	–1 +/–
> В новой реализации удалось избавиться от утечек памяти борьба с утечками памяти в самом безопасном языке во вселенной <----- вы находитесь здесь
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #100

376. Сообщение от llolik (ok), 29-Дек-20, 10:20	+/–
> растаманы потекли :))) но это, внезапно, нормальное их состояние. Ну во-первых, на Rust я написал, пока что, около 2kloc, что мало, чтобы являться специалистом по rust и вообще "растаманом". Во-вторых, я читать умею: https://en.wikipedia.org/wiki/Memory_safety - найди мне тут leak-и.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #369

378. Сообщение от Аноним (366), 29-Дек-20, 10:23	+1 +/–
Попробуй следить за изменениями, а не сидеть только во вконтактиках.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #126

379. Сообщение от Аноним (366), 29-Дек-20, 10:24	+/–
> целенаправленная кампания по дискредитации языка > утечки памяти
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #135 Ответы: #380

380. Сообщение от Аноним (366), 29-Дек-20, 10:25	+/–
растаманы - s&m?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #379

381. Сообщение от n00by (ok), 29-Дек-20, 10:32	+/–
>> Вот, уже без "подгружаем", а просто "делаем" вызов... софта на Си, к которому "любой язык" сбоку прикручен системным загрузчиком, который тоже на Си. > Не понимаю про что спорим. В том-то и дело. Вы сами начали оспаривать мой тезис "нужна libc ... что бы сторонний софт (который на Си) запускать". Я могу к нему добавить, что Glasgow Haskell Compiler транслирует в Си, MLton транслирует в Си, ocamlopt транслирует в машинный код, но рантайм всё равно там на Си. Рантайм Perl и Python наверняка на Си, но я сам не смотрел. Потому мне интересно, есть ли какие-то примеры, не гипотетическая возможность, а факты. > Да, с dlopen() я перепутал, чё с > меня взять - я тупой жавер, а не сишник - я > ваще не должен знать разницы между "сокетом" и "процессом" (это один > чел в Мейлру так однажды пошутил про жаверов). > Смысл в том, что вызов к libc.so может сделать любой процесс, не > важно из какого языка он скомпилен. Интересно, в частности, зачем таким проектам вообще нужна libc, если у них свой рантайм. > При этом программам под редокс > либц может быть вообще не нужен, т.к. между ядром и программой > используется другая обёртка над этим ядром.  А может быть и > ваще без обёртки - херач сразу сисколлы и не горюй, на > расте для линуксовых сисколлов тупо есть либа Вот видите, самодостаточным языкам не нужна libc, они и так работают. > как есть либа для > сисколлов виндовых. Это очень печальный звоночек, если там действительно используются "сисколы" (вектора которых меняются), а не ntdll.dll (или kernel32.dll).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #354 Ответы: #388

382. Сообщение от Аноним (366), 29-Дек-20, 11:10	+/–
растаманы только показали, как они могут течь.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #351

383. Сообщение от Wilem82 (?), 29-Дек-20, 11:12	+/–
> если все зависит от программиста зачем нужен Раст? От программиста зависит только использование unsafe. Без ансейфа ты сегфолты не получишь. Утечки без unsafe - насколько понимаю только через специальные для этого функции - std::mem::forget(), std::boxed::Box::leak(). Случайно ты их не вызовешь. Ну это как случайно вызвать std::process::exit(0) и жаловаться, что у тебя процесс завершается. Как ты считаешь, если компилятор в силу устройства языка проверяет за тебя кучу ошибок работы с памятью и гарантирует отсутствие сегфолтов без unsafe - означает ли это, что ничего от языка не зависит? Как ты так интересно логические выводы-то строишь?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #350

385. Сообщение от Аноним (366), 29-Дек-20, 11:18	+/–
> Раст возник, и продвинулся ...в сторону текучести памяти.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #357

386. Сообщение от Wilem82 (?), 29-Дек-20, 11:23	+2 +/–
> Кричали же что Си это тяжело, а на расте даже домохозяйка может ось написать. Про лайфтаймы и овнершипы всё равно думать надо. Это гораздо проще, чем писать на Си, но думать всё равно надо сильно больше, чем на игрушечных языках. Плюс это требует более глубокого понимания низкоуровневого устройства. Например - чем куча отличается от стека. Откуда стек берётся и как примерно устроен. Жаваскриптисты скорее всего даже слов таких не знают, а про стек может быть что-то краем уха слышали когда из-за рекурсии у них переполнение раз в жизни случилось. Ну и в целом раст позволяет, - а иногда и принуждает - думать и обрабатывать какие-то мелкие детали, которые в игрушечных языках спрятаны.  Например, частный вопрос от новичков раста - а чё это у меня программа выводящая в stdout тормозит? А чел там фигарит println!() и не знает, что на каждый вызов лочится мутекс, и что бы оно быстро работало, нужно один раз взять мутекс себе и только потом в stdout всё записать, что неимоверно ускоряет процесс. На всяких жавах, жаваскриптах и прочем у тебя такого выбора нет, ты всегда будешь платить за синхронизацию каждого вызова.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #362 Ответы: #392, #403

387. Сообщение от Wilem82 (?), 29-Дек-20, 11:33	+1 +/–
Пожалуйста: https://doc.redox-os.org/book/ch01-05-why-redox.html Кроме того, авторы заявляли, что делают это не ради самой ОС, а ради развития языка.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #364 Ответы: #396

388. Сообщение от Wilem82 (?), 29-Дек-20, 12:34	+/–
> есть ли какие-то примеры, не гипотетическая возможность, а факты Извините, я наверно туплю. Примеры чего? Софта на Си, которому не нужен libc? Или софта не на Си, которому не нужен libc? Ясен пень есть - ядро любой операционки, к примеру. Оно не может зависеть от libc, потому что libc сам зависит от вызовов к ядру. Или какой-нибудь эмбед. Плюс скорее всего виндовым программам оно не нужно, у винды свой API к ядру. Хотя для винды, безусловно, есть реализация libc. Кстати пишут, что Golang ваще игнорирует libc, и что на Линуксе, что на Винде сам обращается к ядру через системные вызовы. > Интересно, в частности, зачем таким проектам вообще нужна libc, если у них свой рантайм. Не знаю. > Вот видите, самодостаточным языкам не нужна libc, они и так работают. Да я в курсе... опять не понимаю, к чему это? Я что, говорю, что программам, которым не нужен libc - нужен libc? > Это очень печальный звоночек, если там действительно используются "сисколы" (вектора которых меняются), а не ntdll.dll (или kernel32.dll). Это я фигню написал - да, там обёртка над kernel32.dll.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #381 Ответы: #406

389. Сообщение от Wilem82 (?), 29-Дек-20, 12:58	+2 +/–
> Это оператор яп? Что-то из Перл? s/<pattern>/<replacement>/<flags> Это из sed (а может и каких-то его предков) прошло: https://www.gnu.org/software/sed/manual/html_node/The-_0022s... . Перекачевало в vi, потом в vim.  Потом в первых интернет-чатах IRC, которые были популярны в 90-ые и даже немного 00-ые, таким образом матёрые юниксоиды друг другу остроумно показывали, что они типа исправляют опечатку в уже отправленном сообщении, т.к. IRC не позволяет отправленные изменять. Ну и с тех пор ностальгирующие по давним временам, или просто люди с очень специфическим кругом общения, пишут вот так. То есть фактически это такой элитный способ сказать "у меня вон там опечатка, я типа заменяю такой-то кусок текста на другой" вместо того, что бы зарегистрироваться и иметь возможность редактировать собственные сообщения. Или же, таким образом человек показывает, что он хочет заменить кусок текста в чужом сообщении. Сейчас, правда, это принято делать по-другому: ты выделяешь цитату и правишь в ней текст, а потом добавляешь "вот, поправил" - это гораздо смешнее получается, а главное всем понятно. Пожалуйста.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #358

390. Сообщение от Аноним (390), 29-Дек-20, 13:22	+/–
>> странный какой-то Cи. Наверное, новый стандарт. > Бывает нечто, о чем говорят: «смотри, вот это новое»; но это было уже в веках, бывших прежде нас. > Figure 3-11: ELF header > char magic[4] = "\177ELF";// magic number ... > (с) Linkers & Loaders by John R. Levine Ну вот видишь - совсем не сишка.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #372 Ответы: #405

391. Сообщение от Аноним (-), 29-Дек-20, 13:33	+/–
> Вызовы ядра на C, Карл, потому что на расте это сделать невозможно. Ты обо*рался. Причем аж два раза. https://github.com/torvalds/linux/blob/fcadab740480e0e0e9fa9... static inline long stub_syscall2(long syscall, long arg1, long arg2) {     long ret;     __asm__ volatile (__syscall         : "=a" (ret)         : "0" (syscall), "D" (arg1), "S" (arg2) : __syscall_clobber );     return ret; } https://github.com/kmcallister/syscall.rs/blob/master/src/pl... #[inline(always)] pub unsafe fn syscall2(n: usize, a1: usize, a2: usize) -> usize {     let ret : usize;     asm!("syscall" : "={rax}"(ret)                    : "{rax}"(n), "{rdi}"(a1), "{rsi}"(a2)                    : "rcx", "r11", "memory"                    : "volatile");     ret }
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #367 Ответы: #423

392. Сообщение от Аноним (-), 29-Дек-20, 13:43	–1 +/–
>а чё это у меня программа выводящая в stdout тормозит? А чел там фигарит println!() и не знает, что на каждый вызов лочится мутекс, и что бы оно быстро работало, нужно один раз взять мутекс себе и только потом в stdout всё записать, что неимоверно ускоряет процесс. В Си поезд из точки А в точку Б приедет прямиком. В Расте, для того чтобы доехать до пункта Б, надо сначала проехать пункты В и Д.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #386 Ответы: #394, #395

393. Сообщение от Аноним (-), 29-Дек-20, 13:50	+/–
>> покрыто безопасными обертками > вот только почему-то были утечки памяти на расте :) О, подтянулись очередные зксперты. Не было там "утечки памяти на расте" - просто нужно читать глазками, а не опой и знать хотя бы азы низкоуровневщины, а не только JS с питончиком.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #368

394. Сообщение от Аноним (394), 29-Дек-20, 14:24	+1 +/–
https://doc.rust-lang.org/std/io/fn.stdout.html >> Each handle returned is a reference to a shared global buffer whose access is synchronized via a mutex. If you need more explicit control over locking, see the Stdout::lock method. > В Си поезд из точки А в точку Б приедет прямиком. Питонистам и ЖСникам оно конечно виднее, но в С11 говорится о > §7.21.2 Streams > Each stream has an associated lock that is used to prevent data races when multiple threads of execution access a stream, and to restrict the interleaving of stream operations performed by multiple threads. Only one thread may hold this lock at a time А до этого машинист считал, что по умолчанию поезд на этом пути только один.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #392

395. Сообщение от Wilem82 (?), 29-Дек-20, 15:12	+3 +/–
> В Си поезд из точки А в точку Б приедет прямиком. В Расте, для того чтобы доехать до пункта Б, надо сначала проехать пункты В и Д. Тебе уже поясинили почему неправ, но добавлю: даже если бы это было так, как ты говоришь, это означало бы только врождённую опасность функции вывода в stdout. Именно потому, что Раст как язык и его библиотеки в целом пекутся о корректности - программы на нём корректно работают, а не глючат или сегфолтятся. Не, "ой, я не подумал, ой а я не знал, ой а я не думал что эта ошибка реально может возникнуть", а тебя подталкивают или даже заставляют обработать все крайние случаи. В результате твоя программа имеет больший шанс быть надёжной, а не куском говна.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #392 Ответы: #404

396. Сообщение от luis2 (?), 29-Дек-20, 16:17	–2 +/–
Спасибо, из прочитанного стало ясно, что просто кто-то хочет свой блекджек с девами. Причины какие-то высосанные.....
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #387 Ответы: #397, #416

397. Сообщение от Wilem82 (?), 29-Дек-20, 17:32	+1 +/–
А какие в твоих глазах были бы невысосанными? Ну что б понимать, что не любое обоснование было бы "плохим", а где-то есть всё-таки "хорошее".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #396

398. Сообщение от ИмяХ (?), 29-Дек-20, 20:05	+1 +/–
Тупые поделки от мелкософта не нужны
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #330

399. Сообщение от freecoder_xx (?), 29-Дек-20, 22:40	+/–
И откуда вы это помните, кто и через кого вам эту историю пересказал? По тону вашего комментария видно, что вы вообще не в курсе той истории, что там реально произошло.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #59

400. Сообщение от freecoder_xx (?), 29-Дек-20, 23:46	+/–
Я думаю вы неправильно смотрите: нужно искать мотив не снаружи, а изнутри. Рано или поздно на Rust будут писать ОСи, и первой уже оказался Redox. В экосистеме раста идет конкуренция среди разработчиков за "первое место" и прочие блага, которые оно способно принести.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #317 Ответы: #412

401. Сообщение от freecoder_xx (?), 29-Дек-20, 23:48	+/–
Местные хейтеры раста не знают матчасть, вот что стало понятно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #313

402. Сообщение от uis (ok), 30-Дек-20, 02:40	+1 +/–
Я и не знал, что на опеннете есть даже пилоты боингов. Или их конструкторы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #268

403. Сообщение от uis (ok), 30-Дек-20, 02:58	+/–
>Это гораздо проще, чем писать на Си, но думать всё равно надо сильно больше, чем на игрушечных языках. Плюс это требует более глубокого понимания низкоуровневого устройства. Например - чем куча отличается от стека. Что-то мне подсказывает, что наоборот. На сях, например, быстро доходит, чем отличается malloc, alloca и vla. И почему возвращать указатели последних - идиотизм. Да и вообще си - высокоуровневая замена ассемблеру, разбавляемая разве что inline assembly.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #386

404. Сообщение от uis (ok), 30-Дек-20, 03:05	–1 +/–
>сегфолтятся Уж лучше сегфолт на сях, чем вполне определённое, но не для пользователя, продолжение выполнения. >, а тебя подталкивают или даже заставляют обработать все крайние случаи. Часто встречал программы, где проверяется errno вызова close? Или как там на хрусте.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #395 Ответы: #408

405. Сообщение от n00by (ok), 30-Дек-20, 09:48	+/–
>>> странный какой-то Cи. Наверное, новый стандарт. >> Бывает нечто, о чем говорят: «смотри, вот это новое»; но это было уже в веках, бывших прежде нас. >> Figure 3-11: ELF header >> char magic[4] = "\177ELF";// magic number > ... >> (с) Linkers & Loaders by John R. Levine > Ну вот видишь - совсем не сишка. Даже и не знаю, что сказать Вам по этому поводу... Представьте себе конфету. Шоколадную. Вы же вкушаете её без фантика, верно? Потому она из какао, а не из бумаги с фольгой.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #390

406. Сообщение от n00by (ok), 30-Дек-20, 10:09	+/–
>> есть ли какие-то примеры, не гипотетическая возможность, а факты > Извините, я наверно туплю. Примеры чего? Софта на Си, которому не нужен > libc? Или софта не на Си, которому не нужен libc? С Вами каши не сваришь... Вы же сами начали оспаривать мой тезис. Наверное, у Вас должны быть какие-то примеры, способные его (мой тезис) опровергнуть? Вот их и хотелось бы посмотреть. > Ясен > пень есть - ядро любой операционки, к примеру. Оно не может > зависеть от libc, потому что libc сам зависит от вызовов к > ядру. Или какой-нибудь эмбед. Плюс скорее всего виндовым программам оно не > нужно, у винды свой API к ядру. Хотя для винды, безусловно, > есть реализация libc. Речь шла о запуске прикладного софта под Redox. Пример с ядром не подходит. > Кстати пишут, что Golang ваще игнорирует libc, и что на Линуксе, что > на Винде сам обращается к ядру через системные вызовы. $ ldd `which go`     linux-vdso.so.1     libpthread.so.0 => /lib64/libpthread.so.0     libc.so.6 => /lib64/libc.so.6     /lib64/ld-linux-x86-64.so.2 >> Интересно, в частности, зачем таким проектам вообще нужна libc, если у них свой рантайм. > Не знаю. >> Вот видите, самодостаточным языкам не нужна libc, они и так работают. > Да я в курсе... опять не понимаю, к чему это? Я что, > говорю, что программам, которым не нужен libc - нужен libc? Вы говорите, что "подгружает libc и делает вызовы к его фукнциям". Я думал знаете, зачем.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #388 Ответы: #409

407. Сообщение от Аноним (210), 30-Дек-20, 11:57	+/–
Не все банкоматы на Windows XP. Есть же QNX.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #75 Ответы: #422

408. Сообщение от Wilem82 (?), 30-Дек-20, 12:57	+/–
> Уж лучше сегфолт на сях, чем вполне определённое, но не для пользователя, продолжение выполнения. Не понял про что это. > Часто встречал программы, где проверяется errno вызова close? Или как там на хрусте. Я часто встречал где не проверяется, что существенно усложняло траблшутинг на продакшене. Сам же я всегда все ошибки проверяю и логирую если что-то не так. Вообще, если интересует тема надёжных программ, сделанных для продакшена, а не для тестировщиков - рекомендую к прочтению https://www.amazon.com/Release-Design-Deploy-Production-Read... . Например, механизм "circuit breaker" придумал как раз автор этой книги, и популяризовал тамже, за много лет до того, как реализация CB стала появляться в некоторых фреймворках.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #404

409. Сообщение от Wilem82 (?), 30-Дек-20, 13:08	+/–
> Речь шла о запуске прикладного софта под Redox. relibc - реализует API libc для ядра редокса. Программы, написанные под libc при этом могут работать на редоксе. Поэтому relibc - полезен. При этом сами программы могут быть написаны не на Сях. Я писал про это. Например, они могут быть написаны на Расте, т.к. std Раст-а на линуксе использует libc. А может и не использовать, если сделать реализацию std, которая минуя API libc, напрямую обращается к API redox-а. > $ ldd `which go` Не компилятор, а программы, скомпилированные Golang. Сам не проверял, но пишут, что оно так. > Вы говорите, что "подгружает libc и делает вызовы к его фукнциям". Я думал знаете, зачем. Любая программа, если она использует libc - использует libc. Либо он статически прилинкован в бинарь, либо подгружается динамически - не важно, изнутри через dlopen или снаружи через механизмы ОС. В чём вопрос?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #406 Ответы: #410

410. Сообщение от n00by (ok), 30-Дек-20, 15:07	+/–
>> Речь шла о запуске прикладного софта под Redox. > relibc - реализует API libc для ядра редокса. Программы, написанные под libc > при этом могут работать на редоксе. Поэтому relibc - полезен. При > этом сами программы могут быть написаны не на Сях. Я писал > про это. Например, они могут быть написаны на Расте, Ясно, примеров нет и не будет. >> $ ldd `which go` > Не компилятор, а программы, скомпилированные Golang. https://go.googlesource.com/go/+/refs/heads/master/src/built... $ ldd `which gitea`     linux-gate.so.1     libdl.so.2 => /lib/libdl.so.2     libpthread.so.0 => /lib/libpthread.so.0     libpam.so.0 => /lib/libpam.so.0     libc.so.6 => /lib/libc.so.6     /lib/ld-linux.so.2 > Сам не проверял, но пишут, что > оно так. Убедили. >> Вы говорите, что "подгружает libc и делает вызовы к его фукнциям". Я думал знаете, зачем. > Любая программа, если она использует libc - использует libc. Либо он статически > прилинкован в бинарь, либо подгружается динамически - не важно, изнутри через > dlopen или снаружи через механизмы ОС. В чём вопрос? У меня больше нет к Вам вопросов.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #409 Ответы: #411

411. Сообщение от Wilem82 (?), 30-Дек-20, 16:59	+/–
> Ясно, примеров нет и не будет. Примеров чего? Я устал уже пытаться угадать то, что вы имеете ввиду. Каждый раз предлагаю несколько вариантов, и ни разу не получаю подтверждения вида "да, я вот именно это имею ввиду".  Попробую угадать ещё раз: - Интересует пример программы, написанной на Расте, но использующий libc? Это - практически все программы, написанные на Расте под Линукс, т.к. растовкий std для Линукса подстроен над libc - Или неиспользующие libc, но при этом под Линукс? Таких не знаю, и скорее всего если они есть, то очень мало, просто потому, что это бессмысленно - отказаться от std, но при этом написать что-то полезное? Хотя технически это возможно, т.к. для Раста делают кучу no_std библиотек, т.е. таких, которые не зависят от растовского std. Обычно их делают для эмбеда, но ничто не мешает применять их (и применяют) в любом окружении. Более того, считается, что если твоя либа no_std - то это более козырно, чем если она не-no_std, т.к. её переиспользуемость повышается. - Или интересуют программы под Редокс, которые используют напрямую редоксовское API, но при этом опционально могут для чего-то вызвать ещё и relibc? Вообще без понятия, это ж фактически research-проект, под который очень мало чего есть, а уж тем более найти человека, которые оттуда какие-то практические примеры знает - это надо очень постараться. Но опять-таки, чисто из технического устройства ничто такому подходу не противоречит. - Или какой-то другой вариант? Сформулируйте чётко, тогда будет конкретный ответ. > $ ldd `which gitea` Оно будет залинковано на libc если собиралось через cgo, а не go. Кроме того, пишут, что до версии го 1.5 оно линковалось к libc ради DNS-а, но потом и это выпилили. У меня стоит по-моему ровно одна программа, написанная на го - docker, и оно "not a dynamic executable". Можно конечно предположить, что либц там просто внутри, но я натыкался на высказывание о том, что Гугл именно сам для го запилил обращение к сисколлам, и либц они вообще не используют, кроме каких-то частных случаев, а то и вообще без. > У меня больше нет к Вам вопросов. Да это ради бога. :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #410 Ответы: #413

412. Сообщение от KroTozeR (ok), 30-Дек-20, 18:32	+/–
> Я думаю вы неправильно смотрите: нужно искать мотив не снаружи, а изнутри. > Рано или поздно на Rust будут писать ОСи, и первой уже > оказался Redox. В экосистеме раста идет конкуренция среди разработчиков за "первое > место" и прочие блага, которые оно способно принести. В таком случае ОС на Rust должна предъявить какие-то преимущества. Язык СИ достаточно универсален, но писать проще на C++. Архитектура драйверов под Linux проще для понимания, чем то же самое для Windows. Однако, код модулей ядра Linux вызывает желание рыдать... Не всех, конечно, бывают и адекватные... Иногда... И язык СИ тут ни в чём не виноват. Сама культура разработчиков порождает эти простыни смешанного в кучу кода без каких-либо адекватных комментариев. При разработке натыкаешься на отсутствие достаточной документации и просто лютейший снобизм "ядерщиков". Достаточно, к примеру, просто написать ОС с совершенно иным подходом к организации кода. Тогда люди будут заменять тот же GNU/Linux на Embedded новой ОС-ю просто мотому, что писать модули под неё проще и удобнее. Попутно распиарят язык программирования. Кстати, под винду драйверы можно и на C++ писать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #400

413. Сообщение от n00by (ok), 31-Дек-20, 06:54	+/–
> Кроме того, пишут Забейте. Вы ещё предыдущим своим сообщением убедили меня, что верить Вам не стоит. Остальное не читал, извините, что не ответил.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #411 Ответы: #414

414. Сообщение от Wilem82 (?), 31-Дек-20, 12:43	+/–
> убедили меня, что верить Вам не стоит Верить? Мда, худшее, что я ожидал для себя из данной дискуссии - это мне бы предоставили контр-аргументы доказывающие, что я неправ. Ну постыдился бы немного, сказал бы спасибо за объяснения и ушёл просветлённым.  А вы мне про веру. Ну мы же не в церкви, при чём тут вера? Я, правда, так и не понял что именно вы хотели узнать, и все мои попытки это выяснить, уточняющие вопросы и так далее были проигнорированны. Так что видимо и предмета разговора нет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #413 Ответы: #417

415. Сообщение от burjui (ok), 02-Янв-21, 03:19	+/–
ML - тоже не чисто функциональный язык, в отличие от Haskell.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #291

416. Сообщение от burjui (ok), 02-Янв-21, 03:28	+/–
А разработчики не обязаны лично тебе доказывать, что у них причины "правильные".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #396

417. Сообщение от n00by (ok), 02-Янв-21, 11:42	+/–
>> убедили меня, что верить Вам не стоит > Верить? Мда, худшее, что я ожидал для себя из данной дискуссии - > это мне бы предоставили контр-аргументы доказывающие, что я неправ. Во-первых, что бы я с Вами дискутировал, Вам необходимо понимать, о чём вообще речь: что такое связывание, как оно работает, порядок загрузки модулей и так далее. Во-вторых, бремя доказательства исходного Вашего утверждения лежит на Вас. Достаточно было привести хоть один пример, но Вы решили поиграть в игру "и чо?"
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #414 Ответы: #419

418. Сообщение от anonymous (??), 02-Янв-21, 18:13	+/–
Memory leaks are memory safe! И хотя это кажется абсурдным, но это правда.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #368

419. Сообщение от Wilem82 (?), 02-Янв-21, 20:23	+/–
> исходного Вашего утверждения Какого?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #417 Ответы: #420

420. Сообщение от n00by (ok), 03-Янв-21, 14:29	+/–
>> исходного Вашего утверждения > Какого? Перечитайте ветку, коль с памятью плохо.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #419

421. Сообщение от Аноним (421), 11-Мрт-21, 16:37	+/–
Получается что наличие unsafe в коде позволило выявить проблему безопасности? Потенциальное CVE. Ведь люди которые искали ошибки смотрели на блоки unsafe. Надо же, я думал что один unsafe написал в коде и все - считай что в С++ попал, а мог и не учить раст даже. НУ ничего, там наверно осталось полно утечек памяти, вот порадуюсь когда у кого-нибудь сервер крашнется. Когда-нибудь. Пусть и без privilege gain..
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #144

422. Сообщение от Аноним (422), 12-Мрт-21, 18:36	+/–
У нас в Украине ПриватБанк начинает внедрять в банкоматы Linux. Нахрена им старый QNX
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #407

423. Сообщение от ИмяХ (?), 28-Мрт-21, 05:24	+/–
Ассемблерная вставка внутри unsafe это эталон безопасности.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #391

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

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