Давайте. Уборщик это максимально низкоквалифицированная профессия, не требующая никакого образования, тем более высшего, короче предварительного вложения времени и денег, вот те швабра и ведро — погнал.
— средняя зарплата уборщика 12$ в час в США,
— средняя за программиста 33$ в час, что в 3 раза больше чем уборщика (Вы же не сравниваете зп программиста на удаленке ТАМ и уборщика ТУТ?)
— грубая средняя зарплата актера основного состава 100000$ в час (10 часов, а может и меньше, на сьемки своих 10 минут экранного времени) что в 3000 раз дороже программиста. Актер должен какать золотыми слитками за такие деньги, при том что актер, что программист наемный рабочий. Не может быть справедливой разница в цене времени наемного рабочего в 3000 раз.
В другом правом поле альтернативной вселенной, каждому программисту тоже могли бы платить миллионные гонорары с дивидендами, и что бы его код не мог быть дописан кем то другим, как роль не может быть доиграна другим актером, чтобы также на 3 порядка взвинтить цену.
Если в скором будущем нейросеть позволит нарисовать качественно лицо нужного актера поверх любого стажера, работающего за зарплату уборщика, и тем самим убавить гонорары/бюджеты, то думаете профсоюз актеров или суды позволят это сделать? Программиста просто практически ничто не защищает от увольнения в случае, когда он сильно много хочет, таковы законы, вот и все. А так актер что, родился и через несколько лет может сниматься, не закончив даже школу.
Ну такое. Смотря что за создали и какая маржа. Актеры вон за 10 минут лям баксов получают- должна ли нас мучать совесть, что из-за нас они не получили 5 лямов за те же условные 10 минут экранного времени? Меня вот нет. Да, если у фильма адекватный бюджет, то другое дело, но надо и просить вменяемые деньги за него, а не десятки лямов на актерский состав уходит, а потом с нас эти деньги требуют. Разница между 25$ в час в обычного западного человека, и актера, который делает 100к в час это овердофига. Это просто актер, наемный рабочий, а не бизнесмен. И все эти правила игры и их правильность зависит только от принятых законов.
Ну в целом решается выделением под торренты отдельного hdd.
Ага люди будут ставить в ноут отдельный HDD для торрентов. 100%. Да даже будь это настольный, никто специально не будет туда что то покупать, как и тулить старое шумящее и жрущее ради раздачи ноунеймам в интернетах.
Или такой работаешь в IDE c докерами и kubernetes и прочим фаршем и будешь еще отгрызать ресурсы под торренты, которых всегда мало. Не для того ты покупаешь рабочий комп, чтобы все время держать торренты. Абсолютно. Качаешь ты 10 минут, а потом у тебя весь день это должно висеть. Так что раздача с одного пк это не вариант. Тем более, посмотрев фильм ты его удаляешь, ты не будешь хранить его ради раздачи непонятное количество времени, место на SSD не резиновое и дорогое.
И грузят торренты железо немало и цп куда заметнее, чем пару процентов, а дисковое IO и сеть просто выжирают, и дело тут не в самой пропускной способности, а в количестве блоков и пакетов. Не даром ведь провайдеры их не любят и режут, или подрезают.
Было бы конечно круто, чтобы в роутер добавили SoC специально под торренты, но этого конечно не будет. Так что отдельный одноплатник тут единственное вменяемое решение- там можно и старый винт заюзать, потому как можно его прицепить хоть в туалете и никому он там шуметь не будет.
А вот насчет «поубавить аппетиты» — тут я категорически против.
Так этот рынок решил пиратство- плохо, любой продукт может быть куплен только за запрошенную сумму денег. Тут, как говорится, либо крестик, либо трусы...))
Сколько не ест, оно ест, более чем калькулятор. Особенно если это не топовый игровой пк, а мобильная платформа типа ноутбука. А если это рабочий пк, то это неприемлемо, ибо там ресурсов всегда не хватает, и мирится с этим никто не будет. Да и основная нагрузка еще ж на диск, а это узкое место. С играми та же песня- ну то будет добровольно отдавать пару FPS ради того, чтобы торрент вертелся? Хотя, если торрент бы запускался и отдавал только при относительном простое, то да уже легче, но все ровно отдельная выделенная торрент качалка (точнее отдавалка) была бы намного лучше.
Но в ситуации, когда владелец прав предпочитает полностью лишить мир некоего продукта лишь бы не отдавать просто так
Как то странно звучит. Воровать плохо, но чтобы [Вы] не воровали, надо свой продукт отдавать за бесплатно? Так?)) Свои игры тоже будете бесплатно отдавать, чтобы не воровали?)
Воровать плохо, но когда правообладатель хочет сильно много денег и вполне богато живет, то да пиратство может быть выходом. Я например не понимаю, почему какая то «звезда» ситкомов должна получать более ляма долларов за 10 минут экранного времени, тогда как столько же, а то и меньше, получает ученый, всю жизнь работавший над своим открытием и в конце-концов получивший Нобелевку. Потому в этом случае пиратство праведное- надо убавить аппетиты.
Да, тут есть проблемы. Не каждому подходит раздача с основного пк- фильм ты может и посмотрел, а дальше хочешь работать или в игрушку, а торрент жрет заметные ресурсы, причем не в прогнозируемое время, так что держать его продолжительное время в фоне это не вариант.
Тут надо простое аппаратное решение- какой-нить ARM одноплатный пк, размером с роутер, в который можно поставить пару SD карт/SSD на худой конец шумящий 2.5 HDD. Чтобы оно было максимально энергоэффективно, бесшумно и занимало минимум места возле роутера. Ну и чтобы трекер считал отдачу с него по ИД, который может юзать основной пк для скачки.
В общем то и сейчас ничто не мешает любому собрать такое за 20$ и со старого винта, но кто будет с этим заморачиваться… Был бы в продаже такой torrent-pc другое дело. Можно было бы запилить, чтобы при простое он бы мог скачивать раздачи с малым количеством сидов, для поддержки раздач.
Самое ржачное то, что от ракет печенегов это вообще никак не защищает- если раньше вообще без всякой спутниковой навигации они летали на огромные расстояния, то неужели они думают, что гипотетическая ракета не долетит последние 5км на гироскопе к цели?
Некоторые так волнуются про жор памяти когда 16гб стоят сотню долларов.
ммм думаете тут у людей по 4гб стоит на машинах?) Этих самых 16 гб давно ни на что не хватает, а больше не поставишь :) Хотя всего еще 5-6 лет назад это был достаточно серьезный объем.
Это несвязанные вещи. Любой BSOD системы, внезапная смерть аккумуляторов или ИБП под нагрузкой (а вероятность их отказа гораздо выше чем выделенной слаботочной цепи), и все, данные улетели период с последней синхронизации, что может быть и несколько дней. Да и когда синхронизировать? При переходе на ИПБ? Не подходит- данные могут еще добавиться. В конце заряда ИБП? Рискованно- может внезапно отрубится, если аккумуляторы несвежие и проблемные. Накопитель должен быть автономным, лишнее звенья увеличивают вероятность отказа.
Дак 15+ лет назад оно и в принципе не могло взлететь, flash есть уже давно, но SSD взлетели на массовый рынок совсем недавно, по все тем же причинам, а гибрид ssd тем более должен появится позже. Такая технология появилась слишком рано для своего времени на дорогой и относительно примитивной элементной базе. А так, какой DevOps бы отказался от SSD, который не изнашивается от записи и работает на порядок быстрее, пусть и на порядок дороже?
Кому нужны RAM диски — они их используют, бэкапятся на ходу и т.п.
Ну RAM диски, особенно программные (т.к используют дорогую память сервера, а не дешевую прошлых поколений), это костыль, дабы обойти узкое место в IO. Есть те, кто откажется от «лишней» серверной производительности без плясок с бубнами, так как с их точки зрения это обычный SSD? Нет, просто это упирается в деньги. Ну и ионисторы более подходящее отказоустойчивое решение.
Для серверных накопителей это копейки (посмотрите цену на серверные SSD), к тому же нужно учесть, что рост производительности и отказоустойчивости (упразднение деградации flash) снижает потребность в репликах (что тоже деньги и потребление) и проблемы их синхронизаций, и стоимость их обслуживания. Очевидно, прямое назначение- высоконагруженные базы данных, то есть таких серверов в серверной немного на фоне, и то дополнительное потребление на перезаряд DDR3 не являлось бы каким то заметным недостатком. А если подойти к проектированию с умом, можно было бы включать банки RAM по требованию с каким то механизмом маппинга и уплотнения адресного пространства.
Если прикинуть стоимость 1тб DDR3, себестоимость которых бы снижалась после утрате актуальности и наличия множества невостребованных производственных мощностей, то выходят совсем уж небольшие цифры, если взглянуть прямо сейчас на китайские мелкооптовые цены на чипы taobao- 5$ за 8гб чип, то есть 800гб всего 500$, но при крупном опте с завода вероятно еще меньше. Ну выйдет 800-1000$ за 1Тб RAM/SSD — это страшные деньги для серверных решений?
Мне вот не понятно, почему нельзя скрестить SSD и RAM на одной плате, добавив туда ионистор (может пару независимых трактов питания для резерва и может еще и маленький li-on), который при пропаже питания делает перенос данных на flash патчингом по журналу? Да сейчас в SSD есть RAM буфер, но почему не взять и сделать основным хранилищем RAM, который по объему равен Flash и в тех редких случаях, когда сервер обесточивается или ресетится синхронизировать flash с RAM.
В основном, конечно, это для серверных применений, тогда мы получаем кучу преимуществ:
— отсутствие проблемы лимитированного количества циклов записи
— можно применять чипы и производственные мощности дешевой RAM предыдущего поколения, которая уже не годится для своего прямого назначения и не востребована рынком, зато цена за 1гб ниже, например как сейчас DDR3, что расширяет для производителя срок службы технологии и повышает окупаемость мощностей.
— минимизация износа flash памяти, особенно для серверных решений (так как flash бы использовалась только при shutdown и запланированных синхронизациях)
— рост производительности IO на порядок — DDR3/4 все таки быстрее Flash SSD, для баз данных это бы означало, что производительность недалеко от in-memory баз, но при этом энергонезависимая.
— можно применять flash более дешевую, с меньшим количеством циклов записи
На полноразмерной PCI плате можно натулить немало так чипов RAM даже DDR3 и выйдет весьма существенные объемы в единицы TБ.
Всегда было интересно, что мешает вместо спутников в таких проектах использовать аэростаты, летающие на 40км+ высоты? Это ведь на порядки дешевле, меньше задержки. Хотя, походу, тут юридические проблемы до 100км, так как являеться воздушным пространством стран, но с другой стороны как летают все метеозонды? У них есть разрешения от каждой страны на Земле?
Не так давно ловил себя на мысли, что нынче наколхозить летающий торрентр трекер с хранилищем в десяток террабайт и весом в 0.5-1кг вместе с аккумуляторами не составляет особого труда, когда 1ТБ уже на одной микроСД карте и было бы прикольно, забавы ради, замутить такое, отправив его в свободное воздушное путешествие по континентам))
Вижу понимать как работает useState изнутри никому не надо. Дали функцию, вызывайте, а как она маппит состояние на компонент и где его хранит никому не интересно. В принципе правильно, если юзание this это уже большой челендж :)
да, знакомо) Я вот 13 лет с JS суммарно, но на собесах просто большая половина мозга отваливается или занята не тем, чем надо, но все ровно половины мозга обычно достаточно для прохождения тех интервью.
Но вот лайвкоддинг в маленькой формочке на каком то сайте вообще застал врасплох, я там даже не мог нормально воспринять шрифт, цветовую схему и банально скобки расставить, буквально ослеп ибо не было еще и подсветки блоков/сигнатур.
Начал писать код, просто чтобы начать что то писать, до конца не поняв ТЗ по реализации API, ибо я ожидал от них спецификацию по интерфейсам, а они примеры вызовов налепили.
Короче, я как в универе- лучше начать что то делать, чтобы не совсем зафейлить). Очень долго рожал, как потом уже понял, посредственную фигню. Тупка жесткая, сам себе удивился… Просто дно, еще и при этом, в качестве хобби, коллаборатор/около ментейнер пакетов, один с которых с 17лямами загрузок в месяц и 1,5к зависимых модулей :)
Несомненно дешевле, чем форк IPC, но не дешевле чем если ничего никуда не передавать и выполнять силами текущего инстанса, а остальные запросы пусть балансир другим пихает :)
мы всё равно будем вынуждены делать все операции в том же потоке.
Да, но с точки зрения клиентов им есть ли разница в каком потоке на сервере был обработан их запрос? Им интересна только задержка ответа. Если речь о делегировании работы другому потоку (основной получил, передал данные воркеру ожидает ответа, попутно обрабатывая другие запросы в евентлупе) то это ничем не отличается от того, если бы запрос пришел другому инстансу через балансир, только еще одно лишнее звено (балансир->инстанс1->воркер1). Если речь что один запрос можно параллельно обработать- половину задачи одним потоком обработать, пока второй решает вторую половину, то тут уже вылазит проблемы синхронизации потоков и зависимостей данных, т.е задачи могут плохо распараллеливается если следующие вычисления базируются на предыдущих. Но к этому надо добавить оверхед на передачу и получения данных воркерам. А ведь даже тяжелые запросы это всего миллисекунды. Суть ведь равномерно загрузить ядра/цп, чтобы потоки не гуляли, при этом обеспечить допустимую задержку отклика для каждого запроса. Какие то феншуи делать для размазывания по воркерам запросы в миллисекунды как бы бессмысленно для большинства задач в вебе.
само по себе дробление это не бесплатная операция, мы забиваем очереди event loop.
В чем разница? 10 инстансов и 1 инстанса + 9(10) воркеров? Воркеры тоже не бесконечны- не на каждый ведь запрос можно выделить свой воркер, так что будем иметь тоже самое узкое горлышко, только в другом потоке. Дробить задачи так чтобы каждый чанк не исполнялся более пары мс не забьет очередь, чтобы существенно отразилось на производительности. Трансфер данных воркерам тоже не бесплатно, и вероятно дороже.
Ну правильно, чанки фактически решают проблему отзывчивости и «блокировки» других запросов, давно ей пользуюсь. Задачу, которую нельзя разбить на чанки я не могу представить, потому как ее нет. Благодаря async/await и немного хелперов вообще не отличается от написания синхронного варианта, уже больше не надо извращаться для такой техники. В итоге мы перегрузку ЦП просто нивелируем добавлениям инстансов в пул балансира, простым горизонтальным масштабированием — простейший вариант. А передавать запросы на воркеры как бы лишние телодвижения.
Даже как то удивительно, что ее так мало юзают другие, я в чужих реальных проектах этого не видел, а ведь банальный подход.
— средняя зарплата уборщика 12$ в час в США,
— средняя за программиста 33$ в час, что в 3 раза больше чем уборщика (Вы же не сравниваете зп программиста на удаленке ТАМ и уборщика ТУТ?)
— грубая средняя зарплата актера основного состава 100000$ в час (10 часов, а может и меньше, на сьемки своих 10 минут экранного времени) что в 3000 раз дороже программиста. Актер должен какать золотыми слитками за такие деньги, при том что актер, что программист наемный рабочий. Не может быть справедливой разница в цене времени наемного рабочего в 3000 раз.
В другом правом поле альтернативной вселенной, каждому программисту тоже могли бы платить миллионные гонорары с дивидендами, и что бы его код не мог быть дописан кем то другим, как роль не может быть доиграна другим актером, чтобы также на 3 порядка взвинтить цену.
Если в скором будущем нейросеть позволит нарисовать качественно лицо нужного актера поверх любого стажера, работающего за зарплату уборщика, и тем самим убавить гонорары/бюджеты, то думаете профсоюз актеров или суды позволят это сделать? Программиста просто практически ничто не защищает от увольнения в случае, когда он сильно много хочет, таковы законы, вот и все. А так актер что, родился и через несколько лет может сниматься, не закончив даже школу.
Ага люди будут ставить в ноут отдельный HDD для торрентов. 100%. Да даже будь это настольный, никто специально не будет туда что то покупать, как и тулить старое шумящее и жрущее ради раздачи ноунеймам в интернетах.
Или такой работаешь в IDE c докерами и kubernetes и прочим фаршем и будешь еще отгрызать ресурсы под торренты, которых всегда мало. Не для того ты покупаешь рабочий комп, чтобы все время держать торренты. Абсолютно. Качаешь ты 10 минут, а потом у тебя весь день это должно висеть. Так что раздача с одного пк это не вариант. Тем более, посмотрев фильм ты его удаляешь, ты не будешь хранить его ради раздачи непонятное количество времени, место на SSD не резиновое и дорогое.
И грузят торренты железо немало и цп куда заметнее, чем пару процентов, а дисковое IO и сеть просто выжирают, и дело тут не в самой пропускной способности, а в количестве блоков и пакетов. Не даром ведь провайдеры их не любят и режут, или подрезают.
Было бы конечно круто, чтобы в роутер добавили SoC специально под торренты, но этого конечно не будет. Так что отдельный одноплатник тут единственное вменяемое решение- там можно и старый винт заюзать, потому как можно его прицепить хоть в туалете и никому он там шуметь не будет.
Эм… Это как?))) Продавать бесплатно за 0$?))
Так этот рынок решил пиратство- плохо, любой продукт может быть куплен только за запрошенную сумму денег. Тут, как говорится, либо крестик, либо трусы...))
Как то странно звучит. Воровать плохо, но чтобы [Вы] не воровали, надо свой продукт отдавать за бесплатно? Так?)) Свои игры тоже будете бесплатно отдавать, чтобы не воровали?)
Воровать плохо, но когда правообладатель хочет сильно много денег и вполне богато живет, то да пиратство может быть выходом. Я например не понимаю, почему какая то «звезда» ситкомов должна получать более ляма долларов за 10 минут экранного времени, тогда как столько же, а то и меньше, получает ученый, всю жизнь работавший над своим открытием и в конце-концов получивший Нобелевку. Потому в этом случае пиратство праведное- надо убавить аппетиты.
Тут надо простое аппаратное решение- какой-нить ARM одноплатный пк, размером с роутер, в который можно поставить пару SD карт/SSD на худой конец шумящий 2.5 HDD. Чтобы оно было максимально энергоэффективно, бесшумно и занимало минимум места возле роутера. Ну и чтобы трекер считал отдачу с него по ИД, который может юзать основной пк для скачки.
В общем то и сейчас ничто не мешает любому собрать такое за 20$ и со старого винта, но кто будет с этим заморачиваться… Был бы в продаже такой torrent-pc другое дело. Можно было бы запилить, чтобы при простое он бы мог скачивать раздачи с малым количеством сидов, для поддержки раздач.
ммм думаете тут у людей по 4гб стоит на машинах?) Этих самых 16 гб давно ни на что не хватает, а больше не поставишь :) Хотя всего еще 5-6 лет назад это был достаточно серьезный объем.
Ну RAM диски, особенно программные (т.к используют дорогую память сервера, а не дешевую прошлых поколений), это костыль, дабы обойти узкое место в IO. Есть те, кто откажется от «лишней» серверной производительности без плясок с бубнами, так как с их точки зрения это обычный SSD? Нет, просто это упирается в деньги. Ну и ионисторы более подходящее отказоустойчивое решение.
Если прикинуть стоимость 1тб DDR3, себестоимость которых бы снижалась после утрате актуальности и наличия множества невостребованных производственных мощностей, то выходят совсем уж небольшие цифры, если взглянуть прямо сейчас на китайские мелкооптовые цены на чипы taobao- 5$ за 8гб чип, то есть 800гб всего 500$, но при крупном опте с завода вероятно еще меньше. Ну выйдет 800-1000$ за 1Тб RAM/SSD — это страшные деньги для серверных решений?
В основном, конечно, это для серверных применений, тогда мы получаем кучу преимуществ:
— отсутствие проблемы лимитированного количества циклов записи
— можно применять чипы и производственные мощности дешевой RAM предыдущего поколения, которая уже не годится для своего прямого назначения и не востребована рынком, зато цена за 1гб ниже, например как сейчас DDR3, что расширяет для производителя срок службы технологии и повышает окупаемость мощностей.
— минимизация износа flash памяти, особенно для серверных решений (так как flash бы использовалась только при shutdown и запланированных синхронизациях)
— рост производительности IO на порядок — DDR3/4 все таки быстрее Flash SSD, для баз данных это бы означало, что производительность недалеко от in-memory баз, но при этом энергонезависимая.
— можно применять flash более дешевую, с меньшим количеством циклов записи
На полноразмерной PCI плате можно натулить немало так чипов RAM даже DDR3 и выйдет весьма существенные объемы в единицы TБ.
Не так давно ловил себя на мысли, что нынче наколхозить летающий торрентр трекер с хранилищем в десяток террабайт и весом в 0.5-1кг вместе с аккумуляторами не составляет особого труда, когда 1ТБ уже на одной микроСД карте и было бы прикольно, забавы ради, замутить такое, отправив его в свободное воздушное путешествие по континентам))
Но вот лайвкоддинг в маленькой формочке на каком то сайте вообще застал врасплох, я там даже не мог нормально воспринять шрифт, цветовую схему и банально скобки расставить, буквально ослеп ибо не было еще и подсветки блоков/сигнатур.
Начал писать код, просто чтобы начать что то писать, до конца не поняв ТЗ по реализации API, ибо я ожидал от них спецификацию по интерфейсам, а они примеры вызовов налепили.
Короче, я как в универе- лучше начать что то делать, чтобы не совсем зафейлить). Очень долго рожал, как потом уже понял, посредственную фигню. Тупка жесткая, сам себе удивился… Просто дно, еще и при этом, в качестве хобби, коллаборатор/около ментейнер пакетов, один с которых с 17лямами загрузок в месяц и 1,5к зависимых модулей :)
Да, но с точки зрения клиентов им есть ли разница в каком потоке на сервере был обработан их запрос? Им интересна только задержка ответа. Если речь о делегировании работы другому потоку (основной получил, передал данные воркеру ожидает ответа, попутно обрабатывая другие запросы в евентлупе) то это ничем не отличается от того, если бы запрос пришел другому инстансу через балансир, только еще одно лишнее звено (балансир->инстанс1->воркер1). Если речь что один запрос можно параллельно обработать- половину задачи одним потоком обработать, пока второй решает вторую половину, то тут уже вылазит проблемы синхронизации потоков и зависимостей данных, т.е задачи могут плохо распараллеливается если следующие вычисления базируются на предыдущих. Но к этому надо добавить оверхед на передачу и получения данных воркерам. А ведь даже тяжелые запросы это всего миллисекунды. Суть ведь равномерно загрузить ядра/цп, чтобы потоки не гуляли, при этом обеспечить допустимую задержку отклика для каждого запроса. Какие то феншуи делать для размазывания по воркерам запросы в миллисекунды как бы бессмысленно для большинства задач в вебе.
В чем разница? 10 инстансов и 1 инстанса + 9(10) воркеров? Воркеры тоже не бесконечны- не на каждый ведь запрос можно выделить свой воркер, так что будем иметь тоже самое узкое горлышко, только в другом потоке. Дробить задачи так чтобы каждый чанк не исполнялся более пары мс не забьет очередь, чтобы существенно отразилось на производительности. Трансфер данных воркерам тоже не бесплатно, и вероятно дороже.
Даже как то удивительно, что ее так мало юзают другие, я в чужих реальных проектах этого не видел, а ведь банальный подход.