• Математики открыли новый фронт в битве с древней числовой задачей
    +2
    Вряд ли он будет полезен на что — то более, чем упражнение для реализации, но придумал алгоритм для поиска четных совершенных чисел (понравилась задачка, вот и уделил ей пару часов):
    — в левой колонке выписываем степени двойки, 1, 2, 4, 8,…
    — последовательно перебираем строки сверху вниз
    — для текущей строки, правую колонку начинаем заполнять снизу вверх.
    — первым выбираем максимальное простое число, не превосходящее следующую по порядку степень двойки.
    — в ячейку выше помещаем число, равное удвоенному текущему. продолжаем заполнять до верху.
    — считаем сумму, и проверяем текущее полученное число.
    — повторяем для остальных степеней двойки.
    Для 496 должно быть как — то так:
    1 — 496
    2 — 248
    4 — 124
    8 — 62
    16 — 31

    PS. Возможно алгоритм уже давно описан, хотя гугление сходу ни чего не показало, на всякий случай, прошу прощения за самопиар. Придумывание алгоритмов не является моей профессией.
  • Нам надо создать веб с чистого листа
    0
    Как мне кажется, чтобы придумывать интернет заново нужно, для начала, рассмотреть прежние use cases и как они реализовывались на практике. После этого, стоит попытаться сформулировать новые, которые отвечали бы современным запросам, прежде всего, потребителя. При этом, нужно четко разделять инфраструктурные вещи, например, протоколы передачи данных или стандарты разметки, которые должны понимать браузеры, пользовательские потребности, то, зачем сейчас он приходит в сеть и что ожидает получить, и поддержку разработчика, который вдохнет в инфраструктуру жизнь и представит ее пользователю.
    Совсем кратко, чисто для примера, потому что тема гигантская, и во многих моментах холиварная:
    — если не ошибаюсь, то, до 3 версии html вообще картинки не поддерживал и ориентировался только на текстовую информацию. это наложило свой отпечаток и на протокол http. да, он, в последствии, был дополнен, но может стоит попробовать сделать лучше? или подумать об использовании 2 протоколов, для текста и для потоковых данных? (инфраструктура)
    — месенжеры сейчас уступают по изобразительным возможностям полноценным браузерам, возможно стоит задуматься и сделать более интерактивным браузер, добавив ему такой вид ресурса, как канал месенжера и позволив посетителю параллельно взаимодействовать и с тем и с другим. (возможности для пользователя, возможности для владельцев ресурса)
    — современные фреймворки, вроде vue или react, пользуются большим вниманием со стороны разработчиков. возможно стоит попытаться понять, чтем это вызвано, и предложить им поддержку со стороны браузера для ускорения, и загрузки, и работы страницы? (разработка)
    — стилевые фреймворки, взять тот же бутстрап или квазар, для примера, предлагают достаточно единообразное оформление, чтобы вы могли сосредоточится на взаимодействии с пользователем. нужно попробовать понять, означает ли это появление нового вида приложений, взамен обычной desktop программы и можно ли как — то позволить им безопасно создавать файлы и получать доступ к оборудованию пользователя. как мне кажется, это может быть интересно и пользователям, ты не покупаешь программу навсегда, а берешь в краткосрочную аренду, просто позволив ей исполняться на твоем устройстве, и разработчикам, заставить человека за раз достать 1000$, как мне кажется, сложнее, чем заставить его 10000 раз достать по 10 центов. (инфраструктура, разработка, пользователь, бизнес)
    Если бы я решил придумать интернет заново, то я думал бы в какой — то подобной манере.
  • Госдепартамент США создаст свой великий файерволл
    0

    Ага, наши пытались технику победить, а амеры с правильной стороны подошли, Дурова за кошелек потянули, ну он и обмяк.


    PS Сорри, шел мимо, за комментарий глаз зацепился, ну и вырвалось.

  • Госдепартамент США создаст свой великий файерволл
    0

    Веб, как информационный контент, и способствовал развитию сети, как средства его доставки. Не придумай в свое время народ соединить компьютеры сетью, придумывать веб потребности и не возникло бы, а вот когда веб придумался — то рост его количества и стал главным мотиватором развития сети. Впрочем, это напоминает спор, что было раньше, курица или яйцо, предлагаю его не начинать.
    Я все таки не склонен драматизировать. Дождемся окончания перемен в мире. Думаю, к этому времени и с интернетом станет понятнее. Как знать, возможно связность станет не горизонтальной а вертикальной, и передачу данных будут обеспечивать спутники, а последнюю милю будет накрывать 5G, или даже 6G.

  • Госдепартамент США создаст свой великий файерволл
    +1

    Почему обязательно печальное? Точнее не так. Почему все обязательно должно идти по пути деградации? На мой взгляд, развитие интернета — это процесс сугубо прагматический.
    Оглянитесь на технологии. От интернета, в том виде как он был придуман, мало что осталось. Сайты, из вороха страниц с перекрестными ссылками стали полноценными приложениями. Изменились изобразительные возможности браузеров. Я уж молчу, как сильно поменялся бэкенд.
    Поменялась и ситуация. Всемирное разделение труда, потребностям которого интернет, на мой взгляд, достаточно успешно соответствовал, усиленно ломают. Чем это кончится — время покажет. Пока предсказывать не берется ни кто.
    Политика сильно влияет на интернет, но она влияет на него здесь и сейчас. Чем на более долгую перспективу мы будем пытаться смотреть, тем чаще будем обнаруживать влияние абсолютно практических вещей. По крайней мере мне так кажется.

  • Дешифровка текста методом частотного анализа
    0

    Шифры замены — это не все симметричные шифры.

  • Динамическое определение класса в Python
    0

    Баловство все это.
    Может кроме метаклассов. Да и они большинству разработчиков не известны, и это к счастью.
    Почему это плохо:


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

    PS. По поводу, если не создания, то динамической привязки методов, поищите информацию об unbound методах в питоне. В тройке от них отказались, оставив bounded и static, но зато вы окажитесь рядом с информацией, как добавить в класс метод даже не прибегая к метапрограммированию.

  • ООП: Кто взял Измаил? Вопрос принадлежности методов объекту
    0
    1. Смысл в том и есть, что вы неверно выделили объекты для реализации. Отсюда все противоречия. Если взять "источник питания" со свойством "напряжение", "нагрузку" со свойством "сопротивление" и объект "электрическая цепь", который будет содержать инстансы первых двух как свойства, то ваши 3 формулы станут методами последнего, и я не понимаю, что по вашему не так с ООП в данном случае.
    2. Сражение за Измаил часть более крупной системы под названием русско-турецкая война, где есть масса взаимодействующих объектов и условий. У вас возникло противоречие, потому что вы результат, в общем — то побочный, объявили главным, и кроме этого, вы его рассматриваете вне контекста системы. Битва за это место шла, потому что с него удобно атаковать неприятеля, или наоборот, защищаться. Здесь вообще могло не быть города.
    3. Здесь, наверное, был не прав, когда исключил кота из рассмотрения. Кот имеет свою реализацию важных методов "этоЕдаДляДанногоКота()", "требоватьЕдыОтХозяина()" и свойства "съедает за раз". Человек имеет свою реализацию метода "повестисьНаТребованияЭтойСкотины()". Миска вряд ли имеет важное значение и потребует реализации, главное, чтобы она была (ну или бог с ней, пусть будет). А вот корм скорее всего придется выделить ради хранения величины его запаса, только это будет не пакет, а корм как таковой. При желании можно пересчитывать в пакеты, килограммы, или миски. Естественно корм должен удовлетворять критерию "этоЕдаДляДанногоКота". Ну и нужен объект, который объединит все это в композицию, конечно, если вы не собрались прикармливать чужого кота, назовем этот объект "Семья". "Семья" корректно свяжет кота со своим хозяином и местом для хранения запаса кормов. Тогда реализация метода хозяина "покормитьСкотину()" станет простым перемещением количества корма в миску, в объеме который определяется потребностями питомца.
    4. Здесь прям не знаю что сказать. Для нужд игровой логики нужно хранить одни величины, например запас патронов, для нужд визуализации — другие, например, если вы в бою, то оружие может быть испачкано кровью. Что отнести к состоянию игрока, а что к его амуниции, наверное программисту виднее, вряд ли здесь все так уж однозначно можно расписать.
    5. Чтобы прикоснуться к предмету, он должен обладать поверхностью, ну или чем — то, что можно ею счесть (по этой причине, прикосновение к свету скорее всего невозможно, а прикосновение к воде можно принять с некоторыми оговорками). Раз уж мы собрались все трогать руками, они у нас должны быть. Прикосновение — это приведение расстояния между какой — то частью поверхности предмета и какой — то частью поверхности руки к нулю. Чтобы описать это, вам потребуется описать геометрическую форму руки и форму предмета. Какие нафиг интерфейсы!?!?
  • ООП: Кто взял Измаил? Вопрос принадлежности методов объекту
    +1
    1. Закон ома определяет не способ вычисления, например, силы тока через 2 оставшиеся, а взаимосвязь между величинами. Поэтому наличие 3 формул уместно.
    2. Стать хозяином Измаила не метод, а результат действия «победить в сражении».
    3. Действие происходит между человеком и пищей, человек перемещает пищу из холодильника в тарелку. Мотивация — это относится к бизнес логике, кормить кошку, кормить собаку, кормить себя.
    4. Вы напутали с интерфейсами. Выстрел — это часть интерфейса «стрелковое оружие». Для ножа говорить о выстреле, как и об оставшихся патронах неуместно.
    5. Чтобы что — то потрогать руками нужно, чтобы они у вас были, и объект, который вы собираетесь потрогать допускал это (попробуйте потрогать свет :)). Если эти 2 требования выполнены, то реализация операции «прикосновение» становится достаточно простым делом.
  • Парсер данных по произвольной грамматике в 400 строк
    0
    Как уже вам и советовали, для начала, напишите парсер чего нибудь попроще, ini, csv, json, yaml или xml. Попробуйте улучшить, например, по потреблению памяти, и/или скорости работы.
    После этого, попробуйте разбирать известные языки, минимальное подмножество Си или паскаля, например.
    Уже на этом этапе у вас появится пища для размышлений, и, возможно, вы захотите уделить время теории.
    Вы взялись за непосильную, для вас, а потому и бессмысленную работу. Будьте последовательны и терпеливы. Я искренне желаю вам удачи.
  • Программируем прямо в Nginx
    –1
    Реинкарнация mod_perl?
    Дурацкий вопрос — а зачем? Как только народ начнет накручивать логику на подобные сценарии, он наступит ровно на те же грабли, что возникали с mod_perl. Разве нет?
  • Что такое алгоритм?! Часть первая
    0
    Боюсь, автор много кармы на этой теме не заработает.
    Сама идея, взять инуитивно всем знакомое понятие и попытаться дать ему свою формулировку ни к чему кроме споров ни приведет. И дело даже в правильности или нет еще одного определения. В зависимости от того, с какой стороны на данное понятие смотреть, то или иное определение может точнее отражать суть.
    Например:
    • описание задачи и получения результата с точки зрения математики является алгоритмом? почему нет! последовательность шагов задается формулами, исполнителем является человек.
    • конвейер по сортировке, например, яблок на фабрике по их упаковке/переработке чем не механический компьютер со специальной программой (меньше размера А — отправить на корм скоту, меньше размера Б — на сок, меньше размера В — на пюре, ...)?
    • электронные устройства взаимодействуют с человеком, под час достаточно сложным образом (у меня микроволновка знает рецептов приготовления блюд больше чем я), всегда ли речь идет о присутствии процессора и программы как таковой? не уверен. хотя само взаимодействие вполне может подчиняться интуитивно понятному алгоритму.
  • Кто похоронит современный веб?
    0

    На счет ценности контента я не сомневаюсь. Я о другом.
    За все время своего существования html, css и js поменялись не особо сильно, особенно если сравнивать с инструментами и технологиями, которые появились рядом с ними.
    Typescript принес новые возможности, свойственные "настоящим" языкам, но в итоге он все равно транслируется в js. React и vue сделали более удобным переиспользование кода и реактивность, но все это опять приходит к html+css+js.
    Говорить о смерти современного веба можно будет тогда, когда будут исчерпаны все возможности тройки html+css+js и будет разработано что-то не менее гибкое, и не менее удобное. А пока сети расширяются, ресурсы компьютеров растут и всего этого хватит еще лет на 5 точно.

  • Кто похоронит современный веб?
    0

    Современный веб будет жить и здравствовать еще лет 5, а то и 10. Пока технологическая сложность не превысит разумных пределов. Уже сейчас мало знать html+css+js. Все чаще встречается TypeScript, да и react или vue, это уже совсем не то, что придумывали отцы основатели. Думаю дальше будет только хуже. По этой причине, уже существующие технологии будут выжимать по максимуму.

  • [Вопрос] В России запрещено порно?
    –15

    Почему — то вспомнился анекдот:


    • вопрос, сколько нужно сотрудников компании майкрософт чтобы поменять одну лампочку.
    • ответ, ни сколько. компания объявит темноту новым стандартом.

    Ну а если серьезно, давайте отменим все нормы морали и нравственности, не будем соблюдать их сами, и не будем учить этому наших детей. Только что вы будете делать, если эти нормы начнут нарушать в отношении вас?

  • Коронавирус: мир сошёл с ума
    0

    Сам факт, что данные по США из 2 источников различаются еще ни чего не значит. Ни чего не сказано про методы сбора информации. Да и вообще, смертность от вируса — это вопрос политический, особенно в США.


    По поводу претензий к ВОЗ: разве не национальные правительства принимают решения на своей территории, прислушиваясь, или игнорируя, рекомендации ВОЗ?


    Что, на мой взгляд, является достоверными и неоспоримыми фактами, важными для обывателя:


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

    Все остальное, вроде ответа на вопросы "кто виноват" и "что делать" — это удел профессионалов в предметных областях, и хочется верить, что они правильно расставят приоритеты и обязательно дадут своевременные ответы на них.

  • Как фильтровать дезинформацию, если она идёт из официальных источников?
    0

    Думаю, автор не разобрался в сути вопроса и не корректно раскрывает тему.
    Дезинформация — это есть умышленное искажение/сокрытие объективной, или распространения ложной, информации для облегчения достижения манипулятором своих целей во взаимодействии с аудиторией.
    Первый вопрос — цель, в дезинформации населения об эффективности масок? Профилактика паники и связанного с ней дефицита масок? Бред. Если меня убедить в бесполезности масок, сколько бы их ни было в аптеке, я ее ни когда не одену.
    Второй вопрос — выбор источников. NY Times точно не является авторитетом в микробиологии. Личность профессора тоже вызывает сомнения, раз он не пошел со своей "ценной" информацией в более специализированные издания и организации, где пришлось бы подкреплять свои слова реальными фактами.
    Третий вопрос — аналогия с простудными заболеваниями. Я не медик, и не микробиолог, просто, краем уха слышал, в сети или по ТВ, что "выхлоп" одного простуженного может разлетаться на 4 — 5 метров и проходит время, прежде чем он осядет, а окажись это правдой, то дискуссия о масках теряет свою значимость, потому что важна комплексная гигиена, ношение маски, мытье рук и лица, ношение верхней одежды вне дома и правильное с ней обращение в жилище.
    Четвертый вопрос — автор совсем не допускает, что истина может быть где — то посередине? Кто хоть раз надевал маску на достаточно длительный срок знает, что, чем больше маска находится на лице, тем чаще хочется ее поправить, или на время снять. Моя мысль: новая маска работает хорошо, чем дальше, тем больше маска провоцирует прикосновения к лицу и самой маске руками, что, в случае с "короной" не есть хорошо.


    Если коротко, то как — то так.

  • Нейросетевой калькулятор для сложения и вычитания не очень больших чисел
    +2

    Будущее давно предсказано. У Айзека Азимова есть коротенький рассказ, называется "Чувство силы". По моему, как раз про это.

  • Операционная Система «Сивелькирия»: вводное описание
    +4

    То, как я услышал сказанное автором: мы собираемся сделать нечто, работающее само по себе, выяснить, чем на самом деле занят ваш компьютер вы не сможете, вмешаться — в случае возникновения проблем — тоже, заботиться о ваших данных на компьютере вам тоже не придется, вы просто не будете иметь к ним доступа.
    Примеры реализаций "все в одном месте" мы видели и продолжаем наблюдать: Windows, есть еще Apple, Google со своим андроидом, яндекс, который свою ОС пока не запилил, но со своим браузером столько г… а на компьютер засовывает. Я не спрашиваю "зачем", как на этом зарабатывают большие корпорации — это более или менее понятно, просто, есть большие сомнения что вы это сможете, прежде всего финансово.
    Да и сама идея "ОС, как платформа для интеграции, максимально защищенная от вмешательства пользователя" плоха. Мы каждый день сталкиваемся с разного рода интеграторами, оператор связи постоянно "возникает" со своими предложениями по голосу/интернету/тв, банки, рекламные/информационные конторы, магазины ...., список у каждого свой. Сомнительно, что вам удастся внушить доверие потенциальным пользователям.

  • О проблемах транслятора Python и переосмысление языка
    –1

    Не склонен с вами согласится: ваша претензия скорее не к языкам с динамической типизацией, а к скриптовым языкам в принципе. Да, из соображений скорости проверка кода идет в 2 приема, при загрузке модуля на синтаксические ошибки, и в процессе работы на присутствие/отсутствие свойств и методов. Вы не хотите задуматься о смене языка на статически типизированный, раз со скриптами вам неудобно?
    К стати, определенная работа по преодолению этих недостатков идет: например в php поддерживает тайпхинты, да и в питоне есть модуль typing с аналогичными возможностями. Правда я не знаю, на сколько эти технологии устоявшиеся, потому что, пока, проще найти код без указания типов, чем с ними.

  • Новые фичи Python 3.8 и самое время перейти с Python 2
    0
    > 2.…
    Ок, кому — то чисто позиционные параметры нужны, я, хоть и не согласился, но понял «зачем». Чего я точно не понимаю, и вообще, слегка в шоке, «почему так»? Ну приспичило вам вам запретить обращение к параметру по имени, ну так возьмите и пометьте каждый такой параметр каким нибудь значком, или даже слово служебное придумайте. Все остальные параметры тусуем как хотим, а этот желаем видеть только на третей позиции, к примеру, и ни как иначе.
    > 4.…
    То, что в текущей реализации словарь оставляет значения в порядке вставки, это, скорее детали реализации, нежели дизайна языка. На мой взгляд, плохая идея — использовать эту особенность в чем — то, что будет запускаться не только вами и не один — два раза.
  • Новые фичи Python 3.8 и самое время перейти с Python 2
    +6
    Согласен с вами, странные плюшки.
    1. Новый оператор требует, как минимум, тщательного объяснения его применимости. Даже приведенный пример с массивом, сколько людей способно понять, почему в этом случае он не сработает? Извращенный ум и шаловливые рученки могут породить еще массу вариантов, которые нужно будет проверять, прежде чем вставлять в реальный код. И кто выиграет от такого «улучшения»?
    2. Было же простое и понятное правило, сначала идут позиционные, потом именованные аргументы. Зачем и кому потребовалась эта ужесть? Зачем в список параметров функции помещать что — то кроме параметров этой самой функции?
    4. Поправьте меня, если я ошибаюсь, но есть просто dict и есть OrderedDict, который помнит порядок вставки. Если для второго — ок, наверное это кому — то нужно, то для первого ценность нововведения сомнительна, на мой взгляд.

    П. п. 3 и 5 особой антипатии не вызывают, хотя, лично для меня, и особой ценности не представляют.
  • О проблемах транслятора Python и переосмысление языка
    0

    VM питона является стековой. Для, хотя бы, эмуляции параллельного исполнения приходится каждому "параллельному процессу" предлагать "свой" стек. Если произойдет исключение и мы его не поймаем, то начнется разматывание стека виртуальной машиной, которой сугубо пофиг дым на нашу "параллельность", ей про это ничего не известно.
    Моя мысль была в том, что: нельзя бесконечно курочить продукт несвойственными ему функциями, чем дальше, тем чаще это будет выходить боком. Или у вас другое мнение?

  • О проблемах транслятора Python и переосмысление языка
    0

    Собственно про сам язык:


    • реализация новомодных плюшек, вроде асинхронности или сопрограмм, желающие могут расширить этот список на свое усмотрение, на мой взгляд, является ни чем иным как хаком. когда язык придумывался вопроса о загрузке всех ядер процессора не стояло, и для этого в VM питона нет ничего.
    • чем сложнее вещь, тем проще ее поломать. достаточно только потерять осторожность. к новым плюшкам в питоне это тоже относится. генераторы — офигенно удобная абстракция, но не нужно забывать об осторожности. даже если мы просто засунем в генератор выборку данных из БД или сети, и забудем поймать какое либо исключение, как поведет себя программа? собьется алгоритм переключения стека или устоит? а если процесс долгоживущий? а если начать активно смешивать генераторы с асинхронными функциями и бросанием исключений? подозреваю что алгоритм сломается, вопрос только во времени, как скоро это случиться.
    • кто виноват, в том, что наш любимый язык иногда нас расстраивает? авторы? отчасти могут быть, особенно если языки создаются прямо сегодня. но python появился много лет назад, и всегда старался быть обратно совместимым с прошлыми версиями себя. естественно, чем дальше, тем может быть больше отрыв от сегодняшней реальности. не раз сталкивался с тем, что новые разработчики на python испытывают неоправданный оптимизм по отношению к языку, считая, "раз это заявлено и реализовано", значит это должно работать, какой бы код они ни написали. автор статьи, на мой взгляд, не плохо проиллюстрировал, что это не всегда так.

    От "кто виноват" перейдем к "что делать":


    • критически переосмыслить ядро языка. что не является востребованным или является устаревшим — убрать. ни каких договоренностей, или часть синтаксиса и полноценно поддерживается, или ни где не упоминается (я, к примеру, о публичных и приватных свойствах классов). одна возможность должна реализовываться единственным образом (например, свойства классов описываем в конструкторе, вычислимые помечаем декоратором методы класса, и ни как иначе).
    • основной аргумент Гвидо, против внедрения многопоточности был, как я помню: "невозможно внедрить поддержку многопоточности так, чтобы это не отразилось на скорости однопоточных программ". но, если нельзя сделать одну универсальную программу, может стоит задуматься о двух?
    • если взяться за реализацию полноценной параллельности/конкурентности, то нужно понять, что это будет, отдельная библиотека, часть синтаксиса, нечто среднее.
    • можно попробовать замахнуться на распараллеливание, например, циклов, а не только запуск функций в отдельном потоке.
    • если подытожить сказанное выше: проект php-ng успешно вылился в обновление языка и это способствовало его развитию и появлению новых возможностей, нужны люди, способные осилить python-ng.

    Прошу прощения за много букафф, всех с Новым годом :)

  • О проблемах транслятора Python и переосмысление языка
    +1

    Спасибо автору за статью. Хотя я и пишу на нем уже лет 10, я как та домохозяйка, что не задумывается об устройстве автомобиля, она просто садиться и едет за покупками. Было интересно.

  • Mozilla пообещала не включать шифрование DoH в Великобритании. Что это значит для России?
    0

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

  • Кармическое проклятье Хабра
    –1

    Обсуждение статей, в том числе и конструктивная критика — это полезно всем. Как иначе отличить действительно полезный материал от информационного шума?
    Другое дело офтоп. Я бы позволил автору статьи помечать коментарии, не связанные с темой материала, как офтоп и показывать их отдельно, а чтобы мотивировать авторов на эту работу — плюсовать им в рейт/карму. Да, возможно стоит обнулять плюсы с комментаторов, если автор отправил всю ветку в офтоп. Со спорными ситуациями администрация хабра может разобраться частным порядком.

  • Кармическое проклятье Хабра
    0

    Обсуждение статей это не общение само по себе. Это оценка статьи. Если кто — то начинает гнать офтоп, обычно, находятся желающие ему об этом напомнить.

  • Кармическое проклятье Хабра
    +2

    Терзают смутные сомнения, что базовый посыл вашей статьи неверен.
    Подозреваю, что хабр — это не про общение. Хабр — это про обмен качественной информацией и опытом (по крайней мере, я пришел на хабр именно за информацией). Карма оценивает качество поставляемой человеком информации, а рейт — оценивает доверие/одобрение к нему со стороны других. Одобрение со стороны авторитетного товарища, по идее, должно бы больше приносить кармы автору материала.
    Это только ГИПОТЕЗА! Хотя она и объясняет существование рейтинга и кармы. Правда, если признать ее правдоподобной, то весь анализ надо начинать снова, и не забыть проанализировать, в чем создатели хабра промахнулись с реализацией, если челу можно слить карму без объяснения причин.

  • Рассказ о том, как популярная JavaScript-библиотека начала выводить в терминал рекламу
    0

    Любые меркантильные отношения подразумевают обязательства обеих сторон, одна — оплатить определенное количество работы, другая — ее выполнить, в срок и качественно. Чем это отличается от обычного найма, например, фрилансера?
    Опять же, если добрый дядя оплатил фитчу, которую считал очень нужной, а автор не желает ее включать в пакет, как быть, если авторское право ни кто не отменял?
    В общем, странная идея.

  • И всё же C — низкоуровневый язык
    0

    Си, как язык, абсолютно не требует подгонки подо что бы то ни было. Тем более, что и самого определения "системное программирование" в строгой и исчерпывающей форме вряд ли существует. Граница довольно сильно размыта. Например: ядро ОС безусловно системный компонент, командная оболочка csh/bash… еще, скорее всего, системная программа, утилиты, вроде find/wc уже ближе к прикладным, куда отнести KDE или XFce с гномом — это вообще тема холиварная. :)
    Моя мысль была проще: если компилер может собрать самодостаточный файл, который можно запустить на голой железке, то язык, им реализуемый, можно назвать системным. И кстати, я не ограничивался одним Си. :))

  • И всё же C — низкоуровневый язык
    0

    Здесь ключевой момент — это способность работать без ОС. Интерпретируемые языки, даже с промежуточным представлением кода, сразу мимо. Для компилируемых — все зависит от того, можно слинковать с бинарником все зависимости или нет (сюда входит и рантайм самого языка, который, теоретически, может зависеть от наличия тех или иных библиотек и сами библиотеки, которые используются программой).

  • И всё же C — низкоуровневый язык
    0

    Язык Си безусловно низкоуровневый, как и всякий другой, который может создавать бинарь, способную работать на голом железе (ОС сюда входит, вместе со всеми своими компонентами в виде драйверов, модулей… ).
    По поводу конфликта интересов прикладных и системных разработчиков — здесь сложно однозначно говорить, что Си тому виной. К примеру, разработчики БД стараются сами управлять взаимодействием СУБД и дискового хранилища, чтобы получить максимум скорости, но, на мой взгляд, здесь больше борьба с ОС, чем с компилятором.
    По поводу памяти, кто мешает запросить у ОС кусок памяти достаточно большого размера и самому рулить его нарезкой под свои нужды? А вот следить, чтобы он не ушел в swap, больше чем нужно — это уже опять борьба с ОС, и компилятор здесь ни при чем.
    Аппаратные платформы совершенствуются. Все идет в сторону параллельного и асинхронного исполнения кода. Но винить Си в отставании, на мой взгляд странно. Потоки и процессы — это не аппаратная, а программная абстракция, и так, или иначе, но именно из этого языка их реализация ушла в другие, а не наоборот.
    По поводу, например, расширенных инструкций процессоров от Intel терзают смутные сомнения, что компании AMD будет позволено их реализовать в полном объеме, а значит авторам компиляторов каждый раз придется решать: работаем везде, или по максимуму, но только здесь.
    По поводу стандарта, это каждый решает для себя сам. Я только недавно выучил этот язык, и просто стараюсь не использовать конструкции, работу которых не понимаю. Про сам стандарт наслышан. Как по мне, 900 страниц — это капец как много. Стоит написать его с нуля, не привязываясь к существующим реализациям и не оставляя неопределенностей. Несоответствие стандарту автоматически не делает компилятор непригодным к использованию, но может мотивировать к исправлению проблем в них. Особенно, если о них постоянно будет кто — то напоминать.

  • [ВОЗМОЖНО] СОРМ расшифровывает HTTPS трафик к Mail.ru и ICQ
    0

    Моя мысль была такая:


    1. Вся история вокруг сертификатов строится исходя из того, что атакующий не может влиять на трафик и dns и, следовательно, обе стороны соединения могут обращаться к издателю сертификата как к удостоверяющему арбитру.
    2. Федералы вроде как могут влиять на маршруты и dns.
    3. Если они смогут завернуть процедуру выписки сертификата на себя, разве это не приведет к утечке ключей? Осталось только понять на сколько это возможно, и на сколько федералы готовы играть в долгую.
  • [ВОЗМОЖНО] СОРМ расшифровывает HTTPS трафик к Mail.ru и ICQ
    +1

    Незаметнее всего было — бы попытаться прослушать процесс выписки сертификата.

  • Почему const не ускоряет код на С/C++?
    0

    Рискну предположить, что const является семантическим правилом, работающим на этапе анализа исходного кода, и на генерацию целевого кода, скорее всего, ни как не влияющим.
    Пометка значения как константа — это скорее семантическое правило "любой код, который попытается изменить это значение — неверен" чем оптимизация (хотя, возможно, какой — то из компиляторов и умеет использовать это при генерации целевого кода).

  • Зачем современную веб-разработку так усложнили? Часть 1
    0

    Был, а возможно и есть, такой дядька, Дэн Седенхольм, благодаря которому я познакомился с термином "пуленепробиваемый веб дизайн", сейчас этот подход похоже не особо котируется. Наверное стоит начать сожалеть об этом.

  • Зачем нужны дженерики в Go?
    0

    Прошу прощения, не соображу, а как тогда будет выглядеть универсальная функция Sort, работающая абсолютно с любым типом, и встроенным, и кастомным?

  • Транспортная система у нас и у них или “Автовокзалы против агрегаторов 2”
    +3

    Кому интересно, может попробовать разобраться, кто у нас в стране и за что должен отвечать. Я, с момента покупки своего авто, именно этот вид транспорта предпочитаю.


    Как я понимаю:


    • за внутренние перевозки пассажиров, в пределах одного региона, отвечают местные власти. именно они должны следить, чтобы электричек/автобусов ходило достаточно, привлекая перевозчиков и договариваясь с РЖД о сумме дотаций, там где пассажиров на нормальную загрузку не хватает.
    • кто отвечает за межрегиональные перевозки я, честно говоря не вкурсе.

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


    Опять же, на мой взгляд, глядя на все это со стороны, ноги у этих проблем растут из за пробелов в законодательстве. Если агрегатор посредник, то я, как клиент, должен быть перенаправлен на прямой контакт с продавцом услуги, и мне абсолютно ровно, как они потом между собой выручку делят. Все вопросы с продавца. Если же, услугу мне продает агрегатор, то и все риски он должен принять на себя (и то, что техника исправна, и то что водитель в здравом уме и твердой памяти, и подготовки у него хватает).


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

  • Программирование на JavaScript для токарного станка
    0

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