Но можно же выложить дамп того что в публичном доступе? Затереть в базе таблицы с пользователями, сообщениями, приватными разделами форума и всё такое чувствительное. Это не кажется прямо сложная и непосильная задача. Жалко же терять такой 25-летний уникальный архив данных.
Он не про разработку, а про отладку. А что такое отладка электроники? Конструкторы наконструировали, схемотехники нарисовали, трассировщики развели. Потом попадает всё программисту, который напрограммировал прошивку. Включаешь, а оно там работает как-то не так как должно. Может в схеме ошибка. Может в трассировке ошибка. Может в конструкции что-то придавило и на землю коротит, может в прошивке ошибка, может в кабеле провода перепутали зеркально, может в протоколе взаимодействия с ПО ошибка. А потом всё вроде и хорошо, а нагрели до +40 и какие-то сбои посыпались) Кто будет разбираться на этом стыке? Как правило это не дизайнеры, не конструктора, не технологи и тем более не менеджеры. Тестировщики начинают нормально работать когда базовая разработка уже сделана и оно как-то что-то работает - можно выявлять, можно проверять.
С инженерными образцами обычно работают в связке программист/схемотехник. И если над одним сложным устройством будет работать только один программист и один схемотехник, то это может затянуться. А если таких команды 2-3-4, которые за разные узлы отвечают, то всё солидно так ускоряется. Есть конечно программисты, которые не схемотехники, но умеют нормально работать с измериловкой и понимают в схемоте - такие и аппаратную отладку тянут в одиночку. Но я тут недавно открытие сделал, что оказывается далеко не все кто умеют прогать FPGA или МК способны эффективно тащить аппаратную отладку. Причём речь не о работе с чем-то специфичным типа анализатор спектра или измеритель фазовых шумов, а хотя бы о вдумчивом применении осциллографа.
Я бы не сказал. По астрофизике статей немало и их хорошо принимают. Даже несмотря на то, что немалая часть отношение имеет больше к философии, чем к физике. Но даже их нормально понимать всё же нужна какая-то физическая база.
Заголовок с объёмом информации должен быть как-то логически связан. И когда люди читают хабр, то подразумевают это априори, так как вроде бы это ресурс претендующий на интеллектуальность. Но это должна быть нормальная смысловая логика, а не как в моём вышеприведённом комментарии, сарказм которого аудитории хабра оказался непостижим настолько, что она принялась мне карму сливать)
В 20:31 МСК (00:31 местного времени) электроагрегат №2 Саяно-Шушенской ГЭС был выведен из резерва и запущен в работу.
Ранее как-то не обращал внимание на этот удивительный факт - какая необходимость была вводить агрегат в работу ночью? После ввода в работу за ним нужно же пристальное внимание в первые часы. Дневное время по-любому предпочтительнее ночного же!
Опрос некорректный - мне они все нравятся) Да и вообще, при взгляде из современности, где всё стало уныло-одноцветно-одинаковым, выглядит очень интересно разнообразное буйство конструкций и решений в момент становления как-то сферы, в данном случае - сферы мобильный ПК.
VHDL/Verilog - это всё же не "чистое" программирование наподобии софта для ПК. Если человек не понимает архитектуры FPGA, элементов аппаратной логики и не имеет представление о схеме тактирования, то ничего хорошего он не напрограммирует. Это всё же больше инженерия, нежели программирование.
Проблема в том, что вы купите, я куплю, он купит, а остальные тысячи как лили в облака - так у будут лить дальше. Потому что им так проще: не надо ничего покупать, подключать, какие-то программки для чтения/записи ставить, короче не надо во всём этом разбираться - жмак-жмак и архив типа отправлен в облако. А о надежности люди обычно думают после часа Х, а не до. Это если бы облака через каждый месяц лопались - тогда бы с ростом пострадавших у людей какие-то мысли стали бы появляться, а так взывать к благоразумию обычно бесполезно.
Он пишет не про бетон же. А про то что эта технология греет воду вокруг себя. Если такими штуками утыкать всё побережье на глубине под километр как думаете как это скажется на биосреде?
Само по себе это может быть и не страшно. Страшно то, что на одном сервисе по аккаунту узнается номер. На другом сервисе по номеру узнается ещё что-то. И т.д. и т.п. В результате из вроде бы отдельных некритичных данных можно собрать комплект данных, который уже будет критичен. Поэтому внимание нужно уделять вот таким вот подобным вроде бы мелочам для постоянной минимизации потенциального ущерба.
Месяца два назад на хабре была статья где человек сделал подобное исследование и был в шоке насколько всего везде можно понабрать.
Вы неверно поняли посыл статьи. Автор не противник ИИ. Он пишет о том, что бизнесу нужен не ИИ, а ML. Что не нужно тратить х10 денег на технологии ИИ для реализации текущих задач, когда с этим быстрее, точнее и дешевле справится технология ML за х1 денег.
Но можно же выложить дамп того что в публичном доступе? Затереть в базе таблицы с пользователями, сообщениями, приватными разделами форума и всё такое чувствительное. Это не кажется прямо сложная и непосильная задача. Жалко же терять такой 25-летний уникальный архив данных.
При низких скоростях эти 10% особо так и в глаза бросаться не будут. Хороший баг... необычный)
Он не про разработку, а про отладку. А что такое отладка электроники? Конструкторы наконструировали, схемотехники нарисовали, трассировщики развели. Потом попадает всё программисту, который напрограммировал прошивку. Включаешь, а оно там работает как-то не так как должно. Может в схеме ошибка. Может в трассировке ошибка. Может в конструкции что-то придавило и на землю коротит, может в прошивке ошибка, может в кабеле провода перепутали зеркально, может в протоколе взаимодействия с ПО ошибка. А потом всё вроде и хорошо, а нагрели до +40 и какие-то сбои посыпались) Кто будет разбираться на этом стыке? Как правило это не дизайнеры, не конструктора, не технологи и тем более не менеджеры. Тестировщики начинают нормально работать когда базовая разработка уже сделана и оно как-то что-то работает - можно выявлять, можно проверять.
С инженерными образцами обычно работают в связке программист/схемотехник. И если над одним сложным устройством будет работать только один программист и один схемотехник, то это может затянуться. А если таких команды 2-3-4, которые за разные узлы отвечают, то всё солидно так ускоряется. Есть конечно программисты, которые не схемотехники, но умеют нормально работать с измериловкой и понимают в схемоте - такие и аппаратную отладку тянут в одиночку. Но я тут недавно открытие сделал, что оказывается далеко не все кто умеют прогать FPGA или МК способны эффективно тащить аппаратную отладку. Причём речь не о работе с чем-то специфичным типа анализатор спектра или измеритель фазовых шумов, а хотя бы о вдумчивом применении осциллографа.
Я бы не сказал. По астрофизике статей немало и их хорошо принимают. Даже несмотря на то, что немалая часть отношение имеет больше к философии, чем к физике. Но даже их нормально понимать всё же нужна какая-то физическая база.
Заголовок с объёмом информации должен быть как-то логически связан. И когда люди читают хабр, то подразумевают это априори, так как вроде бы это ресурс претендующий на интеллектуальность. Но это должна быть нормальная смысловая логика, а не как в моём вышеприведённом комментарии, сарказм которого аудитории хабра оказался непостижим настолько, что она принялась мне карму сливать)
- В заголовке пять правил?
- Пять.
- В тексте правила перечислены?
- Перечислены.
- Их пять штук?
- Пять.
- Чего ж тебе ещё надо собака? (с)
Ранее как-то не обращал внимание на этот удивительный факт - какая необходимость была вводить агрегат в работу ночью? После ввода в работу за ним нужно же пристальное внимание в первые часы. Дневное время по-любому предпочтительнее ночного же!
Опрос некорректный - мне они все нравятся) Да и вообще, при взгляде из современности, где всё стало уныло-одноцветно-одинаковым, выглядит очень интересно разнообразное буйство конструкций и решений в момент становления как-то сферы, в данном случае - сферы мобильный ПК.
Хабам-то соответствует. Но теги, конечно, доставляют.
Человечество входит в эру, в которой аудио и видео доказательством уже не являются. И чем дальше будет - тем ситуация будет усугубляться.
VHDL/Verilog - это всё же не "чистое" программирование наподобии софта для ПК. Если человек не понимает архитектуры FPGA, элементов аппаратной логики и не имеет представление о схеме тактирования, то ничего хорошего он не напрограммирует. Это всё же больше инженерия, нежели программирование.
Проблема в том, что вы купите, я куплю, он купит, а остальные тысячи как лили в облака - так у будут лить дальше. Потому что им так проще: не надо ничего покупать, подключать, какие-то программки для чтения/записи ставить, короче не надо во всём этом разбираться - жмак-жмак и архив типа отправлен в облако. А о надежности люди обычно думают после часа Х, а не до. Это если бы облака через каждый месяц лопались - тогда бы с ростом пострадавших у людей какие-то мысли стали бы появляться, а так взывать к благоразумию обычно бесполезно.
Он пишет не про бетон же. А про то что эта технология греет воду вокруг себя. Если такими штуками утыкать всё побережье на глубине под километр как думаете как это скажется на биосреде?
А может человечество уже всё и вот-вот столкнётся с пределом познания? Автор из будущего пишет - ему виднее!
В отличии от BTRFS нативной поддержки ZFS в ядре всё равно же пока ещё нет.
Может человеку нативная поддержка ZFS нужна)
В избранном у меня её нет, а найти на хабре, что было 3 месяца назад очень сложно - сходу не получилось(
Само по себе это может быть и не страшно. Страшно то, что на одном сервисе по аккаунту узнается номер. На другом сервисе по номеру узнается ещё что-то. И т.д. и т.п. В результате из вроде бы отдельных некритичных данных можно собрать комплект данных, который уже будет критичен. Поэтому внимание нужно уделять вот таким вот подобным вроде бы мелочам для постоянной минимизации потенциального ущерба.
Месяца два назад на хабре была статья где человек сделал подобное исследование и был в шоке насколько всего везде можно понабрать.
В пространстве и времени?
Вы неверно поняли посыл статьи. Автор не противник ИИ. Он пишет о том, что бизнесу нужен не ИИ, а ML. Что не нужно тратить х10 денег на технологии ИИ для реализации текущих задач, когда с этим быстрее, точнее и дешевле справится технология ML за х1 денег.