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

"Выпуск глобальной децентрализованной файловой системы IPFS 0.8"	+/–
Сообщение от opennews (??), 24-Фев-21, 18:27
Представлен выпуск децентрализованной файловой системы IPFS 0.8 (InterPlanetary File System), образующей глобальное версионированное хранилище файлов, развёрнутое в форме P2P-сети, образованной из систем участников. IPFS комбинирует идеи, ранее реализованные в таких системах, как  Git, BitTorrent, Kademlia, SFS и Web, и напоминает единый "рой" BitTorrent (пиры, участвующие в раздаче), обменивающийся Git-объектами. IPFS отличается адресацией по содержимому, а не месту размещения и произвольным именам. Код эталонной реализации написан на языке Go и распространяется под лицензиями  Apache 2.0 и MIT... Подробнее: https://www.opennet.dev/opennews/art.shtml?num=54644
Ответить | Правка | Cообщить модератору

Сообщения

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

1. Сообщение от Аноним (1), 24-Фев-21, 18:27	–17 +/–
Удобно из браузера скачивать, нужно только найти толпу дурачков, которые захостят тебе контент на куче нод. К сожалению, го ограничивает применимость, но ничего не поделать. Так в принципе очень удобно: по хэшу получаешь доступ к определённым файлам определённых версий.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #26, #111

2. Сообщение от Вопль_в_пустыне (?), 24-Фев-21, 18:35	–5 +/–
Так то штука классная, но с таким убогим интерфейсом она годна для кучки гиков, когда разрабы осознают что надо быть ближе к массовому юзеру...
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #6, #84

3. Сообщение от Аноним (3), 24-Фев-21, 18:39	+/–
В чем отличия от Freenet?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #13, #120

4. Сообщение от Аноним (4), 24-Фев-21, 18:40	+/–
"для организации работы сайтов, не привязанных к серверам" Было бы интересно почитать об этом более подробно.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #11, #61

5. Сообщение от Moebius (ok), 24-Фев-21, 18:40	–4 +/–
Дубликацию данных снова не устранили.
Ответить | Правка | Наверх | Cообщить модератору

6. Сообщение от Аноним (6), 24-Фев-21, 18:41	–1 +/–
Кому надо?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #7

7. Сообщение от Аноним (7), 24-Фев-21, 19:01	+1 +/–
Тому, кто хочет создать продукт, которым кто-то (кроме автора) будет пользоваться
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #19, #23

8. Сообщение от Аноним (8), 24-Фев-21, 19:18	+4 +/–
Благодаря наличию публичных гейтвеев очень удобно публиковать файлы: ipfs add some-file Получил хеш и кинул ссылку на https://ipfs.io/ipfs/...
Ответить | Правка | Наверх | Cообщить модератору

9. Сообщение от Аноним (9), 24-Фев-21, 19:19	–8 +/–
go go лесом go
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #20

10. Сообщение от Аноним (9), 24-Фев-21, 19:20	–3 +/–
ipfs pin remote service add mysrv сразу видно, системдысты.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #114

11. Сообщение от Аноним (-), 24-Фев-21, 19:22	+6 +/–
https://docs.ipfs.io Чем ещё помочь, даже не знаю
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #60

12. Сообщение от BrainFucker (ok), 24-Фев-21, 19:25	+/–
Проблему потребления памяти исправили? А то оно жрало так будто трижды на Java написано.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #27, #35, #68

13. Сообщение от Сейд (ok), 24-Фев-21, 19:31	+1 +/–
В ней небольшое время ожидания. Что-то типа Psiphon. Не сравнить с Freenet или RetroShare.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #66

14. Сообщение от rvs2016 (ok), 24-Фев-21, 19:32	+/–
Вот надо мне на своём сайте файл (например, картинку) разместить не так, как обычно это делается, а в распределённой сети IPFS так, чтобы потом пользователи сайта могли получать файл этот файл не из одного веб-сервера, а из этой самой распределённой сети IPFS. Как это сделать?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #16, #54, #72

15. Сообщение от Аноним (15), 24-Фев-21, 19:33	+/–
Какие у сабжа кейсы по использованию?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #17, #18, #69

16. Сообщение от Аноним (1), 24-Фев-21, 19:45	+5 +/–
Поднимаешь кучу нод, добавляешь на них хэш твоего файла, добавляешь на сайт ссылку на хэш через какой-нибудь ipfs.infura.io и всё. Опыт у пользователей будет различаться, в зависимости от географического расположения ноды. Как синхронизировать обновления нод додумай сам.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14

17. Сообщение от Аноним (1), 24-Фев-21, 19:46	+3 +/–
Версионированные торренты.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15

18. Сообщение от Аноним (19), 24-Фев-21, 19:49	–3 +/–
Для неграмотных, которые не осилили статью - бесполезен.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15

19. Сообщение от Аноним (19), 24-Фев-21, 19:52	+7 +/–
Линус за свою щизнь не задизайнил ни одного графического интерфейса. Но, внезапно, его разработками пользуются.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #52

20. Сообщение от Аноним (19), 24-Фев-21, 19:55	+/–
Любмтель еженедельных CVE?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9 Ответы: #25, #29, #34, #36

21. Сообщение от Аноним (-), 24-Фев-21, 19:59	+3 +/–
Ано анонимно?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #22, #24, #30, #128

22. Сообщение от Аноньимъ (ok), 24-Фев-21, 20:03	+5 +/–
Нет. I2p транспорт так и неосилили. Более того, зайдя не на тот ipfs сайт рискуете оказаться распространителем и хранителем очень незаконных материалов.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21 Ответы: #33, #57

23. Сообщение от Аноним (6), 24-Фев-21, 20:03	+2 +/–
Ну так пусть он и будет, а автору то зачем.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7

24. Сообщение от Аноньимъ (ok), 24-Фев-21, 20:03	+1 +/–
Короче это публичный торрент для HTML.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21 Ответы: #28

25. Сообщение от Dzen Python (ok), 24-Фев-21, 20:31	–4 +/–
Уж лучше закрываемые еженедельные CVE, чем хрен-пойми-что-там-копмилятор-наворотил, для которого надежных методов поиска этих самых уязвимостей нет
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20 Ответы: #67

26. Сообщение от еман (?), 24-Фев-21, 20:32	+4 +/–
>го ограничивает применимость тут конкретнее. где и в чём ограничивает go?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #31

27. Сообщение от пох. (?), 24-Фев-21, 20:36	–5 +/–
Оно на игогого написано, как еще оно должно ее жрать?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12

28. Сообщение от пох. (?), 24-Фев-21, 20:37	+2 +/–
Почему только хтмл? Прон тоже можно - но только одобряемый товарищмайором.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #24 Ответы: #39

29. Сообщение от Аноним (-), 24-Фев-21, 20:40	+/–
Ну и фиг с ними, при правильно собранной системе - в худшем случае вывалит трейс, вот только зерадей просто так тебе еще фиг кто падарит, так что все эти пугалки для галки ^_^
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20

30. Сообщение от Аноним (30), 24-Фев-21, 20:44	+1 +/–
анонимно, для людей, для опенсорса ... го . ну какбы несовместимо по определению, ты еще поди проконтролируй при каждом запуске не подменили ли любимый модуль на гитпомойке. ананимнасть, ха три раза
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21

31. Сообщение от Аноним (1), 24-Фев-21, 20:52	–15 +/–
Причина та же, что и с java. Если оно нигде в стеке не используется, этот кусок будет сбоку пришлёпан. В лучшем случае, в худшем -- придётся как-то интегрировать через костыли и подпорки.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26 Ответы: #51, #73

32. Сообщение от Аноним (30), 24-Фев-21, 20:53	+3 +/–
А сейчас вообще модно стало унижать пользователей. Не торрент - а вебторрент, чтоб webrtc еще паспорт из тумбочки вытягивало. Сильно много роботов стало - унизим же своих пользователей да заставим жабаскриптовую капчу проходить, желательно гуглокапчу, чьхать на ихнюю безопасность, главное чтоб сайтек индексировался для сапы. как бы еще унизить, о ! давай man in middle запилим для юзера, пусть все о себе выкладывает на cloudflare. программы на го, тем более от макак вообще не стоит запускать на компутерах.. прямо вот век технологических прорывов и здравого смысла.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #42

33. Сообщение от Аноним (33), 24-Фев-21, 20:59	+1 +/–
> распространителем Есть настройка, чтобы распространялись только pinned.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22

34. Сообщение от Аноним (9), 24-Фев-21, 21:48	–1 +/–
Обладатель интеллекта - чловек перешедший на сдедующую ступень эволюции после обезьяны.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20 Ответы: #79

35. Сообщение от Ordu (ok), 24-Фев-21, 22:11	+/–
Ссылки на issue есть? Было бы любопытно почитать про проблемы потребления памяти в go программах. Пускай даже и в одной программе.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12 Ответы: #37, #102

36. Сообщение от Аноним (36), 24-Фев-21, 22:16	+/–
А причем тут CVE? Или ты хочешь рассказать о непогрешимости rust и go?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20 Ответы: #124

37. Сообщение от FractaL (ok), 24-Фев-21, 22:18	–3 +/–
Воистину святыми и непогрешимыми Rust и Go да вознесёмся мы в небеса. А чертям место в аду.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #35 Ответы: #38

38. Сообщение от Ordu (ok), 24-Фев-21, 22:35	+3 +/–
> Воистину святыми и непогрешимыми Rust и Go да вознесёмся мы в небеса. > А чертям место в аду. Я просил ссылку на issue, а не проповедь. И уж тем более не от тебя -- ты не настоящий фрактал, и у тебя квалификации не хватает даже на то, чтобы троллить сишными дырянями. Квалификация настоящего фрактала весьма сомнительна, но тебе бы вообще молчать зубами к стенке.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37 Ответы: #40, #43

39. Сообщение от Аноньимъ (ok), 24-Фев-21, 22:51	+/–
> Почему только хтмл? Прон тоже можно - но только одобряемый товарищмайором. Можно конечно, я к тому что основная идея этой штуки в первую очередь сайты.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28 Ответы: #71

40. Сообщение от Аноним (40), 24-Фев-21, 23:18	–2 +/–
Сари какой агрессивный. У тебя же рак любимый ? Чего в го.. влезаешь так яро
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #38 Ответы: #41

41. Сообщение от Ordu (ok), 24-Фев-21, 23:38	+1 +/–
> Сари какой агрессивный. У тебя же рак любимый ? Чего в го.. > влезаешь так яро Потому что менеджмент памяти -- это проблема Computer Science, которая не разрешима в общем случае теоретически, и, как следствие, неразрешима практически. А это значит, что эта проблема даёт отличные возможности расти над серой массой быдлокодеров, знать расположение многих граблей и владеть многими трюками, позволяющими этих граблей избегать. Причём, поскольку проблема неразрешима теоретически, то эти знания/умения/навыки останутся ценными десятилетиями, эти знания пересекают границы языков. Эти знания как раз очень ценны, в отличие от знания каких-то там языков: языки приходят и уходят, а фундаментальные проблемы остаются. И вот, кажется у меня появился шанс выловить интересный пример проблем с менеджментом памяти в языке с gc. GC очень интересен в этом плане, потому что там очень жёсткие плюсы и минусы, причём все попытки их сравнивать -- увы и ах -- остаются на уровне размахивания руками, по разным причинам. И я такой ооо, уже слюни текут от предвкушения... Но тут ко мне в комменты лезут какие-то хомячки, воюющие за/против каких-то там языков программирования. Естественно я агрессивен.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #40 Ответы: #44, #47, #81

42. Сообщение от Аноним (44), 24-Фев-21, 23:48	–3 +/–
Ох как я с тобой согласен. Надо ещё веб на rust переписать, чтобы WebRust'ия стала.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32 Ответы: #58

43. Сообщение от Аноним (44), 24-Фев-21, 23:51	+/–
Типа у настоящего фрактала есть хоть какая-то квалификация. Насмешил. Тем более он открытым текстом писал сам что квалификации у него нет от слова совсем и его опыт в программировании равено нулю.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #38 Ответы: #46

44. Сообщение от Аноним (44), 24-Фев-21, 23:54	–3 +/–
> не разрешима в общем случае теоретически, и, как следствие, неразрешима практически. А это значит, что эта проблема даёт отличные возможности расти над серой массой быдлокодеров Ты смотри как вырос то. Это ты так на игогошке наскакался или растишки обожрался. Ростун ты наш, светлый разум блин. Тот-то у тебя проблема не разрешима а у всех разрешима. :D Кто тут быдлокодер хм..
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #41 Ответы: #48

46. Сообщение от Ordu (ok), 25-Фев-21, 00:06	+/–
> Типа у настоящего фрактала есть хоть какая-то квалификация. Насмешил. знаю. Я не наблюдал его комментов, которые бы позволяли судить. > Тем более он открытым текстом писал сам что квалификации у него нет > от слова совсем и его опыт в программировании равено нулю. Может быть, но я тоже такое могу написать при определённых условиях, и поэтому доверять таким словам я бы не стал.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #43

47. Сообщение от Аноним (-), 25-Фев-21, 00:06	+/–
> Потому что менеджмент памяти -- это проблема Computer Science, которая не разрешима в общем случае теоретически, и Это вообще с каких таких пор в CS рубятся на предмет неразрешимых теоретически проблем с памятью ? Вот это вот вообще не кс проблема. Решений как автоматически освобождать память миллионы и gc, все правильно - одна из них, хоть и далеко не самая лучшая. Т.е главная проблема, как сказали маркетолухи - забывают освободить память, я правильно понимаю ?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #41 Ответы: #49

48. Сообщение от Ordu (ok), 25-Фев-21, 00:15	+2 +/–
> Тот-то у тебя проблема не разрешима а у всех разрешима. :D Кто > тут быдлокодер хм.. Ты б Кнута хотя б почитал, а? Он разбирает там вопрос динамического выделения памяти, и объясняет почему он неразрывно связан с проблемами. Кнут, понятно, древность уровня палеонтологии, и, читая его, стоит выдерживать определённый уровень критичности восприятия, тем более что он, по складу ума, больше академический работник, нежели профессиональный программист, но ты всё ж открой и почитай. Если Кнут с его математикой тебе не указ, если тебе ближе исследования социологического уровня, то загляни в статистику по частоте встречаемости багов типа use-after-free, double-free и memory-leak. Gc, допустим, от первых двух избавляет, но от memory-leak -- нет. И ежели что-то подобное произошло в программе на Go, то интересны детали этого. Я подозреваю, что они зарыты в goroutine'ах, но хочу убедиться в этом, и просмаковать во всех нюансах.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #44 Ответы: #77, #78

49. Сообщение от Ordu (ok), 25-Фев-21, 00:16	+1 +/–
>> Потому что менеджмент памяти -- это проблема Computer Science, которая не разрешима в общем случае теоретически, и > Это вообще с каких таких пор в CS рубятся на предмет неразрешимых > теоретически проблем с памятью? Как минимум, со времён первого издания TAOCP Кнута. Причём в TAOCP всё подкреплено ссылками на статьи по теме, что наводит на мысль о том, что ещё до Кнута люди тоже рубились.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #47 Ответы: #53

51. Сообщение от Аноним (51), 25-Фев-21, 01:17	+5 +/–
В отличии от java тут не требуется отделтный jvm. На выходе же простой elf бинарник. А если ещё не требуется CGO то бинарник не будет привязан к libc и будет переносимым между разными системами и дистрибутивами.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31 Ответы: #55

52. Сообщение от bergentroll (ok), 25-Фев-21, 01:25	+/–
> Линус за свою щизнь не задизайнил ни одного графического интерфейса. Да, но возможно нет. https://subsurface-divelog.org
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19 Ответы: #62

53. Сообщение от Аноним (53), 25-Фев-21, 02:43	–2 +/–
> Как минимум, со времён первого издания TAOCP Кнута. Причём в TAOCP всё > подкреплено ссылками на статьи по теме, что наводит на мысль о > том, что ещё до Кнута люди тоже рубились. ага, зопелю вам нью делит, ой блин, ни спасло, давайте ище по три рубля, бум решать дальше. сколько можно одно и тоже человечиство в цикле проходит, закостенелые профессора они всегда будут такими, но только не надо вот этого вот - расстрелять всех, книги сжечь , теперь песать все будут раком , а кто не улыбается - морить в дыры. если говорят разумные люди что руки надо мыть перед операцией, а не после, никак не слышат
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #49 Ответы: #56

54. Сообщение от Аноним (54), 25-Фев-21, 02:58	+1 +/–
Для этого существует cluster.ipfs.io. Создаешь кластер, дальше приглашаешь заинтересованных присоединиться к кластеру или проднимаешь узлы на своих ресурсах. Например, основные сайты IPFS и Protocol Labs как раз доступны через IPFS и объеденены в общий кластер. Потому при загрузке страниц сайта по IPFS, все шустро и почти аналогично вебу. https://collab.ipfscluster.io/ - тут список некоторых публичных кластеров. Другой вариант: платные сервисы вроде https://pinata.cloud/
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14

55. Сообщение от Аноним (1), 25-Фев-21, 03:22	+1 +/–
Скажем, graalvm тоже вполне умеет продуцировать бинари. И даже GC выкидывает, опционально. Если огромный вонючий бинарь заменить на какой-нибудь сферический flatpak, то инфраструктура только выиграет - хотя бы видно что там в этом флатпаке, можно контроллировать процесс сборки и обновления содержимого. Так что нет, разницы в этом плане тут нет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #51 Ответы: #64

56. Сообщение от Ordu (ok), 25-Фев-21, 04:30	+1 +/–
Когда тебе заказчик задаёт вопросы типа: "твой код не течёт? Чем докажешь?", что ты отвечаешь ему? "Мамойклянус"? Или "я тестами код покрыл, как соседа своего жену каждую ночь покрываю"? Или что ты отвечаешь? Может "слющай,не нравится, проходи мимо, не мешай продажам, а"? Тебе не кажется, что это ответы уровня веб-макак или даже маркетологов, и совершенно не к лицу уважающему себя инженеру? А между прочим, тот ответ про тесты, это один из лучших вариантов доступных программисту. Его можно разнообразить, добавив туда слов фаззинг, юнит тесты, valgrind, статический анализ, … но все эти слова ничего не доказывают, лишь свидетельствуют, что всё не совсем безнадёжно. Программирование как род деятельности находится в зачаточном состоянии, вылезти с уровня кустарных ремесленников программистам так и не удалось. А тебе, судя по твоему отрицанию существующих признанных проблем, даже до уровня ремесленника не удалось дотянуться.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #53 Ответы: #82

57. Сообщение от Lex (??), 25-Фев-21, 06:00	+/–
> хранителем очень незаконных материалов Как будто туда заходят за чем-то еще
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22 Ответы: #59

58. Сообщение от mozilla dev (?), 25-Фев-21, 09:38	+/–
мы попытались... эта сволочь нас - выбросила за борт, представляете!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42

59. Сообщение от Аноньимъ (ok), 25-Фев-21, 12:56	+3 +/–
Сеть позиционируется создателями как замена обычному интернету.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #57

60. Сообщение от asdf (?), 25-Фев-21, 13:31	+1 +/–
очевидно переводом ))))
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11

61. Сообщение от JL2001 (ok), 25-Фев-21, 13:36	+/–
> "для организации работы сайтов, не привязанных к серверам" > Было бы интересно почитать об этом более подробно. я так понял, есть две интерпритации "не привязано к серверам": 1) весь сайт строится на замене https:// на ipns:// или dweb://ipns/ и живёт в условиях браузеров с эдонами для dweb или с с указаными локальными/глобальными нодами ipns 2) js-ipns (реализация ноды ipns на жаваскрипте) запускается на главной странице, доступной в обычном интернете, и далее пункт 1
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4

62. Сообщение от Аноним (-), 25-Фев-21, 13:40	+/–
эта типа должно выглядеть умно ?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #52 Ответы: #63

63. Сообщение от bergentroll (ok), 25-Фев-21, 13:44	+1 +/–
> эта типа должно выглядеть умно ? Что именно, что Л. Торвальдс написал графическое приложение? Ну, он умный, да.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #62 Ответы: #65

64. Сообщение от еман (?), 25-Фев-21, 13:47	+/–
> Скажем, graalvm тоже вполне умеет продуцировать бинари. И даже GC выкидывает, опционально. > Если огромный вонючий бинарь заменить на какой-нибудь сферический flatpak, то инфраструктура > только выиграет - хотя бы видно что там в этом флатпаке, > можно контроллировать процесс сборки и обновления содержимого. Так что нет, разницы > в этом плане тут нет. слишком толсто. RTFM[/thread]
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #55 Ответы: #70

65. Сообщение от Аноним (-), 25-Фев-21, 13:52	+/–
Тут ты прав, это была горячка с моей стороны. Линус божественный UI дизигнер, чего только стоят эти строки: Do you know how to make the list entries by right-justified? Right now the "ft" and "min" columns are numeric, but left-justified, which is butt ugly. Columns of numbers should be right-justified. https://github.com/subsurface/subsurface/pull/13 особенно про gtk3 великолепные стихи
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #63

66. Сообщение от JL2001 (ok), 25-Фев-21, 13:57	+3 +/–
> В ней небольшое время ожидания. Что-то типа Psiphon. Не сравнить с Freenet > или RetroShare. совершенно не понимаю, что у ipfs общего с Psiphon > Psiphon – инструмент обхода интернет-цензуры от Psiphon Inc. Он использует VPN, SSH и HTTP-прокси для доступа к заблокированным ресурсам. с Freenet не работал ipfs - магнитный торент с возможностью создачи именованых каналов передачи байт, встроеным типо_днс и развитым апи/командной тулзой для управления всем этим имеет проксю для доступа к данным внутри сети по http и управления нодой имеет js-ipfs - реализацию на жаваскрипте и можно запустить ноду прям в браузере и использовать её для работы с сетью имеет некие подвижки/стандарты для прописывания адресов сети прямо в обычные dns есть уже дофига всяких приложений, использующих сеть, как распределённое хранилище данных/бд чата и тд единственный минус, что не даёт лично мне заменить торенты на ipfs - невозможность в одну команду скачать файл с ipfs и начать его раздачу (и чтоб без дублирования занятого места на винте) заявке на гитхабе уже года 3-4, похоже разрабов это не сильно интересует а ещё есть фичебага или багофича - один и тот же файл может иметь разные хеши (магниты) -: см выше - есть шанс, что скачав файл - добавишь ты файл в раздачу с другим хешом +: нельзя забанить файл - ему сделают другой хеш и снова раздадут я не вижу никаких стандартов/стремлений от разрабов по уменьшению "мусора" вида "при добавлении файла разобъём мкв на отдельные дорожки и теги, дабы мкв с одной дорожкой и с 10ю (включая ту самую)+тегами были в едином общем облаке хешей"
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13 Ответы: #74, #121

67. Сообщение от JL2001 (ok), 25-Фев-21, 13:59	+/–
> Уж лучше закрываемые еженедельные CVE, чем хрен-пойми-что-там-копмилятор-наворотил, > для которого надежных методов поиска этих самых уязвимостей нет а что, в сишечке компилятор воротит только то, что боженька и три закона робототехники заповедовали?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25 Ответы: #113

68. Сообщение от JL2001 (ok), 25-Фев-21, 14:02	+/–
> Проблему потребления памяти исправили? А то оно жрало так будто трижды на > Java написано. а у меня не жрало и не жрёт конкретика или ссылка на багу - в студию иль провакатор и дезинформатор?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12 Ответы: #103

69. Сообщение от JL2001 (ok), 25-Фев-21, 14:08	+/–
> Какие у сабжа кейсы по использованию? некое подобие ответа https://www.opennet.dev/openforum/vsluhforumID3/123371.html#66
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15

70. Сообщение от Аноним (1), 25-Фев-21, 14:09	+1 +/–
Нет, ты.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #64

71. Сообщение от JL2001 (ok), 25-Фев-21, 14:12	+/–
>> Почему только хтмл? Прон тоже можно - но только одобряемый товарищмайором. > Можно конечно, я к тому что основная идея этой штуки в первую > очередь сайты. я не знаю, почему многие так думают - из-за поддержки ноды ipfs протокола http для доступа к данным сети? из-за существования js-ipfs? сама сеть никак на html не заточена, на сколько мне известно
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39

72. Сообщение от sage (??), 25-Фев-21, 14:23	+2 +/–
Вариантов несколько: 1. Если у вас весь сайт доступен через IPFS, ничего дополнительно делать не нужно, достаточно вставить относительную ссылку. 2. Если у вас обычный веб-сайт (не в IPFS), и вы хотите вставить картинку ссылкой в IPFS, следует указать какой-либо публичный шлюз, а пользователи с расширением IPFS Companion или браузером Brave будут открывать её через свои локальные шлюзы. 3. Поднять собственные шлюзы и вставить картинку HTML-тегом picture со вложенным тегом source с несколькими ссылками.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14 Ответы: #75, #92

73. Сообщение от Аноним (73), 25-Фев-21, 14:31	+1 +/–
> Причина та же, что и с java. Если оно нигде в стеке > не используется, этот кусок будет сбоку пришлёпан. В лучшем случае, в > худшем -- придётся как-то интегрировать через костыли и подпорки. То же можно сказать про любой язык, даже про Си. Например, если весь проект на Джаве, а одна библиотека на Си, она будет сбоку пришлепана и интегрирована через костыли и подпорки (FFI, необходимость сборки под разные архитектуры).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31 Ответы: #93

74. Сообщение от Сейд (ok), 25-Фев-21, 14:55	+/–
Небольшое время ожидания, я же написал.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #66 Ответы: #122

75. Сообщение от rvs2016 (ok), 25-Фев-21, 15:43	+/–
> Вариантов несколько: > 1. Если у вас весь сайт доступен через IPFS, ничего дополнительно делать > не нужно, достаточно вставить относительную ссылку. > 2. Если у вас обычный веб-сайт (не в IPFS), и вы хотите > вставить картинку ссылкой в IPFS, следует указать какой-либо публичный шлюз, а > пользователи с расширением IPFS Companion или браузером Brave будут открывать её > через свои локальные шлюзы. > 3. Поднять собственные шлюзы и вставить картинку HTML-тегом picture со вложенным тегом > source с несколькими ссылками. Сайт обычный, не в IPFS. Внутрь его страниц просто некоторые объекты типа картинок надо грузить из IPFS. И при этом не хочется же пользователям говорить типа - установите себе приблуды (расширения, ноды там всякие и т.п.), т.к. часть из них этого просто не поймёт, а часть не будет с этим заморачиваться, а просто пойдёт на другой сайт, где "всё работает и так". Поэтому все эти ноды хорошо бы запускать каким-нибудь джава-скриптом или прямо самими браузерами внутри пользовательских браузеров. Больше всего таким требованиям пока подходит браузер Brave. Им в деле загрузки объектов из IPFS повезёт. Остальные, горемычные, будут грузить объекты в страницы старинным дедовским из 90-х годов способом.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #72 Ответы: #87

76. Сообщение от odin314 (ok), 25-Фев-21, 16:24	+/–
https://ipfs.io/ipfs/QmUUPSPdbPK5sSxZVhjH7adYZ4QGpvRrUVRc6ht...
Ответить | Правка | Наверх | Cообщить модератору

77. Сообщение от Аноним (77), 25-Фев-21, 16:36	+/–
> Ты б Кнута хотя б почитал ... Я то почитал, потому у меня разрешима. А ты видно не читал.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #48 Ответы: #80

78. Сообщение от Аноним (79), 25-Фев-21, 16:56	+/–
Перестаём быдлокодить на быдло языках, перестаём ныть. Уменьшаем количество смузи в крови и начинаем читать того-же кнута внимательнее, потом думать. И о чудо, всё решаемо. Не забудь сжечь все толмуды по go, rust и прочей пропоганде великого и светлого. И жизнь станет интересее, приятнее и окажется что всё решаемо.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #48

79. Сообщение от Аноним (79), 25-Фев-21, 16:56	–1 +/–
А вот и первый мартишкин минус
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #34

80. Сообщение от Ordu (ok), 25-Фев-21, 17:56	+1 +/–
>> Ты б Кнута хотя б почитал ... > Я то почитал, потому у меня разрешима. А ты видно не читал. Ты с начала читал? Ты уверен, что ты правильно понял, что значит "разрешима"? Там первые две главы ключевые, одна математический ликбез, вторая cs-ликбез. Без них остальные главы сложно понять наверное.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #77 Ответы: #125

81. Сообщение от Sw00p aka Jerom (?), 25-Фев-21, 18:13	+1 +/–
>Потому что менеджмент памяти -- это проблема Computer Science, которая не разрешима в общем случае теоретически, и, как следствие, неразрешима практически. Кто автор сего доказательства неразрешимости? Ссылочку в студию плиз.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #41 Ответы: #83

82. Сообщение от Sw00p aka Jerom (?), 25-Фев-21, 18:19	+/–
>"твой код не течёт? Чем докажешь?" Оценкой "пространственной" сложности алгоритмов используемых в программе. Текучесть памяти это не проблема CS, и если бы была она не разрешима, то приведите пример где текет память и это невозможно исправить. пс:33034
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #56 Ответы: #85, #126

83. Сообщение от Ordu (ok), 25-Фев-21, 18:53	+/–
>>Потому что менеджмент памяти -- это проблема Computer Science, которая не разрешима в общем случае теоретически, и, как следствие, неразрешима практически. > Кто автор сего доказательства неразрешимости? Ссылочку в студию плиз. Не, давай лучше ты дашь ссылку на доказательство разрешимости? Неразрешимость сводится к тому, что нет fool-proof способа менеджить память, которого хватит всем. Это не значит, между прочим, что такой способ невозможен в принципе, но он, как минимум, неизвестен общественности. Если ты считаешь, что знаешь такой способ, то расскажи его. Можно ссылкой. Я в каком-то соседнем комменте задал наводящие вопросы: как ты доказываешь про свой код, что там нет проблем с mm? Ты не доказываешь это заказчику? Ну ок, а себе ты это доказываешь как-то? В какой момент ты удовлетворённо откидываешься на спинку стула, и говоришь "ну вот, теперь код безбажен"? Что ты делаешь для этого? Вот когда тебе надо доказать асимптотическую сложность алгоритма, ты берёшь и доказываешь это. Когда тебе надо доказать, что проблема не разрешима алгоритмически, ты достаёшь с антресоли машину Тьюринга, сдуваешь с неё пыль, и доказываешь, и дальше уже не ты дурак, что не можешь написать решение задачи, а тот кто тебе такую задачу поставил дурак, потому что хочет Солнце с неба. Про алгоритмы не всё можно доказать, что хочется -- проблема останова, например, неразрешима в общем случае. Но про mm что ты можешь доказать? Ты знаешь алгоритм как детерминированно показать про любую программу наличие/отсутствие проблем с mm? Или ты просто _веришь_ в то, что ты можешь любую программу избавить от багов с mm за конечное время? На чём эта вера основана? На "мамой клянус"? Может у тебя хоть статистика есть, типа ты написал 100k строк кода, они широко используются 10+ лет, и там до сих пор не нашли ни одного бага с mm? На чём основана твоя вера?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #81 Ответы: #90

84. Сообщение от iPony129412 (?), 25-Фев-21, 18:56	+/–
Это так не работает. Можно вспомнить про P2P клиенты и страшные и сложные (для околодомохозяки актив/пасив, всякие пробросы это целое дело). Пользовались по тому что смысл был.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #112

85. Сообщение от Ordu (ok), 25-Фев-21, 19:37	+3 +/–
>>"твой код не течёт? Чем докажешь?" > Оценкой "пространственной" сложности алгоритмов используемых в программе. Текучесть > памяти это не проблема CS, Что значит "не проблема CS"? А что тогда "проблема CS"? И, в смысле, когда Кнут излагал разные способы менеджить память, и рассказывал как ни один из этих способов не решает проблему на 100%, это была не CS, а так, лирическое отступление? Не хреновое такое лирическое отступление? Я давно туда заглядывал, но навскидку там не меньше десятка страниц посвящено этому. А если ещё вспомнить про обсуждение проблем фрагментации кучи, то подозреваю там несколько десятков страниц наберётся. Не много для лирического отступления? wikipedia: > Computer science is the study of algorithmic processes, computational machines and computation itself.[1] As a discipline, computer science spans a range of topics from theoretical studies of algorithms, computation and information to the practical issues of implementing computational systems in hardware and software.[2][3] > Its fields can be divided into theoretical and practical disciplines. For example, > [бла-бла-бла] > The fundamental concern of computer science is determining what can and cannot be automated. Обрати внимание на последнее предложение: фундаментальный интерес CS в том, чтобы определить что может, и что не может быть автоматизировано. mm де факто автоматизируется. Может ли он быть автоматизирован или не может уже не важно: он _де_факто_ автоматизируется, программист не просит пользователя просматривать эпизодически кучу, и решать что там нужно, а что нет. А это значит, что mm находится в области интересов CS. В том числе и проблема "текучести кучи" находится в области интересов CS. > и если бы была она не > разрешима, то приведите пример где текет память и это невозможно исправить. Представь себе, что у тебя указатель на память хранится в двух разных местах. Есть код который обнуляет один из указателей, есть код который удаляет второй. В рантайме эти два куска кода могут выполнится в произвольном порядке, предсказать заранее невозможно. Как ты будешь решать, в каком из кусков кода вызывать free? Заведёшь ref_count? Окей, указателей больше, и несколько из них являются частью циклов в структурах. Что ты будешь делать? weak_ref? Но давай теперь докажи, что weak_ref расставлены правильно, и теперь тебе ещё придётся доказывать, что у тебя нет use-after-free, в силу неверной расстановки weak_ref. Или ты расчехлишь сборку мусора? Окей, докажи теперь, что указатели обнуляются всегда сразу, как только память становится ненужной, что никогда не случится такого, что ненужный объект переживёт сотню циклов сборки мусора. Тебе всё же удалось доказать? Но вот прилетел pull-request, мы его мергнули. Что теперь ты будешь делать? Поверишь автору PR, что он всё проверил, точна-точна? Или будешь доказывать отсутствие проблем с mm снова? Или может у тебя есть способы повторное доказательство провести проще, типа pr меняет три строчки кода, и мы на основании него создаём патч на доказательство? И нам не надо для этого опять изучать весь наш код целиком, чтобы ничего не упустить? Проблема разрешима в некоторых частных случаях. Скажем, если тебе удастся обойтись стеком и не использовать кучу, то проблема решаема. Если тебе удастся обойтись RAII и при этом хранить каждый указатель в единственном числе, то проблема решена. Можно эти ограничения ещё ослабить, и тем не менее оставить локальность доказательства корректности -- тебе не придётся анализировать весь код заново, после каждого патча на две строчки. Но как только ты через эти ограничения перешагиваешь, внезапно оказывается, что доказательство теряет локальность, и чтобы доказать, что вот этот вот free(p) не приводит к double-free, тебе придётся строить рассуждения о том, как ведут себя все 100k строк твоей программы, что никакой из возможных входов в программу не приводит к тому, что этот free(p) освобождает кусок памяти повторно. Решённая проблема перестаёт быть проблемой. Проблемы же с mm продолжаются, потому что проблема не решена в общем случае, и _это_ даёт возможность программисту быть квалифицированным специалистом, и выделятся из серой толпы быдлокодеров, которые не разобрались в вопросе в достаточной мере и не набили себе достаточного количества шишек.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #82 Ответы: #94

86. Сообщение от Аноним (86), 25-Фев-21, 20:14	+2 +/–
Честно говоря, из описания я подумал что IPFS позволит мне расшарить содержимое жёстких дисков в P2P сети, как в старом добром eDonkey. На пробу, выбрал директорию с мемчиками на 20 Гб, нажал Add to IPFS. Через пол часа (Go такой Go) в каталоге ~/.ipfs/blocks образовалось .data файлов на 20 Гб. Т.е. IPFS не просто расшаривает файл, а преобразует его в свой формат и хранит у себя в каталоге. Получается для того чтобы расшарить 10 Тб файлов мне нужно организовать 10 Тб свободного места под данные IPFS, в то время как в BitTorrent и ed2k достаточно пары сотен килобайт под метаданные. Можно, конечно же, удалить оригинальные файлы и остаться с кодированными бинарями на руках вместо картинок и видосов. Спрашивается: зачем эта поделка нужна?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #89, #95, #127

87. Сообщение от Аноним (-), 25-Фев-21, 22:06	+1 +/–
> Поэтому все эти ноды хорошо бы запускать каким-нибудь джава-скриптом или прямо самими браузерами внутри пользовательских браузеров. Так тоже можно: https://js.ipfs.io/
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #75 Ответы: #88

88. Сообщение от rvs2016 (ok), 25-Фев-21, 22:33	+/–
>> Поэтому все эти ноды хорошо бы запускать каким-нибудь >> джава-скриптом или прямо самими браузерами внутри >> пользовательских браузеров. > Так тоже можно: https://js.ipfs.io/ Какой-то там javascript ни разу не браузерный... :-(
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #87 Ответы: #91

89. Сообщение от Аноним (89), 25-Фев-21, 23:37	+/–
Чтоб дизмаралить тупых хомячков. Потыкает и будет орать как опеннетные школьники что все тлен и только в гугле облаке счастье.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #86

90. Сообщение от Sw00p aka Jerom (?), 26-Фев-21, 00:21	+1 +/–
> Не, давай лучше ты дашь ссылку на доказательство разрешимости? Окей, после того как пойму о доказательстве (не) разрешимости какой проблемы идет речь. Все по порядку. > Неразрешимость сводится к тому, что нет fool-proof способа менеджить память, которого хватит всем. Что значить "fool-proof" ? это что за определение? В переводе - "надежный" - что есть надежный? Мне нужны конкретные строгие определения "надежного способа", во-первых, во-вторых, определение "менеджить (управлять) память". А про "которого хватит всем" - промолчу, несерьезное высказывание. Мне нужна точная и строгая формулировка проблемы, чтобы я мог привести хоть какие-то доказательства. > Это не значит, между прочим, что такой способ невозможен в принципе, > но он, как минимум, неизвестен общественности. вот тут есть примеры проблем, посмотрите и опишите проблему которую имеете ввиду вы: https://ru.wikipedia.org/wiki/%D0%90%D0%... > Если ты считаешь, что знаешь > такой способ, то расскажи его. Можно ссылкой. Мне нужно определение проблемы, чтобы точно ответить. > Я в каком-то соседнем комменте задал наводящие вопросы: как ты доказываешь про > свой код, что там нет проблем с mm? Ты не доказываешь > это заказчику? Ну ок, а себе ты это доказываешь как-то? В > какой момент ты удовлетворённо откидываешься на спинку стула, и говоришь "ну > вот, теперь код безбажен"? Что ты делаешь для этого? проблемы с mm могут возникнуть если ты пишешь сам алгоритм mm. Я не могу понять что значить "что там нет проблем с mm". Мне нужна память - я прошу, мне дают если она есть, иначе иду лесом. Но никто с меня не спрашивает за то, что я ранее запросил и не вернул то, что взял. Могу вернуть, могу нет. В чем проблема? Мне по барабану кому еще там нужна будет память. ("Мне" - в контексте алгоритма или программы). Как доказываю? - выше в коменте ответил - оценкой "пространственной" сложности, это оценка необходимого и достаточного объема памяти и её зависимость. Я же могу посчитать сколько раз я запросил память для работы алгоритма. А вдруг мой алгоритм оказался избыточен, это разве "бажный" алгоритм? В прошлых дискуссиях про "течки" памяти мы так и не пришли к определению, что же это такое. > Вот когда тебе надо доказать асимптотическую сложность алгоритма, ты берёшь и доказываешь > это. Хмммм, сложность оценивается, а не доказывается. Это просто зависимость. Из той же википедии: https://ru.wikipedia.org/wiki/%D0%92%D1%... """ Рассмотрение входных данных большого размера и оценка порядка роста времени работы алгоритма приводят к понятию асимптотической сложности алгоритма. """ > Когда тебе надо доказать, что проблема не разрешима алгоритмически, ты > достаёшь с антресоли машину Тьюринга, сдуваешь с неё пыль, и доказываешь, > и дальше уже не ты дурак, что не можешь написать решение > задачи, а тот кто тебе такую задачу поставил дурак, потому что > хочет Солнце с неба. Перед тем как взять машину Тьюринга, надо четко  дать определение проблемы. С дурака что взять?. > Про алгоритмы не всё можно доказать, что > хочется -- проблема останова, например, неразрешима в общем случае. Но про > mm что ты можешь доказать? Как по мне, проблема останова это порочный круг, алгоритм который пройдется по всем алгоритмам по списку и должен будет остановится на том алгоритме, который не останавливается, - не остановится никогда. Такие же приколы бывают с рекурсиями при определенных условиях, когда нет условия ограничивающее глубину рекурсии. Или представьте себе алгоритм, который придумывает алгоритмы и исполняет их, наступает момент и этот алгоритм придумывает самого себя и исполняется, вопрос - остановится такой алгоритм? Про mm ничего сказать не могу, так как не вижу определение проблемы связанная с mm. > Ты знаешь алгоритм как детерминированно показать про любую программу наличие/отсутствие > проблем с mm? Алгоритм оценки "пространственной" сложность прост, банальные пошаговые замеры памяти (занимаемого пространства). > Или ты просто _веришь_ в то, что ты > можешь любую программу избавить от багов с mm за конечное время? Не вижу проблемы. У любого детерминированного алгоритма есть оценка. > На чём эта вера основана? На "мамой клянус"? Может у тебя > хоть статистика есть, типа ты написал 100k строк кода, они широко > используются 10+ лет, и там до сих пор не нашли ни > одного бага с mm? На чём основана твоя вера? Заставь дурака Богу молиться - сами знаете что... это про статистику и веру.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #83 Ответы: #98

91. Сообщение от JL2001 (ok), 26-Фев-21, 00:34	+/–
>>> Поэтому все эти ноды хорошо бы запускать каким-нибудь >>> джава-скриптом или прямо самими браузерами внутри >>> пользовательских браузеров. >> Так тоже можно: https://js.ipfs.io/ > Какой-то там javascript ни разу не браузерный... :-( но в браузере он точно могёт
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #88

92. Сообщение от JL2001 (ok), 26-Фев-21, 00:48	+/–
> 2. Если у вас обычный веб-сайт (не в IPFS), и вы хотите > вставить картинку ссылкой в IPFS, следует указать какой-либо публичный шлюз, а > пользователи с расширением IPFS Companion или браузером Brave будут открывать её > через свои локальные шлюзы. > 3. Поднять собственные шлюзы и вставить картинку HTML-тегом picture со вложенным тегом > source с несколькими ссылками. а можно в третье вписать второе? и туда же вписать обычный http ещё?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #72

93. Сообщение от Аноним (1), 26-Фев-21, 01:05	–4 +/–
Да, именно поэтому джава и течёт как не в себя.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #73 Ответы: #96

94. Сообщение от Sw00p aka Jerom (?), 26-Фев-21, 01:21	–1 +/–
> Что значит "не проблема CS"? А что тогда "проблема CS"? И, в > смысле, когда Кнут излагал разные способы менеджить память, и рассказывал как > ни один из этих способов не решает проблему на 100%, это > была не CS, а так, лирическое отступление? Интересно, следуя по Кнуту, я должен Тьюринга считать дураком за его "бесконечную" ленту? А теперь представьте, что есть "бесконечная" память, будут у вас проблемы с "менеджить память"? > Не хреновое такое лирическое > отступление? Я давно туда заглядывал, но навскидку там не меньше десятка > страниц посвящено этому. А если ещё вспомнить про обсуждение проблем фрагментации > кучи, то подозреваю там несколько десятков страниц наберётся. Не много для > лирического отступления? Сначала все свалим в "кучу", а потом будем придумывать 1000500 способов разгребания этой кучи, создавая из этого проблемы. Сущность человека такова. > Обрати внимание на последнее предложение: фундаментальный интерес CS в том, чтобы определить > что может, и что не может быть автоматизировано. :) Теория алгоритмов https://ru.wikipedia.org/wiki/%D0%A2%D0%... > mm де факто автоматизируется. Может ли он быть автоматизирован или не может > уже не важно: он _де_факто_ автоматизируется, программист не просит пользователя просматривать > эпизодически кучу, и решать что там нужно, а что нет. А > это значит, что mm находится в области интересов CS. В том > числе и проблема "текучести кучи" находится в области интересов CS. Если программист не знает оценки "пространственной" сложности собственных алгоритмов, то что тут сказать? Оценка сложности - обязательна!!! > Представь себе, что у тебя указатель на память хранится в двух разных > местах. Есть код который обнуляет один из указателей, есть код который > удаляет второй. В рантайме эти два куска кода могут выполнится в > произвольном порядке, предсказать заранее невозможно. Как ты будешь решать, в каком > из кусков кода вызывать free? Сами говорите, что обнуляете, значить нужно условие проверки на обнуленность одного из указателей и в дополнение еще и обнулить второй указатель. > Заведёшь ref_count? Окей, указателей больше, и несколько из них являются частью циклов > в структурах. Что ты будешь делать? weak_ref? Но давай теперь докажи, > что weak_ref расставлены правильно, и теперь тебе ещё придётся доказывать, что > у тебя нет use-after-free, в силу неверной расстановки weak_ref. Или ты > расчехлишь сборку мусора? Окей, докажи теперь, что указатели обнуляются всегда сразу, > как только память становится ненужной, что никогда не случится такого, что > ненужный объект переживёт сотню циклов сборки мусора. В голове все может случиться, и это не проблема CS! А доказывается легко, альтернативным (эффективным) алгоритмом. Вот приведу цитату из вики: https://ru.wikipedia.org/wiki/%D0%A1%D0%... """ Появление висячих ссылок обычно становится следствием неправильной оценки времени жизни объекта: программист вызывает команду удаления объекта до того, как его использование прекратится. """ Там же про утечки """ Если ссылающейся на объект переменной будет присвоено новое значение и на объект нет других ссылок, он становится программно недоступным, но продолжает занимать память, поскольку команда его удаления не вызывалась. Такая ситуация и называется утечкой памяти (англ. memory leak). """ И это все разве проблемы CS? Что только не придумали, чтобы избавить "программиста" от непосредственной работы с памятью, и по мне это не правильно. > Тебе всё же удалось доказать? Но вот прилетел pull-request, мы его мергнули. > Что теперь ты будешь делать? Поверишь автору PR, что он всё > проверил, точна-точна? Или будешь доказывать отсутствие проблем с mm снова? Или > может у тебя есть способы повторное доказательство провести проще, типа pr > меняет три строчки кода, и мы на основании него создаём патч > на доказательство? И нам не надо для этого опять изучать весь > наш код целиком, чтобы ничего не упустить? Я лучше буду "верить" в "бесконечную" ленту Тьюринга, и никаких проблем. > Проблема разрешима в некоторых частных случаях. Скажем, если тебе удастся обойтись стеком > и не использовать кучу, то проблема решаема. Какая проблема????????? >[оверквотинг удален] > RAII и при этом хранить каждый указатель в единственном числе, то > проблема решена. Можно эти ограничения ещё ослабить, и тем не менее > оставить локальность доказательства корректности -- тебе не придётся анализировать весь > код заново, после каждого патча на две строчки. Но как только > ты через эти ограничения перешагиваешь, внезапно оказывается, что доказательство теряет > локальность, и чтобы доказать, что вот этот вот free(p) не приводит > к double-free, тебе придётся строить рассуждения о том, как ведут себя > все 100k строк твоей программы, что никакой из возможных входов в > программу не приводит к тому, что этот free(p) освобождает кусок памяти > повторно. Про отладку не слышали? > Решённая проблема перестаёт быть проблемой. Проблемы же с mm продолжаются, потому что > проблема не решена в общем случае, и _это_ даёт возможность программисту > быть квалифицированным специалистом, и выделятся из серой толпы быдлокодеров, которые > не разобрались в вопросе в достаточной мере и не набили себе > достаточного количества шишек. Говорю же проблема в головах, а не в CS. И всякие сборщики мусора, умные ссылки и всякая муть связанная с mm. решают, точнее пытаются решить, не проблему CS, а проблему тех "программистов", которые не представляют как "правильно" работать с памятью и как писать алгоритмы "эффективные" по памяти.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #85 Ответы: #99, #118

95. Сообщение от JL2001 (ok), 26-Фев-21, 02:43	+2 +/–
> Получается для того чтобы расшарить 10 Тб файлов мне нужно организовать 10 > Тб свободного места под данные IPFS, в то время как в > BitTorrent и ed2k достаточно пары сотен килобайт под метаданные. добавление без дубликации ipfs add --nocopy зы: а ещё можно добавить, удалить оригиналы и использовать ipfs fuse в качестве локальной файловой системы зыы: некоторый список возможностей https://www.opennet.dev/openforum/vsluhforumID3/123371.html#66
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #86

96. Сообщение от JL2001 (ok), 26-Фев-21, 02:49	–2 +/–
> Да, именно поэтому джава и течёт как не в себя. товарищ, ты вообще таблетки забыл принять чтоль? что за фуфло ты пытаешься здесь загнать нам??
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #93 Ответы: #97

97. Сообщение от Аноним (1), 26-Фев-21, 03:00	–2 +/–
Сожалею, но я не твой товарищ (по палате), и, скорее всего, это тебе пора поменять таблетки. Может быть, ты просто не понимаешь, с чего жава течёт? Я мог бы объяснить, если бы ты спросил нормально. Всё равно, прими галоперидольчику, а то слишком буйный какой-то.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #96

98. Сообщение от Ordu (ok), 26-Фев-21, 17:37	+1 +/–
>> Неразрешимость сводится к тому, что нет fool-proof способа менеджить память, которого хватит всем. > Что значить "fool-proof" ? это что за определение? В переводе - "надежный" > - что есть надежный? Мне нужны конкретные строгие определения "надежного способа", > во-первых, во-вторых, определение "менеджить (управлять) память". А про "которого хватит > всем" - промолчу, несерьезное высказывание. Это значит, который позволяет промышленным образом получать гарантированный результат. Это значит, что ты можешь пойти на рынок труда, нанять пяток программистов, и они гарантированно дадут тебе результат без mm, без необходимости с твоей стороны изучать их код под микроскопом и тратя на это количество человекочасов того же порядка, как и потраченное на написание кода. >> Я в каком-то соседнем комменте задал наводящие вопросы: как ты доказываешь про >> свой код, что там нет проблем с mm? Ты не доказываешь >> это заказчику? Ну ок, а себе ты это доказываешь как-то? В >> какой момент ты удовлетворённо откидываешься на спинку стула, и говоришь "ну >> вот, теперь код безбажен"? Что ты делаешь для этого? > проблемы с mm могут возникнуть если ты пишешь сам алгоритм mm. Если ты делаешь malloc/free то уже могут возникнуть проблемы. Ты мог выделить память, и не освободить её после того, как она пекратила быть нужной. Даже если ты не делаешь malloc/free проблемы могут возникнуть: скажем ты можешь вернуть из функции указатель на локальную память, и получить use-after-free. Как ты доказываешь, что этого нет? > Как доказываю? - выше в коменте ответил - оценкой "пространственной" сложности, это > оценка необходимого и достаточного объема памяти и её зависимость. Я же > могу посчитать сколько раз я запросил память для работы алгоритма. А > вдруг мой алгоритм оказался избыточен, это разве "бажный" алгоритм? В прошлых > дискуссиях про "течки" памяти мы так и не пришли к определению, > что же это такое. Это бажный алгоритм. В "прошлые" разы -- это в смысле когда мы обсуждали rust'овые гарантии safety? Безопасность -- это не то же самое, что и безбажность. Если я в расте разворачиваю Result'ы при помощи unwrap, то при любой ошибке я получаю панику и принудительное завершение программы. Если я собрал растовый код с проверкой на выход за границы, то у меня гарантированно не будет buffer-overflow, но программа может выпадать в панику, когда индекс за границы выходит. Это тоже всё баги программы. Но "безопасные" баги. Там я приводил примеры, когда mem-leak'и могут оказываться опасными. Для большинства приложений они имеют пониженную опасность, потому как первый приоритет у багов, позволяющих злоумышленнику запустить произвольный код на системе и захватить полный контроль над системой. Но хапануть злоумышленного кода -- это не для всех программ актуально, а для некоторых ООМ означает полный провал. >> Вот когда тебе надо доказать асимптотическую сложность алгоритма, ты берёшь и доказываешь >> это. > Хмммм, сложность оценивается, а не доказывается. Это игра словами. О-большое -- это вполне себе математическая концепция. Из матана позаимствованная. Эйлер придумал о-маленькие и о-большие, для того чтобы пределы считать (кстати меня на первом курсе очень позабавил препод, который гордо рассказывал о том, что эти о-маленькие/большие/красивые -- это кириллические о, потому что Эйлер был "русским" математиком). CS, будучи, если по-хорошему, прикладной математикой, позаимствовала концепцию. Когда ты выводишь для своего алгоритма оценку O(n*log(n)), то ты делаешь это методами математики. Ты строишь в голове конструктивное доказательство. Даже если ты делаешь это в уме и очень неформально: суть в том, что ты делаешь это таким образом, что ежели я скажу тебе "докажи свою оценку", ты легко сможешь выкатить строгое доказательство её. > """ > Рассмотрение входных данных большого размера и оценка порядка роста времени работы алгоритма > приводят к понятию асимптотической сложности алгоритма. > """ Эмм... Чо? О-большое от f(x) -- это класс функций ограниченных f(x), то есть такие g(x), то существует такие a и x0 из R, что для любого x>x0 будет выполняться неравенство a*f(x) > g(x). Наверное, это можно сформулировать как "рассмотрение входных данных большого размера", но... Но это википедия, не надо относиться к ней излишне серьёзно. Кстати я вот не помню: то что я написал -- это если по-хорошму "О-большое при x→∞", но можно же таким же образом определить О-большое при x→0, например. По-идее, матан должен так делать, поскольку пределы бывают разные, и соответственно О-большое без указания предельной точки -- бессмыслица, а значит остаётся теоретическая возможность оценки асимптотической сложности программы, при x→π, и тогда эти разговоры о "большом размере" пойдут лесом. Хотя это может быть лишь теоретической возможностью (и таким образом формалистской придиркой), мне никогда вроде не приходилось оценивать сложность алгоритма не на бесконечности. >> Про алгоритмы не всё можно доказать, что >> хочется -- проблема останова, например, неразрешима в общем случае. Но про >> mm что ты можешь доказать? > Как по мне, проблема останова это порочный круг, алгоритм который пройдется по > всем алгоритмам по списку и должен будет остановится на том алгоритме, > который не останавливается, - не остановится никогда. Такие же приколы бывают > с рекурсиями при определенных условиях, когда нет условия ограничивающее глубину рекурсии. Бывает. Но попробуй какой-нибудь нетривиальный синтаксис парсить, и доказать, что время работы парсера не будет убегать в бесконечность. В смысле, что нет способа генерить последовательности из N символов, которые будут требовать O(e^N) ресурсов для парсинга. Вон на расте можно писать такие программы -- я видел пример генераторов парсеров, то есть синтаксис кодируется в системе типов, и на основании этого генерится программа-парсер, и на этапе компиляции 200 строк кода rustc выжирает гигабайты кода, и думает минут десять. С C++ можно то же самое вытворять легко. С C сложнее, может быть невозможно. Я ссылку найти не могу, на stackoverflow было обсуждение, как в разных языках можно одной строчкой кода получить бинарь на 20Tb. Как доказать что такое невозможно или ещё интереснее, что это возможно только таким-то и таким-то образом, которые мы считаем законными, а иначе такого не случится. >> Ты знаешь алгоритм как детерминированно показать про любую программу наличие/отсутствие >> проблем с mm? > Алгоритм оценки "пространственной" сложность прост, банальные пошаговые замеры памяти > (занимаемого пространства). Это может работать если ты предположишь, что у тебя нет проблем с mm, типа mem-leak'ов. То есть если ты исходно заложишь предположение о том, что у тебя программа безбажна, то ты докажешь, что она безбажна. Нет ничего удивительного в этом, а? А теперь попробуй доказать, что ни при каком входе программа не течёт памятью. >> Или ты просто _веришь_ в то, что ты >> можешь любую программу избавить от багов с mm за конечное время? > Не вижу проблемы. У любого детерминированного алгоритма есть оценка. У тебя есть детерминированный алгоритм поиска багов в программах? И какова асимптотическая сложность этого алгоритма от SLOC? Я утверждаю, что у тебя нет детерминированного алгоритма не только для поиска всех багов, но даже для поиска багов относящихся к mm, таких как use-after-free, double-free и memory-leak. То что у тебя есть, либо не ловит всего, либо предмет той самой проблемы останова: ты не сможешь доказать, что твой алгоритм остановится когда-нибудь. >> На чём эта вера основана? На "мамой клянус"? Может у тебя >> хоть статистика есть, типа ты написал 100k строк кода, они широко >> используются 10+ лет, и там до сих пор не нашли ни >> одного бага с mm? На чём основана твоя вера? > Заставь дурака Богу молиться - сами знаете что... это про статистику и > веру. Ты не ответил на вопрос: на чём основана твоя вера? Ты просто веришь? Или как-то доказываешь? Я уверен, что ты доказываешь. Пускай неформально, пускай ты не пишешь на листочке сложных доказательств непонятными математическими значками. Но доказываешь. Ты проделываешь в своей голове рассуждения вида: вот тут мы выделяем память Q, и сохраняем указатель на неё в структуре A... Больше отсюда указатель мы никуда не копируем, и структура A освобождает Q либо в деструкторе, либо раньше. Значит, если мы докажем, что память структуры A освобождается законным для языка путём (то есть так, чтобы деструктор отработал), то мы можем забыть про Q, с ней тоже всё будет ок. Ты гоняешь в своей голове рассуждения по типу этого. Ну, точнее, тут одно из двух: либо гоняешь, либо быдлокодер. Я ставлю на первое. Но есть ли у тебя способ взяв код, выстроить достаточное количество таких рассуждений, чтобы утверждать что в программе нет проблем с mm (то есть нет use-after-free, double-free и memory-leak, я не включаю сюда buffer-overflow, потому что про него как раз можно выстроить конечной протяжённости рассуждения, которые докажут наличие или отсутствие).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #90 Ответы: #100

99. Сообщение от Ordu (ok), 26-Фев-21, 18:05	+2 +/–
>> Что значит "не проблема CS"? А что тогда "проблема CS"? И, в >> смысле, когда Кнут излагал разные способы менеджить память, и рассказывал как >> ни один из этих способов не решает проблему на 100%, это >> была не CS, а так, лирическое отступление? > Интересно, следуя по Кнуту, я должен Тьюринга считать дураком за его "бесконечную" > ленту? А теперь представьте, что есть "бесконечная" память, будут у вас > проблемы с "менеджить память"? Бесконечная лента -- это математическая абстракция. Как и любая абстракция она имеет ограниченную полезность. Полезность! Но ограниченную. Не надо некритично доверять всему, что тебе говорит какая-то там абстракция, ты же инженер, ты должен это понимать лучше любого учёного. > Сначала все свалим в "кучу", а потом будем придумывать 1000500 способов разгребания > этой кучи, создавая из этого проблемы. Сущность человека такова. Да-да, я абсолютно согласен. Но это философия, а не информатика. ;) Информатика будет придумывать 100500 способов разгребания, а не рассуждать о сущности человека. >> mm де факто автоматизируется. Может ли он быть автоматизирован или не может >> уже не важно: он _де_факто_ автоматизируется, программист не просит пользователя просматривать >> эпизодически кучу, и решать что там нужно, а что нет. А >> это значит, что mm находится в области интересов CS. В том >> числе и проблема "текучести кучи" находится в области интересов CS. > Если программист не знает оценки "пространственной" сложности собственных алгоритмов, > то что тут сказать? Оценка сложности - обязательна!!! Это теория которая оторвана от практики. Это абстракция, полезность которой ограничена. Для работы с проблемами mm её недостаточно, тебе нужна другая абстракция. > Сами говорите, что обнуляете, значить нужно условие проверки на обнуленность одного из > указателей и в дополнение еще и обнулить второй указатель. А как же инкапсуляция? Эти два указателя лежат в разных объектах, и из метода одного объекта добраться сначала до другого, а потом до указателя в нём, чтобы проверить? А как же инкапсуляция? Если ты забьёшь на инкапсуляцию, то к 10k SLOC ты не сможешь вообще ничего доказать про свою программу, не только отсутствия багов. > В голове все может случиться, и это не проблема CS! Это проблема CS. CS обслуживает IT. IT -- это технология. Основное отличие технологии от кустарщины -- это способность гарантированно получать воспроизводимый результат. "Всё может случится", "пути господни неисповедимы" -- это не путь технологий, не путь инженера, не путь творца. Случаться должно только то, что задумано, и не должно случаться ничего, что не задумано. > А доказывается > легко, альтернативным (эффективным) алгоритмом. Вот приведу цитату из вики: > """ > Если ссылающейся на объект переменной будет присвоено новое значение и на объект > нет других ссылок, он становится программно недоступным, но продолжает занимать память, > поскольку команда его удаления не вызывалась. Такая ситуация и называется утечкой > памяти (англ. memory leak). > """ > И это все разве проблемы CS? Что только не придумали, чтобы избавить > "программиста" от непосредственной работы с памятью, Да. Это проблемы CS. Задача CS дать программисту надёжный способ работы с памятью. Если можно этот надёжный способ выстроить поверх C'шной адресной арифметики, то пускай он будет выстроен поверх C'шной адресной арифметики. Если он не может быть выстроен поверх C'шной адресной арифметики, значит надо выстроить его поверх чего-то ещё. > и по мне это не правильно. Это не правильно. Это любовно и прельстиво для программиста, потому как он может быть большим специалистом и носителем сакрального знания, и получать много денег за это. Но проблема в том, что технологии так не работают. Технологии не могут полагаться на людей, потому как люди непредсказуемы, а технологиям нужен предсказуемый результат. Именно поэтому я и говорю, что сегодня программирование -- это кустарное ремесленничество, а не технология. > Я лучше буду "верить" в "бесконечную" ленту Тьюринга, и никаких проблем. Это не ответ, а уход от ответа. >> Проблема разрешима в некоторых частных случаях. Скажем, если тебе удастся обойтись стеком >> и не использовать кучу, то проблема решаема. > Какая проблема????????? Проблема утечек памяти. >[оверквотинг удален] >> проблема решена. Можно эти ограничения ещё ослабить, и тем не менее >> оставить локальность доказательства корректности -- тебе не придётся анализировать весь >> код заново, после каждого патча на две строчки. Но как только >> ты через эти ограничения перешагиваешь, внезапно оказывается, что доказательство теряет >> локальность, и чтобы доказать, что вот этот вот free(p) не приводит >> к double-free, тебе придётся строить рассуждения о том, как ведут себя >> все 100k строк твоей программы, что никакой из возможных входов в >> программу не приводит к тому, что этот free(p) освобождает кусок памяти >> повторно. > Про отладку не слышали? Отладка -- это уровня "мамойклянус тестировал". Отладка -- это на тот случай, когда у тебя мозгов не хватает доказать корректность своей программы, и поэтому ты проводишь исследование типа "что же я там такого понаписал". Кстати, я в расте не использую дебуггер. Я могу рассуждать о коде достаточно свободно, так чтобы выяснять где проблема силой мысли, а не как-то там ещё. > Говорю же проблема в головах, а не в CS. И всякие сборщики > мусора, умные ссылки и всякая муть связанная с mm. решают, точнее > пытаются решить, не проблему CS, а проблему тех "программистов", которые не > представляют как "правильно" работать с памятью и как писать алгоритмы "эффективные" > по памяти. Угу. А ты носитель сакрального знания, и именно поэтому ты не отвечаешь на вопросы "как ты избавляешь программу от багов": это же сакральное знание, которым нельзя делиться с непосвящёнными, так? Так вот я говорю тебе: вся история технологий показывает, что сакральные знания уступают открытым. Где все секреты производства непобедимого оружия традиционных кузнецов? Сегодня сталь льют промышленно, получая очень точно выверенные сплавы, которые лучше всего того, что традиционные кузнецы могли делать. А на случай, когда есть сомнения (скажем с дамасской сталью), современные технологии могут посмотреть, понять в чём дело, и сделать то же самое, но в промышленном масштабе. Это вообще задача прикладной науки -- создавать и обслуживать технологии. В том числе и готовить инженеров, владеющих технологиями -- это тоже задача науки. То же самое будет и с программированием. Бизнесу не нужны непредсказуемые ремесленники, он работает с ними только от безысходности. Бизнесу нужны предсказуемые технологии. И CS активно работает над тем, чтобы сделать IT предсказуемым и воспроизводимым.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #94 Ответы: #106, #132

100. Сообщение от Sw00p aka Jerom (?), 26-Фев-21, 19:37	+/–
> Это значит, который позволяет промышленным образом получать гарантированный результат. Я так и не увидел определение проблемы. > Если ты делаешь malloc/free то уже могут возникнуть проблемы. Ты мог выделить > память, и не освободить её после того, как она пекратила быть > нужной. Даже если ты не делаешь malloc/free проблемы могут возникнуть: скажем > ты можешь вернуть из функции указатель на локальную память, и получить > use-after-free. Как ты доказываешь, что этого нет? Ты, ты, ты - так чья это проблема если всюду ты? Повторяю, когда мы говорим "что ты забыл освободить" или "ты освободил уже освобожденное" - это проблемы твои, не мои (не CS). И как мне доказать, что "ты" не допустил этих проблем? Да лекго, я потребую от тебя оценку "пространственную" твоего алгоритма, запущу на исполнение и замерю занимаемое "пространство". Нынешнее поколение забыли, что такое отладка, что такое снять дамп памяти и т.д. потому-что именно отладка прокажет весь процесс исполнения, где на каком шагу алгоритма что должно храниться в той или иной ячейки памяти. Поэтому корректные алгоритмы на асм, без процесса пошаговой отладки, пишутся крайне редко. И все время "программиста" уходит на отладку, а не написание строчек кода. > Это бажный алгоритм. В "прошлые" разы -- это в смысле когда мы > обсуждали rust'овые гарантии safety? Безопасность -- это не то же самое, > что и безбажность. Если я в расте разворачиваю Result'ы при помощи > unwrap, то при любой ошибке я получаю панику и принудительное завершение > программы. Если я собрал растовый код с проверкой на выход за > границы, то у меня гарантированно не будет buffer-overflow, но программа может > выпадать в панику, когда индекс за границы выходит. Это тоже всё > баги программы. Но "безопасные" баги. "Бажный" алгоритм придумывает "бажный" мозг "программиста". Это не проблема CS. Вам говорят взял (alloc) потом верни (free), чья это проблема если вы не следуете этому правилу? Любое нарушение правил по сути баг, а кто их нарушает? даже в случае с UB, вам говорят не делайте так, а то будет UB, а вы что? Одни и теже грабли. > Там я приводил примеры, когда mem-leak'и могут оказываться опасными. Для большинства приложений > они имеют пониженную опасность, потому как первый приоритет у багов, позволяющих > злоумышленнику запустить произвольный код на системе и захватить полный контроль над > системой. Но хапануть злоумышленного кода -- это не для всех программ > актуально, а для некоторых ООМ означает полный провал. Размышления о последствиях "багов" не тема разговора. Так как тут все специфично, системно зависимо. > Ты строишь в голове конструктивное доказательство. > Даже если ты делаешь это в уме и очень неформально: суть > в том, что ты делаешь это таким образом, что ежели я > скажу тебе "докажи свою оценку", ты легко сможешь выкатить строгое доказательство > её. Оценку дают, это результат вычислений. Оценку доказывать нет необходимости, но метод получения оценки может требовать доказательства, согласен. Но обычно этот метод должен быть принят обеими сторонами ибо смысла нет. В той же ассимтотике можно придраться к понятию элементарного шага алгоритма. Я дал оценку приняв за элементарный шаг одно значение, а вы другое, и оценка в точности будет расходиться. Но никто строго не давал этим понятиям определения. > Но это википедия, не надо относиться к ней излишне серьёзно. Вы не согласны с определением ассимтотической сложности алгоритмов? Дайте свое определение. > Бывает. Но попробуй какой-нибудь нетривиальный синтаксис парсить, и доказать, что время > работы парсера не будет убегать в бесконечность. зачем далеко ходить, возьмите регексы, как вы думаете там есть понятия recursion limit? И зачем такие ограничения? > Это может работать если ты предположишь, что у тебя нет проблем с > mm, типа mem-leak'ов. То есть если ты исходно заложишь предположение о > том, что у тебя программа безбажна, то ты докажешь, что она > безбажна. Нет ничего удивительного в этом, а? А теперь попробуй доказать, > что ни при каком входе программа не течёт памятью. Повторяю, доказывается "пространственной" оценкой, а как получить эту оценку? - пошагово исполните алгоритм и смотрите какое "пространство" (память) он будет занимать. То есть алгоритм необходимо отладить в прямом смысле слова, сколько ячеек памяти занято и построить график зависимости от объема входных данных, это и будет оценкой. Повторите сей эксперимент несколько раз на разных входных параметрах. Это называется анализ алгоритма. > У тебя есть детерминированный алгоритм поиска багов в программах? И какова асимптотическая > сложность этого алгоритма от SLOC? Я утверждаю, что у тебя нет > детерминированного алгоритма не только для поиска всех багов, но даже для > поиска багов относящихся к mm, таких как use-after-free, double-free и memory-leak. Отладка и еще раз отладка, а без отладки - тупо сравнить вот выделил тебе N байт, а ты вернул N-1, о чем это говорит? Алгоритм разве должен выяснить где ты это допустил? А зачем когда есть отладка и этим делом должен заниматься "программист". Скажите, что у меня еще нет и алгоритма который сам создает алгоритмы, ой как весело будет. > То что у тебя есть, либо не ловит всего, либо предмет > той самой проблемы останова: ты не сможешь доказать, что твой алгоритм > остановится когда-нибудь. Если для вас "порочный круг" это проблема, то за решением сего вопроса предлагаю вам обратиться к Б. Расселу, он подскажет как избегать этого, да да избегать, а не лбом утыкаться делать из этого проблему, которую по сути не разрешите, как и не разрешима ситуация с остановом алгоритма заведомо порочного. > Ты не ответил на вопрос: на чём основана твоя вера? Ты просто > веришь? Или как-то доказываешь? Вера удел дураков, как и удача. Выше я описал, про оценку и доказательство (применяемого к методу оценки). > Я уверен, что ты доказываешь. Пускай неформально, > пускай ты не пишешь на листочке сложных доказательств непонятными математическими значками. > Но доказываешь. Ты проделываешь в своей голове рассуждения вида: вот тут > мы выделяем память Q, и сохраняем указатель на неё в структуре > A... Больше отсюда указатель мы никуда не копируем, и структура A > освобождает Q либо в деструкторе, либо раньше. Значит, если мы докажем, > что память структуры A освобождается законным для языка путём (то есть > так, чтобы деструктор отработал), то мы можем забыть про Q, с > ней тоже всё будет ок. Нет я так не рассуждаю, выделение, указатель, структура, деструктор (что за страшное слово) - все это часные случаи со своими вытекающими следствиями. Ассимптотику на то и придумали, чтобы охватить все эти случаи и не касаться их конкретно. > Ты гоняешь в своей голове рассуждения по типу этого. Ну, точнее, тут > одно из двух: либо гоняешь, либо быдлокодер. Я ставлю на первое. Нет не гоняю и гонять не хочу, потому что я не ограничиваю себя в таких рассуждениях конкретными языками, структурами, умными указателями и т.д. Грубо говоря, рассуждать нужно по Тьюрингу. > Но есть ли у тебя способ взяв код, выстроить достаточное количество > таких рассуждений, чтобы утверждать что в программе нет проблем с mm > (то есть нет use-after-free, double-free и memory-leak, я не включаю сюда > buffer-overflow, потому что про него как раз можно выстроить конечной протяжённости > рассуждения, которые докажут наличие или отсутствие). В терминах машины Тьюринга таких понятий нет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #98 Ответы: #101

101. Сообщение от Ordu (ok), 26-Фев-21, 21:49	+/–
Можно я не буду отвечать на каждое твою строчку, и просто в целом попытаюсь ответить? Если тебе важно на какие-то из утверждений услышать мои ответы, то ты скажи на какие. Программирование -- это технология, часть стека технологий IT. Технологии создаются для того, чтобы обслуживать бизнес. То есть, мы часто программируем just for fun, и там мы можем себе ставить любые требования к программе или к процессу написания программ, какие нам нравятся, но в целом технологии создаются для того, чтобы делать миру хорошо, а это значит для бизнеса. Бизнесу нужна предсказуемость процессов. В частности технологических процессов, но не только. Бизнес очень часто упирается в то, что он сначала вливает ресурсы в создание чего-то (часто эти ресурсы измеряются деньгами), и если всё выгорит, то он потом получает какие-то ресурсы взамен потраченных (тоже часто сводят всё к деньгам). Это риск, ты чуешь? Можно влить ресурсов и не получить ничего взамен. Режимов отказа может быть очень много, есть очень много способов для бизнеса профукать все полимеры. Технологические процессы тоже вносят свой вклад в список этих способов. Тут, если по-хорошему, надо было бы привести пару десятков способов пролететь, чтобы ты представлял себе хотя бы примерно многообразие этих способов, но у меня нет настроения писать такую простыню. Так вот, нужна предсказуемость технологий. Откуда вылезает непредсказуемость? Ты, такое ощущение, хочешь свалить всю проблему на тупого инженера. Но ты в курсе, что у людей нет надёжных тестов для оценки тупости? То есть, зашкаливающую тупость можно объективно замерять, но вот объективно сравнить двух инженеров и сказать какой из них лучше справится с задачей -- тут нет методов. На HN пару лет назад, были очень популярны статьи посвящённые отбору кандидатов при найме, и всё это в целом выглядело как бред сивой кобылы. Можно попросить кандидата написать сортировку пузырьком, и если он не напишет, то отказать ему. А если напишет? Я в девятом классе мог написать сортировку пузырьком, и чё? А вот попроси меня написать сегодня чёрно-красное дерево, и я такой... эээ... там какая-то идея с тем, что узлы красные и чёрные, у красных может быть только чёрный ребёнок, все листы, вроде чёрные, бла-бла-бла... а фишка в том, что мы используя только локальные рассуждения (ну не совсем локальные: там O(log) сложность, а не O(1)) этими цветами кодируем информацию  о состоянии сбалансированности дерева, которую используем при ребалансировках... ок, если вы хотите, чтобы я это написал, то либо я сейчас иду в гугл освежать память, либо мне нужно 3..8 часов на то, чтобы изобрести велосипед. Но я отвлёкся, нет способа оценить квалификацию программиста, потому что нет чёткой технологии программирования. Можно использовать какие-то эвристики, которые имеют мало false negative, но они будут иметь много false positive. Можно найти эвристики, которые будут давать мало false positive срабатываний, но у них будет много false negative. Потому что достоверность и надёжность всех этих методик уровня социальных наук (неудивительно). Чёткая хорошая технология должна включать в себя, в частности, методику подготовки персонала и методы оценки их уровня подготовленности. У программирования их нет, а значит когда бизнес связывается с программистами, он должен не забыть пересчитать все вероятности в своих оценках рисков. Сильно пересчитать в сторону снижения шансов на успех. Бизнесу пофигу, считаешь ли ты проблемы с памятью проблемами программиста или проблемами CS, бизнесу нужен результат, причём с гарантией его достижения. CS -- это раздел науки, которая обслуживает IT, значит это проблемы CS. Это был взгляд с точки зрения экономики. Но ежели ты планируешь когда-нибудь стать чем-то большим, чем обезъяна набирающая код, то тебе хоть и не обязательно знать экономику, но положение твоей области в этой экономике представлять надо. Теперь с точки зрения инженера. Тебе, как программисту, приходится выносить решение о надёжности кода. О надёжности своего кода и о надёжности чужого кода. И как ты это делаешь? Заглянул в сорцы, увидел что там оформление кода кривое, сделал вывод о том, что сорцы -- отстой? Но ты ж понимаешь, что оформление кода -- это эвристика? Если я возьму хороший код, и испорчу там оформление, код не станет от этого менее надёжным. И в то же время, если я возьму плохой код и приведу оформление к идеалу, не внося других изменений, он не станет от этого надёжнее. Но и тем не менее, оформление кода остаётся одним из важных детекторов качества. Покрытие тестами -- важный критерий. Любая мейнстримовая технология повышения надёжности -- это детектор качества, это эвристика которая гарантий не даёт, но по-крайней мере говорит о том, что разработчики кода была достаточно в теме, чтобы знать про то, что такое мейнстрим. Они правильные ритуалы выполняли, правильно приседали и с нужной интонацией произносили "ку". Это карго-культ, но какие альтернативы ему? Ещё можно проводить аудит кода, это долго и дорого, но если ты посмотришь повнимательнее, этот аудит -- это тоже не алгоритм, это груда эвристик, только более системно применяющаяся, чем те эвристики, которые ты используешь. Справедливости ради, тестирование, фаззинг, valgrind имеют шансы выловить баги, про которые ничего неизвестно заранее. То есть они стохастические методы оценки качества кода, и применяя статистику можно попытаться высчитать количество багов в данной программе. Но тут есть проблема: те кто разрабатывают программу тоже пользуются этими тулзами, а это значит, что ноль найденных нами багов -- это не гарантия того, что программа разрабатывалась специалистами, которые не допускают багов: они может быть в каждой второй строке кода допускают баг, но потом исправляют те, которые вылавливаются этими методами. А те, которые не вылавливаются, остаются в коде. И сколько их там? Как инженер ты должен уметь оценить надёжность разработанной системы. Более того, ты должен уметь обосновать эту оценку. (Ты выше рассуждаешь, что "вычисление -- это не доказательство", но на самом деле это не так: вычисление это конструктивное доказательство результата, которое доказывает результат вычисляя его. Вычисление -- это тоже способ рассуждать, причём достаточно строгий способ, чтобы претендовать на звание математически строгого доказательства.) Но даже если ты и умеешь оценить надёжность, то какова надёжность этой оценки? Ты можешь сказать что-нибудь в стиле: программа за тысячу часов работы покажет бажное поведение K раз? Ты можешь дать оценку этого K, в виде среднее+стандартное отклонение? Нарисовать распределение вероятностей этого K? Если нет (а я уверен, что нет), то ты не можешь оценить надёжность разработанной системы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #100 Ответы: #134

102. Сообщение от BrainFucker (ok), 26-Фев-21, 22:20	+/–
> Ссылки на issue есть? Было бы любопытно почитать про проблемы потребления памяти в go программах. Пускай даже и в одной программе. Сорри, был занят. Например: https://github.com/ipfs/go-ipfs/issues/3318 https://github.com/ipfs/go-ipfs/issues/3532 Пробовал в 2019, проблема актуальна. Ну тут скорее проблема не из-за самого Go, а в качестве реализации. Bittorrent клиент на Питоне и то потреблял меньше 100МБ.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #35 Ответы: #104

103. Сообщение от BrainFucker (ok), 26-Фев-21, 22:23	+1 +/–
> а у меня не жрало и не жрёт Потребляет меньше ста мегабайт? Не ври. > конкретика или ссылка на багу - в студию На: https://github.com/ipfs/go-ipfs/issues/3318 https://github.com/ipfs/go-ipfs/issues/3532 Пробовал в 2019, актуально.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #68 Ответы: #110

104. Сообщение от Ordu (ok), 26-Фев-21, 22:55	+/–
>> Ссылки на issue есть? Было бы любопытно почитать про проблемы потребления памяти в go программах. Пускай даже и в одной программе. > Сорри, был занят. > Например: > https://github.com/ipfs/go-ipfs/issues/3318 > https://github.com/ipfs/go-ipfs/issues/3532 > Пробовал в 2019, проблема актуальна. О, спс. > Ну тут скорее проблема не из-за самого Go, а в качестве реализации. Да, это не выглядит проблемой Go или GC. Сложно сказать, в чём именно проблема -- там если походить по ссылкам, довольно много проблем, приводящих к выжиранию ресурсов. Скажем тысячи открытых соединений. То есть да, можно сказать, что это проблема реализации и успокоиться на этом. Но местами складывается впечатление, что проблемы вылезают из распределённости, и неясно где и как где и как детектировать и куда втыкать лимиты, вида "не буду стучаться к новым пирам, пока не найду открытых соединений, которых можно закрыть". Любопытно было бы поковырять глубже...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #102 Ответы: #105

105. Сообщение от BrainFucker (ok), 26-Фев-21, 23:13	+/–
Там и изначально было видно что начали реализовывать не продумав архитектуру нормально. Чего только стоит то что оно у них по дефолту добавляемый файл тупо копировало внутрь себя, вместо того чтобы использовать файлы напрямую, как у торрентов. Позже они вроде как добавили опцию чтобы можно было не дублировать файлы, но оно у них работало тоже со какими-то нюансами. Такое себе, в общем. Идея отличная, но реализация...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #104

106. Сообщение от Алког Анон (?), 27-Фев-21, 00:19	–1 +/–
> Сегодня сталь льют > промышленно, получая очень точно выверенные сплавы, которые лучше всего того, что > традиционные кузнецы могли делать. А на случай, когда есть сомнения (скажем > с дамасской сталью), современные технологии могут посмотреть, понять в чём дело, > и сделать то же самое, но в промышленном масштабе. Вот только Ordu вряд ли сможет что-либо отлить из "высококачественного сплава". На самом деле... Да ещё с доказательством что этот сплав не хуже чем от "старых кузнецов". Не говоря уже про сравнение с современными сакральными...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #99 Ответы: #107

107. Сообщение от Ordu (ok), 27-Фев-21, 00:47	+1 +/–
>> Сегодня сталь льют >> промышленно, получая очень точно выверенные сплавы, которые лучше всего того, что >> традиционные кузнецы могли делать. А на случай, когда есть сомнения (скажем >> с дамасской сталью), современные технологии могут посмотреть, понять в чём дело, >> и сделать то же самое, но в промышленном масштабе. > Вот только Ordu вряд ли сможет что-либо отлить из "высококачественного сплава". Естественно. Это вообще а) непросто; б) требует дорогущего оборудования; в) я подозреваю, что работает только в достаточно больших масштабах. Ну, например, выжигать из расплава железа лишний углерод чистым кислородом -- это конечно весело звучит (ну-ка, при ~полутора тысячах градусов Цельсия дунь чистым кислородом, хыхы), но я подозреваю приводит к довольно большим потерям материала, которые снижаются лишь масштабом. > Да ещё с доказательством что этот сплав не хуже чем от "старых кузнецов". Самая крутая сталь, которую делали до изобретения промышленных процессов литья стали, была дамасская сталь. И её превосходство достигалось через загрязнённую ванадием железную руду в окрестностях Дамаска, и через индийскую технологию литья и закалки. Сегодня не нужна руда с ванадием, ванадиевая сталь делается из чистого железа, посредством точно отмеренной добавки ванадия, причём спектроскопия позволяет оценить чего не хватает в расплаве, и довести концентрации до идеальных. Насчёт технологии закалки, чтоб получался характерный рисунок дамасской стали, я не скажу, насколько он нужен и полезен -- я читал, но чёт не упомню. Но из сочетания фактов, что физика получения этого рисунка расписана во всех деталях и воспроизведена практически, и что никто так не делает промышленно, можно сделать вывод, что при современных технологий нафиг не нужны средневековые технологические костыли. Либо потому, что есть методы лучше, а может потому, что сегодня никто не использует мечи, чтобы рубить другие мечи и доспехи. Но ты, конечно, продолжай верить в безвозвратно утерянные секреты древних мастеров.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #106 Ответы: #108, #129

108. Сообщение от Алког Анон (?), 27-Фев-21, 01:07	+/–
Ну да, сплав Ordu не сделает, но "доказательство" того, что он будет не хуже чем у "старых кузнецов" Ordu похоже считает что привёл... :-)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #107 Ответы: #109

109. Сообщение от Ordu (ok), 27-Фев-21, 01:34	+/–
> Ну да, сплав Ordu не сделает, но "доказательство" того, что он будет > не хуже чем у "старых кузнецов" Ordu похоже считает что привёл... В смысле, ты хочешь чтобы я тебе ссылок накидал? Про что именно? Про дамасскую сталь? Держи: https://youtu.be/OP8PCkcBZU4 Или тебе нужен полный обзор секретов древних мастеров? На: https://acoup.blog/2020/10/16/collections-iron-how-did-they-.../ Обрати внимание: это последняя статья из серии. Там в начале ссылки на предыдущие, лучше начать с них. Они может излишне увлекаются экономическими вопросами, типа как много человеко-часов требовалось на производство одного ножика тем или иным способом, или сколько тонн CO2 выделялось в атмосферу в результате, но сами методы тоже вполне изложены. И если тебе покажется, что там где-нибудь есть нераскрытые секреты, то спроси меня, я тебе их раскрою. Все секреты древних мастеров проистекают из одной из двух причин: а) нехватка любознательности и умения пользоваться гуглом; б) ненужности этих секретов в современном мире. Скажем, какое нам дело, как британцы двигали Стоунхендж голыми руками, когда сегодня для этого есть машины?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #108 Ответы: #116

110. Сообщение от JL2001 (ok), 27-Фев-21, 03:17	+/–
>> а у меня не жрало и не жрёт > Потребляет меньше ста мегабайт? Не ври. >> конкретика или ссылка на багу - в студию > На: > https://github.com/ipfs/go-ipfs/issues/3318 > https://github.com/ipfs/go-ipfs/issues/3532 по второй ссылке :) > A newly started daemon has RSS=92020
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #103 Ответы: #117

111. Сообщение от Аноним (-), 27-Фев-21, 05:23	+1 +/–
> К сожалению, го ограничивает применимость, Ну, блин, есть даже C'шная реализация сабжа. Чего тебе еще надо?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #115

112. Сообщение от Аноним (-), 27-Фев-21, 05:25	+/–
А потом пришел IPv6 и это перестало иметь мозги, теперь айпишник можно каждому таракану выдать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #84

113. Сообщение от Аноним (-), 27-Фев-21, 05:25	+/–
В сишке компилятор не скачивает половину интернета как у гуглохипстеров.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #67 Ответы: #123

114. Сообщение от Аноним (-), 27-Фев-21, 05:27	+/–
Скорее ip link set blah-doh-something :). Так что скоро попадет в linux-utils.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10

115. Сообщение от Аноним (1), 27-Фев-21, 06:19	+/–
Это как с i2p? Там она тоже "есть".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #111

116. Сообщение от Алког Анон (?), 27-Фев-21, 14:11	–1 +/–
>> Ну да, сплав Ordu не сделает, но "доказательство" того, что он будет >> не хуже чем у "старых кузнецов" Ordu похоже считает что привёл... > В смысле, ты хочешь чтобы я тебе ссылок накидал? Про что именно? > Про дамасскую сталь? :-))) "Доказтельство" прогрессирует, Мы смотрим... Ждать ли ""Доказательство""..? > Скажем, какое нам дело, как британцы двигали Стоунхендж голыми руками, когда сегодня для этого есть машины? Для Стоухенджа? Машины? Это какие такие машины сегодня строят стоухенджи? (это Мы к тому, что первый вопрос даже -- это что он вообще собой представлял и зачем был нужен, а воздвигали ли его именно голыми и именно руками, это уже потом... И если стоухенджи сегодня строят машины, то почему Стоухендж не строился машинами?)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #109 Ответы: #119

117. Сообщение от BrainFucker (ok), 27-Фев-21, 14:30	+1 +/–
> A newly started daemon has RSS=92020 Ну офигеть, при запуске потребляет "всего" 90МБ. А до запуска так и вовсе 0, вот это вообще круто!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #110

118. Сообщение от Алког Анон (?), 27-Фев-21, 14:35	+/–
> Интересно, следуя по Кнуту, я должен Тьюринга считать дураком за его "бесконечную" > ленту? А теперь представьте, что есть "бесконечная" память, будут у вас > проблемы с "менеджить память"? Будут. Вот первая проблема: сколько памяти будет подвергнуто менеджменту менеджером памяти? >:-)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #94 Ответы: #130

119. Сообщение от Ordu (ok), 27-Фев-21, 16:00	+1 +/–
> "Доказтельство" прогрессирует, Мы смотрим... Ах вот оно чо. > Ждать ли ""Доказательство""..? Ждать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #116

120. Сообщение от Аноним (122), 28-Фев-21, 08:43	+/–
Тогда уж в чём отличие от Dat? https://docs.datproject.org/docs/cli-intro
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3

121. Сообщение от Аноним (122), 28-Фев-21, 09:33	+/–
> единственный минус, что не даёт лично мне заменить торенты на ipfs - невозможность в одну команду скачать файл с ipfs и начать его раздачу (и чтоб без дублирования занятого места на винте) > заявке на гитхабе уже года 3-4, похоже разрабов это не сильно интересует По-моему в `dat` это из коробки:   dat source-dir    -- выдаёт link и раздаёт каталог по этому линку   dat dat://link target-dir    -- скачивает каталог и продолжает раздавать https://docs.datproject.org/docs/cli-intro
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #66

122. Сообщение от Аноним (122), 28-Фев-21, 09:46	+/–
> Небольшое время ожидания, я же написал. Да? Мне оно после ДЕСЯТИ МИНУТ задумчивости выдало "504 Gateway Time-out". https://ipfs.io/ipfs/QmUUPSPdbPK5sSxZVhjH7adYZ4QGpvRrUVRc6ht...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #74

123. Сообщение от anonymous (??), 28-Фев-21, 12:09	+1 +/–
Go компилятор тоже не скачивает. А скачивает пакетный менеджер. Разница лишь в том, что Go предлагает встроенный менеджер (который можно и не использовать), а экосистемы Си не предлагают и заставляют все те же пакеты скачивать, сопоставлять и собирать вручную.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #113

124. Сообщение от anonymous (??), 28-Фев-21, 12:12	+/–
Просто Rust и Go делают гораздо более подробную проверку на ошибки на этапе компиляции (а затем во время работы). Это не гарантия тотального security, но вполне неплохой набор гарантий safety.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #36

125. Сообщение от anonymous (??), 28-Фев-21, 12:16	+/–
Нафига вообще общаться с человеком, который ничего не говорит по сути, а лишь  наездает на собеседника (притом всё теми же несмешными шутками про смузи и подобное)? Просто игнорьте :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #80

126. Сообщение от anonymous (??), 28-Фев-21, 12:22	+/–
Далеко не каждую задачу можно решить с константной (O(1)) пространственной сложностью. А когда сложность неконстантная, то появляются те проблемы, о которых говорит Ordu.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #82 Ответы: #131

127. Сообщение от anonymous (??), 28-Фев-21, 12:38	+/–
> (Go такой Go) Как Go связан с проблемами производительности? Предвкушая ответ: GC при хотя бы слегка вменяемом подходе не вызывает существенных проблем (может процентов 5 CPU потратите).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #86

128. Сообщение от username (??), 28-Фев-21, 13:43	+/–
Ни разу но это и ее важно. Разработчики еще на ранних стадиях добавили черный список для хешей и сказали что будут банить в сети особо злостный контент.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21

129. Сообщение от Sw00p aka Jerom (?), 28-Фев-21, 23:57	+/–
Лекции Леонида Архангельского посмотрите на ютубе, интересно :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #107

130. Сообщение от Sw00p aka Jerom (?), 28-Фев-21, 23:59	+/–
> Будут. > Вот первая проблема: сколько памяти будет подвергнуто менеджменту менеджером памяти? >:-) В бесконечной ленте нет понятия менеджера, есть только "дай мне память" и все.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #118

131. Сообщение от Sw00p aka Jerom (?), 01-Мрт-21, 00:00	+/–
> Далеко не каждую задачу можно решить с константной (O(1)) пространственной сложностью. > А когда сложность неконстантная, то появляются те проблемы, о которых говорит > Ordu. А что стоит цель решать за константное "пространство"? А если вход зависит от N?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #126 Ответы: #138

132. Сообщение от Sw00p aka Jerom (?), 01-Мрт-21, 00:31	+/–
> Это теория которая оторвана от практики. Это абстракция, полезность которой ограничена. > Для работы с проблемами mm её недостаточно, тебе нужна другая абстракция. Вот именно, что не нужна никакая абстракция, есть процесс отладки, который даст эти оценки. > А как же инкапсуляция? Это абстракция которая в головах. > Это проблема CS. CS обслуживает IT. IT -- это технология. Основное отличие > технологии от кустарщины -- это способность гарантированно получать воспроизводимый результат. Чтобы получать "воспроизводимый результат" необходимы стандарты. И нет никаких стандартов по вашей проблеме. > Да. Это проблемы CS. Задача CS дать программисту надёжный способ работы с > памятью. Если можно этот надёжный способ выстроить поверх C'шной адресной арифметики, > то пускай он будет выстроен поверх C'шной адресной арифметики. Если он > не может быть выстроен поверх C'шной адресной арифметики, значит надо выстроить > его поверх чего-то ещё. А не легче, чтобы "программист" вообще забыл про понятие памяти? Ну вон всякие GC понасоздавали, а теперь скажите за что их хейтят? > Технологии не могут полагаться на людей, потому как люди непредсказуемы, > а технологиям нужен предсказуемый результат. А технологии придумывают "непредсказуемые" люди, а "непредсказуемый" человек придумает именно технологию с "непредсказуемым" результатом, увы порочный круг. > Именно поэтому я и говорю, что > сегодня программирование -- это кустарное ремесленничество, а не технология. Обычное пользование не более. >> Какая проблема????????? > Проблема утечек памяти. Это проблема "программиста", не CS и даже не языка. > Отладка -- это уровня "мамойклянус тестировал". Отладка -- это на тот случай, > когда у тебя мозгов не хватает доказать корректность своей программы, и > поэтому ты проводишь исследование типа "что же я там такого понаписал". Вот тут допущена грубейшая ошибка. Отладка (или обычно говорят профайлинг) и есть доказательство, а не "мамойклянусь" моя программа не больше N MB отжирает. Нынешние "программисты" на том же Ц++ забыли, что такое отладка. > Кстати, я в расте не использую дебуггер. Я могу рассуждать о > коде достаточно свободно, так чтобы выяснять где проблема силой мысли, а > не как-то там ещё. А зачем вам в расте дебаггер если он предназначен избавить вас от него и решить вашу проблему управления памятью, в ближайшем будущем "программисты" забудут и понятие память. Силой мысли еще заставьте компилятор оптимизировать ваш код и найти "баги" :) > Угу. А ты носитель сакрального знания, и именно поэтому ты не отвечаешь > на вопросы "как ты избавляешь программу от багов": это же сакральное > знание, которым нельзя делиться с непосвящёнными, так? Сакральное знание в том, как устроена память и каким правилам необходимо следовать чтобы с ней "безбажно" работать. И эти знания доступны всем. Я же не виноват, что вы забыли, что такое отладка. Я же не виноват, что вами движет бизнес, а не интерес к знаниям. > Сегодня сталь льют промышленно, получая очень точно выверенные сплавы, которые лучше всего того, что > традиционные кузнецы могли делать. А на случай, когда есть сомнения (скажем > с дамасской сталью), современные технологии могут посмотреть, понять в чём дело, > и сделать то же самое, но в промышленном масштабе. Это вообще > задача прикладной науки -- создавать и обслуживать технологии. В том числе > и готовить инженеров, владеющих технологиями -- это тоже задача науки. Я тока начал изучать эту область :) Внизу в коментах отметил одного кузнеца, посмотрите его курсы. > То же самое будет и с программированием. Бизнесу не нужны непредсказуемые ремесленники, > он работает с ними только от безысходности. Бизнесу нужны предсказуемые технологии. > И CS активно работает над тем, чтобы сделать IT предсказуемым и > воспроизводимым. Бизнесу пофиг, главное деньги.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #99 Ответы: #133

133. Сообщение от Ordu (ok), 01-Мрт-21, 01:33	+/–
>> Это теория которая оторвана от практики. Это абстракция, полезность которой ограничена. >> Для работы с проблемами mm её недостаточно, тебе нужна другая абстракция. > Вот именно, что не нужна никакая абстракция, есть процесс отладки, который даст > эти оценки. Процесс отладки -- это неформализованный метод. Кустарный. Если бы он был действительно методом, была бы методика применения отладчика, которая гарантирует, что следование ей избавляет программу от багов. В смысле вот я прошёлся по этой методике, получил программу, и теперь готов продавать программу внося в EULA пункт о моей материальной ответственности за каждый найденный баг в моей программе. >> А как же инкапсуляция? > Это абстракция которая в головах. Это не ответ на мой вопрос. Если ты начинаешь сравнивать значения указателей из разных мест, то с большой вероятностью тебе придётся забить на инкапсуляцию. >> Это проблема CS. CS обслуживает IT. IT -- это технология. Основное отличие >> технологии от кустарщины -- это способность гарантированно получать воспроизводимый результат. > Чтобы получать "воспроизводимый результат" необходимы стандарты. И нет никаких стандартов > по вашей проблеме. Вообще-то есть. Если ты возьмёшь любой плюс-минус серьёзный проект, и попытаешься туда заслать PR, то выяснится, что у них есть требования к оформлению кода, что у них есть запреты на использование каких-то синтаксических конструкций, есть принципы документирования кода, именования переменных, бла-бла-бла... Другое дело, что эти стандарты не распространяются на всю отрасль, а очень локальны. >> Да. Это проблемы CS. Задача CS дать программисту надёжный способ работы с >> памятью. Если можно этот надёжный способ выстроить поверх C'шной адресной арифметики, >> то пускай он будет выстроен поверх C'шной адресной арифметики. Если он >> не может быть выстроен поверх C'шной адресной арифметики, значит надо выстроить >> его поверх чего-то ещё. > А не легче, чтобы "программист" вообще забыл про понятие памяти? Ну вон > всякие GC понасоздавали, а теперь скажите за что их хейтят? Это было бы легче, но это не работает. GC ведь тоже не решает проблем. При этом он создаёт дополнительные проблемы, которые при этом местами не только привносят неудобств, они вообще недопустимы. В real-time приложениях рандомные задержки от GC сильно портят всё, потому что в real-time приложениях время отклика должно быть меньше заданной в ТЗ величины, и выполнение этого пункта ТЗ, должно быть доказано, а не просто заявлено программистом, что он сделал всё ок. >> Технологии не могут полагаться на людей, потому как люди непредсказуемы, >> а технологиям нужен предсказуемый результат. > А технологии придумывают "непредсказуемые" люди, а "непредсказуемый" человек придумает > именно технологию с "непредсказуемым" результатом, увы порочный круг. Нет. То что ты излагаешь здесь -- это мудрость принятая на опеннете, но любая мудрость -- это от тупости. Можно поверх на недетерминированной системы выстроить детерминированную. Мне в качестве примера нравится термодинамика: законы термодинамики выводятся из модели выстроенной на микропараметрах, которые описываются распределениями вероятностей, и таким образом модель стохастическая. Но из стохастической модели выводится детерминированная модель с макропараметрами, и уже на этой теоретической модели строится вполне детерминированный паровоз. В качестве другого примера, я могу привести тебе экономические теории принятия решений, которые созданы для того, чтобы иррациональный по природе своей человек, мог бы следовать этим теориям и принимать рациональные решения. Результат не 100%: от иррациональности сложно избавиться, но существенно лучше, чем без теорий. >>> Какая проблема????????? >> Проблема утечек памяти. > Это проблема "программиста", не CS и даже не языка. Если ты сто раз повторишь это утверждение, оно перестанет быть ложным и станет истинным. >> Отладка -- это уровня "мамойклянус тестировал". Отладка -- это на тот случай, >> когда у тебя мозгов не хватает доказать корректность своей программы, и >> поэтому ты проводишь исследование типа "что же я там такого понаписал". > Вот тут допущена грубейшая ошибка. Отладка (или обычно говорят профайлинг) и есть > доказательство, а не "мамойклянусь" моя программа не больше N MB отжирает. > Нынешние "программисты" на том же Ц++ забыли, что такое отладка. Когда ты отлаживаешь, ты рассматриваешь все теоретические возможные состояния процесса? Нет же, ты рассматриваешь очень небольшое количество этих состояний. На основании своих наблюдений ты пытаешься рассуждениями доказать, что во всех нерассмотренных состояниях будет не хуже. Но -- хыхы -- тут ты упираешься опять в свою способность доказывать утверждения о коде. И по-хорошему, отладка -- это костыль на те случаи, когда твоей способности недостаточно, чтобы решить проблему без отладки. >> Кстати, я в расте не использую дебуггер. Я могу рассуждать о >> коде достаточно свободно, так чтобы выяснять где проблема силой мысли, а >> не как-то там ещё. > А зачем вам в расте дебаггер если он предназначен избавить вас от > него и решить вашу проблему управления памятью, в ближайшем будущем "программисты" > забудут и понятие память. Силой мысли еще заставьте компилятор оптимизировать ваш > код и найти "баги" :) Да, я о том и говорю. Я примерно так и делаю. По инерции после C я использовал отладчик в расте поначалу, а потом забил. Он нафиг не нужен. >> Угу. А ты носитель сакрального знания, и именно поэтому ты не отвечаешь >> на вопросы "как ты избавляешь программу от багов": это же сакральное >> знание, которым нельзя делиться с непосвящёнными, так? > Сакральное знание в том, как устроена память и каким правилам необходимо следовать > чтобы с ней "безбажно" работать. И эти знания доступны всем. Где можно почитать про эти правила, которым нужно следовать? Ты продолжаешь делать в разных вариациях делать это необоснованное утверждение, что можно писать без багов. >> То же самое будет и с программированием. Бизнесу не нужны непредсказуемые ремесленники, >> он работает с ними только от безысходности. Бизнесу нужны предсказуемые технологии. >> И CS активно работает над тем, чтобы сделать IT предсказуемым и >> воспроизводимым. > Бизнесу пофиг, главное деньги. Вот сейчас, ты второй раз произносишь псевдомудрость, чтобы дать себе повод выключить мозг. Да, бизнесу главное деньги. Бизнесмен вкинул свои деньги в проект, и если проект не взлетит, то он потеряет эти деньги. Вот программисту он платит оклад, и если проект не взлетит программист не останется внакладе. У него не отнимут заработанные за два года деньги. А вот бизнесмен просто потеряет деньги, выплаченные програмисту. Бизнесмену нужны гарантии. Ты когда-нибудь нёс материальную ответственность за баги в своём коде, которые просочились в продакшн? Готов в обмен на +10% к зарплате взять на себя обязательство выплачивать неустойки клиентам из своего кармана за каждый найденный баг твоего авторства? Если нет, то ты не умеешь писать безбажный код.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #132 Ответы: #135

134. Сообщение от Sw00p aka Jerom (?), 01-Мрт-21, 01:49	+/–
> чтобы делать миру хорошо, а это значит для бизнеса. Ваш этот "бизнесс" обесценил людской труд, ваш "бизнесс" завтра спокойно уволит всех "программистов" как только программы научаться писать программы. > Бизнесу нужна предсказуемость процессов. В частности технологических процессов, но не > только. Предсказуемы только автоматы, и то написанные "предсказуемыми" людьми, а из ваших суждений выходит, что человек "непредсказуем", парадокс. > Так вот, нужна предсказуемость технологий. Откуда вылезает непредсказуемость? Ты, такое > ощущение, хочешь свалить всю проблему на тупого инженера. Предсказуемость вылезает от предсказуемых людей, людей которые работая с памятью соблюдают правила работы с ней. Разгильдяям тут не место. Помните проблему с дыркой на МКС? Что это было? Как такое допустили? А все просто, тупо разгильдяйство, не там просверлил, залепил жвачкой, и после этого еще ни хрена не перепроверили изделие (не отладили), запустили, и уже на орбите обнаружили. Вот так вот - технология "непредсказуемых" людей. И дырка эта разве проблема данной области? Разве не проблема разгильдяя с дрелью в руках после похмелья (а жвачка, чтобы перегар загасить)? > статьи посвящённые отбору кандидатов при найме, и всё это в целом > выглядело как бред сивой кобылы. Можно попросить кандидата написать сортировку пузырьком, > и если он не напишет, то отказать ему. А если напишет? А не надо говорить ему напиши "пузырьковую" сортировку, надо говорить - отсортируй вот такой массив данных. > сейчас иду в гугл освежать память, либо мне нужно 3..8 часов > на то, чтобы изобрести велосипед. Нормальный рабочий ход, изобретать велосипед не грех. Главное понимать принцип его работы, видеть плюсы и минусы того или иного вида велосипеда. > Но я отвлёкся, нет способа оценить квалификацию программиста, потому что нет чёткой > технологии программирования. Есть способ, его конечный продукт необходимо оценивать, если он не удовлетворяет поставленным требованиям, значить менее квалифицирован. Если нет четких требований, то и смысла оценивать нет. > Бизнесу пофигу, считаешь ли ты проблемы с памятью проблемами программиста или проблемами > CS, бизнесу нужен результат, причём с гарантией его достижения. И ему пофиг как этот результат достигается. Бизнесу пофиг на вашу проблему и скидывает он на вас, а вы эту проблему скидываете на CS, ну ждите 2000 лет когда CS решит эту проблему. > CS -- это раздел науки, которая обслуживает IT, значит это проблемы CS. Ок, пусть будет проблемой CS? Будем ждать у моря погоды. > Это был взгляд с точки зрения экономики. А я рассматриваю все с точки зрения философии. > Теперь с точки зрения инженера. Тебе, как программисту, приходится выносить решение о > надёжности кода. О надёжности своего кода и о надёжности чужого кода. > И как ты это делаешь? Заглянул в сорцы, увидел что там > оформление кода кривое, сделал вывод о том, что сорцы -- отстой? Ну это утрирование, оформление кода и прочая хрень, я же говорю я пытаюсь мыслить шире, и не ограничивать себя понятиями системы, языка, синтаксиса и т.д. для меня это все чуждо. Чтобы ребенку объяснить "пузырьковую" сортировку я должен сначала его обучить языку какому-то? да нет, вырежу квадратики бумажные пронумерую разложу на полу и покажу алгоритм в действии. А перед тем как выносить решения о "надежности" кода, для начала необходимо определить строгие критерии надежности. И поэтому мне щас трудно отвечать на такие рассуждения, необходима строгость в суждениях, чтобы вывод был строгий. Чтобы неоднозначности в трактовке не было.   > оформление кода остаётся одним из важных детекторов качества. Покрытие тестами > -- важный критерий. Посредственный сказал бы, не важный как минимум для меня, многие возразят - мол используй форматтер, или какой смысл писать некрасиво оформленный код, если есть строгие правила его оформления принятые в то или иной компании, мы же не будем их нарушать? Или допустим оформление кода это договоренность в команде, и нарушая её - проявление неуважения к коллегам как минимум, но не как не важны "детектор". > Они правильные ритуалы выполняли, правильно приседали и с нужной интонацией произносили "ку". Это карго-культ, но какие альтернативы ему? Ну да это сродни ритуалам, а ритуал - договоренность. Если это не принимают, то это перестает быть ритуалом. А отношение к ритуалом разные, вам не обязательно соблюдать правила ритуала если вы не в этой среде (в ритуальном кругу). > Ещё можно проводить аудит кода, это долго и дорого, но > если ты посмотришь повнимательнее, этот аудит -- это тоже не алгоритм, > это груда эвристик, только более системно применяющаяся, чем те эвристики, которые > ты используешь. Вот тут ошибочка, аудит именно и есть алгоритм проверок и выставления оценок, а проверки заранее подготовлены. > Справедливости ради, тестирование, фаззинг, valgrind имеют шансы выловить баги, про которые > ничего неизвестно заранее. То есть они стохастические методы оценки качества кода, > и применяя статистику можно попытаться высчитать количество багов в данной программе. > Но тут есть проблема: те кто разрабатывают программу тоже пользуются этими > тулзами, а это значит, что ноль найденных нами багов -- это > не гарантия того, что программа разрабатывалась специалистами, которые не допускают багов: > они может быть в каждой второй строке кода допускают баг, но > потом исправляют те, которые вылавливаются этими методами. А те, которые не > вылавливаются, остаются в коде. И сколько их там? Пошаговая отладка отловит все баги, ибо найденные выше указанными инструментами баги проверяют в процессе отладки, или ждут когда программа выпадет в корку и тогда уже запускают отладчик. Разве не так? или идут ищут баги в исходном коде? Отладка, еще раз отладка. > Как инженер ты должен уметь оценить надёжность разработанной системы. Более того, ты > должен уметь обосновать эту оценку. (Ты выше рассуждаешь, что "вычисление -- > это не доказательство", но на самом деле это не так: вычисление > это конструктивное доказательство результата, которое доказывает результат вычисляя > его. Как выше указал, должны быть определены критерии надежности, и согласован метод оценки, ибо что тут доказывать? Это не доказательства получается, это и есть аудит, проверка качества и т.д. как в случае с любым промышленным продуктом. После всех проверок и оценок ставиться знак качества :) Далее, вот тут ошибка "Ты выше рассуждаешь, что "вычисление -- это не доказательство"", я так не писал, привожу как есть: """ Оценку дают, это результат вычислений. Оценку доказывать нет необходимости, но метод получения оценки может требовать доказательства, согласен. Но обычно этот метод должен быть принят обеими сторонами ибо смысла нет. """ Оценка как результат вычислений, а оценку в свою очередь доказывать не надо, но метод оценки может требовать доказательства. Метод оценки должен принят обеими сторонами. > Вычисление -- это тоже способ рассуждать, причём достаточно строгий способ, > чтобы претендовать на звание математически строгого доказательства.) Но даже если ты > и умеешь оценить надёжность, то какова надёжность этой оценки? Повторяю, не надежность оценки, а метода оценки, и доказывать нужно метод оценки, но его нафиг доказывать не нужно, он должен быть согласован и принят обеими сторонами. Если допустим мне необходимо оценить ваш продукт, и я воспользуюсь вашим методом оценки, то простите меня это будет самообман с вашей стороны. Аудит не должен зависеть от сторон, на то и есть независимый аудит. И в практике не просят подрядчика доказать что его продукт надежный, приглашают со стороны независимы аудит и он дает оценку. > Ты можешь > сказать что-нибудь в стиле: программа за тысячу часов работы покажет бажное > поведение K раз? Ты можешь дать оценку этого K, в виде > среднее+стандартное отклонение? Нарисовать распределение вероятностей этого K? Если > нет (а я уверен, что нет), то ты не можешь оценить > надёжность разработанной системы. Да могу, как минимум методом Монте Карло.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #101 Ответы: #136

135. Сообщение от Sw00p aka Jerom (?), 01-Мрт-21, 03:04	+/–
> Процесс отладки -- это неформализованный метод. Кустарный. Если бы он был действительно > методом, была бы методика применения отладчика, которая гарантирует, что следование ей > избавляет программу от багов. Если процесс отладки это "неформализованный метод", то и процесс непосредственного исполнения есть "неформализованный метод". Значить все программы кустарные? Баги в мозгу у программиста, машина исполняет ровно то, что требует от нее программист. Программист допустит в голове багу, значить программа будет бажной. > В смысле вот я прошёлся по этой > методике, получил программу, и теперь готов продавать программу внося в EULA > пункт о моей материальной ответственности за каждый найденный баг в моей > программе. Корректны алгоритм будет корректно исполняться. И процесс отладки это верифицирует. Процесс отладки вам покажет почему инструкция сложения 2+2 вдруг в место ожидаемого результата 4, поместило в память результат 5. Или почему при записи 1 в бит памяти, вдруг там оказался 0. Понимаете к чему я веду, когда баги даже на уровне вычислительного аппарата. > Это не ответ на мой вопрос. Если ты начинаешь сравнивать значения указателей > из разных мест, то с большой вероятностью тебе придётся забить на > инкапсуляцию. Ну конечно не ответ, так как я не рассуждаю в ваших категориях. Если у меня нет в голове указателей или всякой инкапсуляции. А есть просто ячейка памяти. > Вообще-то есть. Если ты возьмёшь любой плюс-минус серьёзный проект, и попытаешься туда > заслать PR, то выяснится, что у них есть требования к оформлению > кода, что у них есть запреты на использование каких-то синтаксических конструкций, > есть принципы документирования кода, именования переменных, бла-бла-бла... Другое дело, > что эти стандарты не распространяются на всю отрасль, а очень локальны. это не стандарты, это правила, такие же правила как "взял память" - "освободи", "освободил память" - "не смей повторно освобождать" и т. д. > Это было бы легче, но это не работает. GC ведь тоже не > решает проблем. При этом он создаёт дополнительные проблемы, которые при этом > местами не только привносят неудобств, они вообще недопустимы. В real-time приложениях > рандомные задержки от GC сильно портят всё, потому что в real-time > приложениях время отклика должно быть меньше заданной в ТЗ величины, и > выполнение этого пункта ТЗ, должно быть доказано, а не просто заявлено > программистом, что он сделал всё ок. Ну вот ожидаемый ответ, а что есть собственно то же GC, разве не перекладывание ответственности с себя на другого (разработчика языка)? если программа на расте будет течь это разве будет проблема программиста? нет конечно, ибо программист на расте "избавлен" от этой  проблемы заверением растовых разработчиков. И вина с ответственностью на них. А кого будет винить заказчик с убытками? Разработчиков раста? > Нет. То что ты излагаешь здесь -- это мудрость принятая на опеннете, > но любая мудрость -- это от тупости. Можно поверх на недетерминированной > системы выстроить детерминированную. Мне в качестве примера нравится термодинамика: законы > термодинамики выводятся из модели выстроенной на микропараметрах, которые описываются > распределениями вероятностей, и таким образом модель стохастическая. Но из стохастической > модели выводится детерминированная модель с макропараметрами, и уже на этой теоретической > модели строится вполне детерминированный паровоз. Хаос тоже детерминирован, и Бог детерминирован (закономерен)! Придумал новую мудрость. > Если ты сто раз повторишь это утверждение, оно перестанет быть ложным и > станет истинным. Это мое мнение. Моя цель не переубедить вас, а донести свою мысль. > Когда ты отлаживаешь, ты рассматриваешь все теоретические возможные состояния процесса? > Нет же, ты рассматриваешь очень небольшое количество этих состояний. На основании > своих наблюдений ты пытаешься рассуждениями доказать, что во всех нерассмотренных состояниях > будет не хуже. Но -- хыхы -- тут ты упираешься опять > в свою способность доказывать утверждения о коде. И по-хорошему, отладка -- > это костыль на те случаи, когда твоей способности недостаточно, чтобы решить > проблему без отладки. Кхмммм, когда я отлаживаю, я верифицирую задумку алгоритма в голове, если в голове бага, то и в отладке она проявится. А по всевозможные состояния дам ссылочки: https://ru.wikipedia.org/wiki/%D0%9E%D0%... https://ru.wikipedia.org/wiki/%D0%9E%D0%... > Да, я о том и говорю. Я примерно так и делаю. По > инерции после C я использовал отладчик в расте поначалу, а потом > забил. Он нафиг не нужен. И где гарантии безбажности? А ну да я забыл, их разработчики раста дают. > Где можно почитать про эти правила, которым нужно следовать? :) вспомнился фильм Бойцовский клуб. Правило 1: Взял - отдай Правило 2: Не смей отдавать дважды Правило 3: .... и т.д. знатоки могут подсказать. > А вот бизнесмен просто потеряет деньги, выплаченные програмисту. Бизнесмену нужны гарантии. И как я понял программистам тоже нужны гарантии, а кто их даст? Такие же программисты? > Ты когда-нибудь нёс материальную ответственность за баги в своём коде, которые просочились > в продакшн? Ответственность говорите? Разве не ответственность сидеть часами в отладчике и верифицировать написанный код на корректность, который будет использоваться в критически важных системах? Легче же выбрать раст и переложить ответственность на разработчиков раста, так ведь? Хорошо когда на все готовое, а если нужно это уметь хорошо готовить, то это сразу становиться проблемой? Бизнесс говорите, когда от двух строчек кода зависит жизнь человека.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #133

136. Сообщение от Ordu (ok), 01-Мрт-21, 05:50	+/–
>> чтобы делать миру хорошо, а это значит для бизнеса. > Ваш этот "бизнесс" обесценил людской труд, ваш "бизнесс" завтра спокойно уволит всех > "программистов" как только программы научаться писать программы. Я смотрю, тебе надоел поиск истины, и ты решил разговор завалить в партер политической дискуссии? > А я рассматриваю все с точки зрения философии. Спешу тебя огорчить, ты льстишь себе. Я общался с парой философов, они тренированные ребята в дискуссии: дискуссия -- это основа их образования. Они меня на демагогии ловят там, где я не подозреваю демагогии, где мне кажется, что я блестящий аргумент выстроил. Они не позволили бы себе менять нарратив, только ради того, чтобы найти что возразить. То есть поступать так, как ты поступил, рефлекторно реагируя на слово "бизнес" в сочетании с "улучшением мира". Философы сначала думают, потом говорят. Они не позволяют себе рефлекторных ответов. Если они не понимают, что услышали, они задают вопросы. Ты же не понимаешь что услышал, и не понимаешь, что не понимаешь. Или тщательно скрываешь, в надежде, что никто не заметит. Ну и да, остальная часть твоего сообщения очень объёмна, состоит по большей части из повторов, споров об определениях слов, прочей демагогии... У меня есть два возможных объяснения этому: либо тебе надоел поиск истины, либо это отражение нечёткости твоей категоризации мира (там в нескольких местах есть примеры тому, которые я бы объяснил нечёткостью границ понятий в твоей голове). Если исходить из принципа "предполагать благие намерения", то мне следует отказаться от гипотезы, что ты намеренно пытаешься утопить дискуссию в болоте, избегая слепящего света истины, и тогда остаётся только нечёткость категоризации. Но с категоризацией я не могу тебе помочь. Чёткость её возникает из опыта применения своих собственных мозгов ко всяким разным проблемам. Чтения книжек, которые показывают как другие люди применяют свои мозги ко всяким разным проблемам. Опыт математики уместно заходит: математика приучает к строгости рассуждений. Какие бы простыни я не писал тут, это не поможет. Только твоя систематическая работа над твоим же мышлением может помочь.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #134 Ответы: #141

137. Сообщение от Аноним (-), 01-Мрт-21, 18:26	+/–
У такой хорошей децентрализованной системы все решения почему-то принимает CloudFlare, а поддержку Tor и I2P не делают уже лет как пять при живой реализации в форке. Давно было пора закапывать.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #143

138. Сообщение от anonymous (??), 01-Мрт-21, 19:28	+/–
Просто иначе не очень понятен ваш аргумент про умение оценки сложности. Умей ты оценивать или нет, это никак не гарантирует отсутствие ошибок.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #131 Ответы: #139, #140

139. Сообщение от Sw00p aka Jerom (?), 01-Мрт-21, 23:36	+/–
> Просто иначе не очень понятен ваш аргумент про умение оценки сложности. Умей > ты оценивать или нет, это никак не гарантирует отсутствие ошибок. Кхмммм, оценив "пространственную" сложность и замерив результат (отладив) исполнения, можно придти к выводу, что никаких "течек" нет, и алгоритм потребляет (занимает) ровно необходимое и достаточное пространство. А ваше О(1), О(N) и т.д. это зависимость от входных параметров. Отсюда следует, что нет "проблем" связанных с памятью. "Утечки" памяти и нарушение доступа к памяти - разные по специфике "баги".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #138

140. Сообщение от Sw00p aka Jerom (?), 01-Мрт-21, 23:39	+/–
> Умей ты оценивать или нет, это никак не гарантирует отсутствие ошибок. Каких ошибок? Ошибок "разгильдяя"? Умея оценивать (отлаживать), ты найдешь любую ошибку. А если не нашел, но ошибка появилась, то греши на себя, это твоя проблема, а не языка и т.д.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #138

141. Сообщение от Sw00p aka Jerom (?), 02-Мрт-21, 00:14	+/–
> Я смотрю, тебе надоел поиск истины, и ты решил разговор завалить в > партер политической дискуссии? а политика причем? и за "бинесс" я не начинал, мне до лампочки всякий там "бизнесс", и поиск истины разве завязан на "бизнессе"? "Бизнесс" разве движет мной в поиске истины? "Бизнесс" по больше части паразит. > Спешу тебя огорчить, ты льстишь себе. Я общался с парой философов, они > тренированные ребята в дискуссии: дискуссия -- это основа их образования. Они > меня на демагогии ловят там, где я не подозреваю демагогии, где > мне кажется, что я блестящий аргумент выстроил. Отлично, раз есть знакомые философы, то предлагаю вам распечатать наш диалог и дать им пусть поставят себя на наше место, и посмотрим кто кого демагогом выставит. Думаю, получится хороший эксперимент. > То есть поступать так, как ты поступил, рефлекторно реагируя на слово "бизнес" > в сочетании с "улучшением мира". "Бизнесс" и улучшение мира по моему мнению - противоречивы, и мы собственно не "бизнесс" обсуждаем, мое отношение к нему иное. > Философы сначала думают, потом говорят. Они > не позволяют себе рефлекторных ответов. На то и рефлекторные, что не требуют обдумывания, потому-что они уже обдуманны. Необдуманный ответ это набор символов, и его за ответ не сочли бы. А если сочли за ответ, то он вероятно обдуманно ложный, либо истинный. > Если они не понимают, что услышали, > они задают вопросы. Ты же не понимаешь что услышал, и не > понимаешь, что не понимаешь. Или тщательно скрываешь, в надежде, что никто > не заметит. Я не понимаю, что я услышал и в тоже время не понимаю, что - не понимаю. Тогда такой вопрос - задам ли я тогда вопрос? (исходя из вашего утверждения "Если они не понимают, что услышали, они задают вопросы") :) Опять игра слов? (опять вопрос?) Кхмммм как много у меня вопросов, с каждым коментом их еще больше. Знаете почему ? (О_о, опять вопрос). Все стоп, больше никаких вопросов. > Ну и да, остальная часть твоего сообщения очень объёмна, состоит по большей > части из повторов, споров об определениях слов, прочей демагогии... А все потому-что, каждый ваш абзац был вашим же повтором. > У меня > есть два возможных объяснения этому: либо тебе надоел поиск истины, либо > это отражение нечёткости твоей категоризации мира (там в нескольких местах есть > примеры тому, которые я бы объяснил нечёткостью границ понятий в твоей > голове). Если исходить из принципа "предполагать благие намерения", то мне следует > отказаться от гипотезы, что ты намеренно пытаешься утопить дискуссию в болоте, > избегая слепящего света истины, и тогда остаётся только нечёткость категоризации. А где искать истину, как не в собственной голове? > Но с категоризацией я не могу тебе помочь. Чёткость её возникает из > опыта применения своих собственных мозгов ко всяким разным проблемам. Я и не пытаюсь категоризировать, я сторонник индивидуализирования. Проблемы категоризировать нельзя, покуда они еще не разрешимы и тем самым индивидуальны каждая.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #136 Ответы: #142

142. Сообщение от Ordu (ok), 02-Мрт-21, 00:53	+/–
>> Я смотрю, тебе надоел поиск истины, и ты решил разговор завалить в >> партер политической дискуссии? > а политика причем? и за "бинесс" я не начинал, мне до лампочки > всякий там "бизнесс", и поиск истины разве завязан на "бизнессе"? "Бизнесс" > разве движет мной в поиске истины? "Бизнесс" по больше части паразит. Потому что, "бизнес делает миру хорошо" -- это парадигма капитализма. Принятая в наших широтах официально, между прочим. В принципе это самоочевидное высказывание: если бы никто не вёл никаких дел, то мы бы сидели в набедренных повязках под деревьями, потому что под деревьями дождём не так мочит. Если ты считаешь, что в набедренных повязках под деревьями сидеть лучше, то почему ты сидишь перед монитором и строчишь ответы мне? А если считаешь, что перед монитором лучше, то как бы это стало возможным без бизнеса? Когда давным давно, одному сидящему под деревом надоело, он начал делать каменные наконечники стрел и выменивать их на еду. У него появилось дело. И тогда же началась эксплуатация. Правда я до сих пор понять не могу, кто кого эксплуатировал: тот кто наконечники для стрел делал, или его всем племенем эксплуатировали? Только политически ушибленные совком начинают доказывать, что бизнес -- это вселенское зло, и он делает человечеству хуже. Остальные считают бизнес либо нейтральным (то есть не имеющей какой-то склонности к добру или злу, и доставляющим и то, и это), либо очень хорошей вещью, двигателем прогресса (которая в виде исключения иногда делает людям плохо, и то можно поспорить). > Отлично, раз есть знакомые философы, то предлагаю вам распечатать наш диалог и > дать им пусть поставят себя на наше место, и посмотрим кто > кого демагогом выставит. Думаю, получится хороший эксперимент. Да я и так знаю. >> То есть поступать так, как ты поступил, рефлекторно реагируя на слово "бизнес" >> в сочетании с "улучшением мира". > "Бизнесс" и улучшение мира по моему мнению - противоречивы, и мы собственно > не "бизнесс" обсуждаем, мое отношение к нему иное. В том то и дело. Вместо того, чтобы держаться темы беседы, ты пытаешься обрызгать личным отношением каждое пролетающее мимо понятие. Из-за этого беседа вообще не может двигаться ни в каком направлении, потому что она тонет в болоте твоего личного отношения. > Я не понимаю, что я услышал и в тоже время не понимаю, > что - не понимаю. Тогда такой вопрос - задам ли я > тогда вопрос? Нет не задашь. И не задаёшь. Я о том и говорю: складывается впечатление, что ты не понимаешь, что не понимаешь. Прыгнул выше головы, и не заметил. > А где искать истину, как не в собственной голове? Твоя голова выстраивает внутри себя отражение реальности. Те самые тени на стене пещеры, которые на первый взгляд выглядят самой реальностью, и на второй взгляд тоже выглядят ею, и вообще поработать надо, чтобы понять, что это лишь тени. Вот с ними и надо работать, в поиске истины. >> Но с категоризацией я не могу тебе помочь. Чёткость её возникает из >> опыта применения своих собственных мозгов ко всяким разным проблемам. > Я и не пытаюсь категоризировать, я сторонник индивидуализирования. Проблемы категоризировать > нельзя, покуда они еще не разрешимы и тем самым индивидуальны каждая. Вот, кстати, неплохой пример, где ты не понимаешь настолько глубоко, что не понимаешь, что не понимаешь, и вместо того, чтобы спросить, начинаешь нести бред. Когда ты говоришь "я", ссылаясь на себя -- это уже свидетельство того, что ты категоризируешь реальность: ты разделил реальность как минимум на две категории "я" и "не я". Если ты присмотришься, то использование речи невозможно без категоризации, потому что каждому слову соответствует какая-то категория, слово лишь референт, ссылающийся на эту категорию (референт -- это типа указателя, или даже больше похоже на ключ в ассоциативном массиве).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #141 Ответы: #144

143. Сообщение от Аноним (-), 02-Мрт-21, 01:51	+/–
фларь и го , они просто созданы друг для друга. кстати, го стал выбором малвареводов в 21м.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #137 Ответы: #146

144. Сообщение от Sw00p aka Jerom (?), 02-Мрт-21, 03:42	+/–
> Потому что, "бизнес делает миру хорошо" -- это парадигма капитализма. Принятая в > наших широтах официально, между прочим. Бизнес никакого отношения к капитализму не имеет, бизнес - это дело! А дела бывают как во благо так и во вред. > Если ты считаешь, что в набедренных повязках под деревьями сидеть > лучше, то почему ты сидишь перед монитором и строчишь ответы мне? На скалах бы строчил бы ответы вам. > А если считаешь, что перед монитором лучше, то как бы это > стало возможным без бизнеса? А напомните мне, в каком это веке бизнес стал парадигмой капитализма? > Правда я до сих пор понять не могу, кто кого эксплуатировал: тот > кто наконечники для стрел делал, или его всем племенем эксплуатировали? Помимо того, чтобы делать наконечники, нужно еще было охотиться. Один делал наконечники, а другой в замен охотился, а бабы сидели и дули в костер, чтобы не погас. Принцип взаимопомощи, и никакого капитализма. Никто фиговые листики не менял на наконечники. Мне продолжать мысль о том как развивались людские отношения? > Только политически ушибленные совком начинают доказывать, что бизнес -- это вселенское > зло, и он делает человечеству хуже. Бизнес это дело! Что в совке делом не занимались? Там даже статья за тунеядство (Жизнь на чужой счёт, чужим трудом.) была. > Да я и так знаю. Ну пригласите их сюда, интересно будет услышать их мнение. > В том то и дело. Вместо того, чтобы держаться темы беседы, ты > пытаешься обрызгать личным отношением каждое пролетающее мимо понятие. Из-за этого беседа > вообще не может двигаться ни в каком направлении, потому что она > тонет в болоте твоего личного отношения. ЫЫЫЫЫ простите, а с кем вы тогда переписываетесь, если не я должен высказывать личное мнение по отношению чего либо, то кто? я типа должен вам поддакивать?   > Нет не задашь. И не задаёшь. Я о том и говорю: складывается > впечатление, что ты не понимаешь, что не понимаешь. Прыгнул выше головы, > и не заметил. Почему я тогда читаю ответ? > и вообще поработать надо, чтобы понять, что это лишь тени. Тень падает только от "реальности", того чего нет не отбрасывает тень. > Вот, кстати, неплохой пример, где ты не понимаешь настолько глубоко, что не > понимаешь, что не понимаешь, и вместо того, чтобы спросить, начинаешь нести > бред. Давайте спросим, что такое категории? > Когда ты говоришь "я", ссылаясь на себя -- это уже свидетельство того, > что ты категоризируешь реальность: ты разделил реальность как минимум на две > категории "я" и "не я". Я - индивид. https://ru.wikipedia.org/wiki/%D0%98%D0%... Не буду щас затрагивать тему категорий. "я" и "не я" и есть "я" как индивид.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #142 Ответы: #145

145. Сообщение от Ordu (ok), 02-Мрт-21, 04:24	+/–
>> А если считаешь, что перед монитором лучше, то как бы это >> стало возможным без бизнеса? > А напомните мне, в каком это веке бизнес стал парадигмой капитализма? Не бизнес стал парадигмой капитализма, а идея о том, что бизнес -- это метод улучшения мира. >> Правда я до сих пор понять не могу, кто кого эксплуатировал: тот >> кто наконечники для стрел делал, или его всем племенем эксплуатировали? > Помимо того, чтобы делать наконечники, нужно еще было охотиться. Один делал наконечники, > а другой в замен охотился, а бабы сидели и дули в > костер, чтобы не погас. Принцип взаимопомощи, и никакого капитализма. А, то есть всё ж бизнес -- это не плохо. >> Только политически ушибленные совком начинают доказывать, что бизнес -- это вселенское >> зло, и он делает человечеству хуже. > Бизнес это дело! Что в совке делом не занимались? Там даже статья > за тунеядство (Жизнь на чужой счёт, чужим трудом.) была. Не, в совке ты работал на дядю. За собственный бизнес тебя бы быстро отправили заниматься делом настоящих мужиков -- валить лес. Даже если бы ты собственный бизнес назвал бы делом. >> В том то и дело. Вместо того, чтобы держаться темы беседы, ты >> пытаешься обрызгать личным отношением каждое пролетающее мимо понятие. Из-за этого беседа >> вообще не может двигаться ни в каком направлении, потому что она >> тонет в болоте твоего личного отношения. > ЫЫЫЫЫ простите, а с кем вы тогда переписываетесь, если не я должен > высказывать личное мнение по отношению чего либо, то кто? я типа > должен вам поддакивать? Точно. Я именно это хотел сказать. Но как ты догадался? Я так тщательно скрывал эту мысль. /s Ты в курсе, что у беседы иногда бывает тема? Что темы неплохо было бы придерживаться? В смысле неплохо иногда держать в уме цель беседы, и идти к цели, не пытаясь двигаться сразу во все стороны. Подумай об этом. >> Нет не задашь. И не задаёшь. Я о том и говорю: складывается >> впечатление, что ты не понимаешь, что не понимаешь. Прыгнул выше головы, >> и не заметил. > Почему я тогда читаю ответ? Ура! Ты задал вопрос. Но пичалько в том, что я не могу ответить на него. Возможно, я его не понимаю: как я могу сказать тебе, почему ты делаешь то, что ты делаешь? >> и вообще поработать надо, чтобы понять, что это лишь тени. > Тень падает только от "реальности", того чего нет не отбрасывает тень. Разве? Разве только от реальности? А, кстати, что ты называешь реальностью? Если твой мозг рисует тебе псевдогаллюцинацию, и ты её реально видишь, но понимаешь, что это глюк. Эта псевдогаллюцинация -- это тень реальности? Она ж мозгом создана, мозг вроде тоже часть реальности, так? А если тебе кажется, что за дверью кто-то стоит, но ты не понимаешь почему тебе так кажется: это ощущение присутствия -- это тень реальности, или нет? Ведь может быть, твой мозг на самом деле собрал информацию и выдал тебе вполне обоснованную гипотезу в виде ощущения присутствия человека за дверью, а может быть у тебя крыша едет. Это тень реальности или нет? Фантомные боли? Это же "тень" отбрасываемая несуществующей конечностью. Не надо понимать сократовские тени буквально. Они дают конечно некую модель происходящего, но вообще ведь тот диалог не столько о модели человеческой психики и/или познания, сколько о месте философа в обществе и его ответственности перед обществом. Реально, всё что ты осознаешь в своей психике как реальность -- это результат сложной работы сложных нейронных сетей в твоей голове. Этот результат как-то связан с реальностью, но вот как именно -- это вопрос... Может быть очень по разному. Может быть у тебя отрезали болевой рецептор, а аксон его остался, и что-то там провоцирует спайки на этом аксоне, которые затем обрабатываются и долетают до твоего сознания как боль. И тогда боль -- это тень вот того "что-то там". А может быть кто-то иголкой тычет в болевой рецептор, и поэтому тот отправляет в ЦНС сигналы, которые ЦНС интерпретирует как боль. А может быть, ты веришь в то, что у тебя сейчас должна болеть нога, твоя психика поискала каких-нибудь сигналов, которые можно интерпретировать как болевые, не нашла. Тогда она снизила порог чуствительности к боли, и вот сигналы появились (болевые сигналы всегда летят в психику, они срезаются если они ниже определённого уровня, называемым порогом). И ты чувствуешь боль. Нельзя дать такое определение реальности, чтобы утверждение "то чего нет, не отбрасывает тени" работало бы всегда и при этом имело бы какой-нибудь смысл, отличный от тавтологичного. Полезнее всегда держать в голове, что тени -- это лишь тени. >> Вот, кстати, неплохой пример, где ты не понимаешь настолько глубоко, что не >> понимаешь, что не понимаешь, и вместо того, чтобы спросить, начинаешь нести >> бред. > Давайте спросим, что такое категории? В википедию. Или загугли по слову Загоруйко, есть книжка про категоризацию там, вообще для расширения программерского кругозора полезно почитать, но в частности избавляет мозги от путаницы в вопросах, что такое категоризация, что такое классификация (хотя все постоянно путают и употребляют эти термины часто взаимозаменяемо, но для чёткости понятий в своей голове, чтобы чётко мыслить, всё равно полезно различать). >> Когда ты говоришь "я", ссылаясь на себя -- это уже свидетельство того, >> что ты категоризируешь реальность: ты разделил реальность как минимум на две >> категории "я" и "не я". > Я - индивид. В этой фразе есть два слова. Каждое из них ссылается на категорию. Они собраны в грамматическую конструкцию, которая устанавливает определённого вида отношение между категориями. Как ты вообще программируешь, если ты не видишь что "я" -- это слово, это что-то типа переменной, которая ссылается на какое-то значение. "индивид" -- это тоже переменная, ссылающаяся на какое-то значение. Есть "синтаксис", точнее грамматика естественного языка, которая позволяет выстраивать слова в программы. Есть исполнитель программ на естественном языке -- психика слушателя твоих слов, которая, интерпретируя программу на русском языке, строит внутренний свой объект, описывающий смысл предложения. Ну то есть, да, естественный язык первым делом хочется воспринимать как декларативный, как язык описания данных, но я заверяю тебя, это не работает. Мозги именно что интерпретируют речь, чтобы выстроить смысл. А поскольку мозги разные, то и смысл из одних и тех же слов они извлекают разный.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #144

146. Сообщение от Michael Shigorin (ok), 02-Мрт-21, 19:51	+/–
> фларь и го , они просто созданы друг для друга. Как, собственно, и этот торчок (#137) с тором -- пришёл, нагадил в соседней ветке и думает, что ему ничего за это не будет. > кстати, го стал выбором малвареводов в 21м.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #143 Ответы: #147

147. Сообщение от Сейд (ok), 06-Мрт-21, 23:38	+/–
А почему он торчок и что ему будет?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #146

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

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