ну так они делают имитацию дорогой черепицы, выглядящую практически так же (если не рассматривать вблизи — толщина будет меньше скорее всего), по той же цене, с близкой долговечностью, но к тому же вырабатывающую электричество.
в принципе — интересный подход. думаю, взлетит.
Первый язык программирования должен быть максимально простым и понятным, без необходимости почесать пяткой за ухом для тривиальных задач (как в случае имитации ООП на JS), + должен ограничивать разработчика в возможностях выстрелить себе в ногу. И при этом — желательно, еще живым и применяемым (паскаль тут отпадает), и по возможности более лаконичный (чтобы меньше отвлекаться на синтаксис языка).
ИМХО на роль первого языка прекрасно подходит питон или раби — ввиду своей простоты, понятности и лаконичности. Заодно — приучает пользоваться отступами, структурировать код.
ну в вашем примере сотруднику ничего не мешает просто сделать рабоу на тяп-ляп, и сидеть на объекте смотреть киношки со смарта/планшета. при этом — якобы «работу работая». возможно — оставив где-то гудеть пылесос, для видимости активной уборки. и контроль местонахождения сотрудника это не изменит. тут только выборочный контроль результата работы поможет.
и да, если сотрудник приедет на офис на час раньше расчетного времени — что ему за это хорошего будет? если ничего — он и не будет пытаться приехать пораньше.
значит — неверно выбраны нормативы времени, если работники в большинстве случаев заканчивают работу намного быстрее. либо — недостаточный стимул у работников заканчивать работу быстрее норматива. смотря что работников лучше стимулирует — кнут или пряник.
и да, сотруднику ничего не мешает к примеру на объекте/около объекта в салоне авто просто сидеть смотреть видео на телефоне, если он решил что не стоит перенапрягаться т.к. норматив по закрытым заявкам выполнен/заявку смог закрыть раньше времени.
думаю — скорее затык в самом VLIW ядре, вернее — в софте который проект конвертит в фотошаблоны (либо в умении его настроить). VLIW ядро довольно широкое, много исполнительных блоков которые должны работать синхронно, без глитчей — а не факт что софт, ренерящий проект из VHDL, будет согласовывать длины соединительных проводников кристала (и вообще имеет представление о том что это нужно).
если сдельная оплата — то в принципе ничего плохого. если есть нормы времени и штрафы за их нарушение/премии за досрочное выполнение — тоже в принципе ничего плохого если работник в отведенное время укладывается, но — «недополученная прибыль» (работник мог бы выполнить еще какую-то задачу).
насчет avr/stm32 — вы в корне не правы, на avr на асме программирование одинаковых фич занимает на порядок больше времени (и требует намного больше опыта — либо привет жизнь сутками в дебаггере), чем конфигурирование проекта на stm32 кубиком и дописывание логики.
то же самое и с конструированием ЭВМ с нуля на рассыпухе/логике низкой степени интеграции, и использовании современных инструментов разработки под ПЛИС с готовыми же библиотеками…
к слову, да. к примеру, приговоренные к смертной казни — вполне им можно было бы предоставить такую альтернативу (участие в эксперименте + пожизненное ограничение свободы после, если выжил, + право на эвтаназию ессно). и, уверен, многие бы и согласились. и с т.з. морали, и с т.з. ценности результатов — одни преимущества.
каким образом ящик резервных железок позволит бороться с багами в софте/особенностями используемых сохо компонентов (свиччипы, эзернет чипы и т.п.)? вы вообще с энтерпрайзом и их требованиями сталкивались? там, где час простоя обходится суммой с 3-4 и более нулями, ессно мертвых президентов?
а багов таки имеется. к примеру, вис микротика наглухо при частых ssh коннектах (порядка нескольких коннектов в секунду) — эту багу фиксили более 3 лет (!). или из относительно свеженького (вроде еще непофиксенного) — вис при переполнении коннтрака… и по железу там часто все печально — тот же встроенный свич в rb2011 к примеру при наличии в л2 сегменте более 50-70 маков превращается в хаб из-за колизий хешей (спасибо дешевому AR8337), начинает рассылать трафик во все свои порты, и бороться можно только свичуя (бриджуя) все на и так чахлом проце; на тех же CCR с гигабитными портами распаяны сетевые адаптеры atheros которые на 500-600 мбитах реального трафика с мелкими пакетами начинают превращаться в тыкву, и т.п.
ну и да, микротики по цене не дешевле б/у циски/джунипера сравнительной производительности.
микротик ни разу не для энтерпрайза. обычная сохо поделка, пускай и перекачанная стероидами. ибо подход к софтописательству — типичный сохо: мы тут вам наговнякали 100500 плюшек, и они вроде как должны работать, но плюшка А вешает систему когда включена плюшка В, плюшка С работает не по стандарту т.к. индус, ее писавший, стандарт не понял (либо вообще не читал), а в плюшке D есть critical bug, допускающий remote DoS атаку — но править мы его вот прямо сейчас не будем, потому что за багфиксы деньги не платят, может, если вам повезет, лет через 5 пофиксим, а пока — пользуйтесь тем что есть. и да, никакого сервис-контракта, по которому отказавшую железку заменят в течение суток-двух, а всплывший баг исправят за адекватные сроки, тоже нет, в принципе. а сервис-контракт — основное требование энтерпрайза.
ИМХО микротик — скорее для тех, кто не осилил *nix и не любит думать — т.к. есть 100500 гайдов, как сконфигурить что-то, с расписанным порядком куда ткнуть мышкой для получения результата.
а с RR — пообщаться получится только если напихать микротику маршруты к аплинкам статикой через RR. возможно — еще получится если маршруты будут получаться не статикой а через ospf/rip, но не пробовал.
на 20-30 км/ч — может и получится прыгнуть. но не на 70 км/ч на максимальной передаче с околонулевым запасом мощности двигателя ;) а этот комплект где-то эквивалентен 50 кубикам по мощности, а то и меньше…
бгп на микротике убого и ущербно от рождения. мало того что разрабы не отличают rib от fib и все пихают в kernel routing table, так оно еще и эпически тормозное + никак не параллелится. и итоге при флапе 2 пиров с full view 72-ядерная поделка за 3000 мертвых президентов обновляет маршруты в течение 20-30 минут. а в обычном состоянии одно из ядрышек постоянно нагружено на 100% бгп процессом — потому что в интернете где-то периодически что-то отпадает/подключается, а при скорости изучения порядка пары десятков маршрутов в секунду работа ядрышку есть всегда.
ну и прочие «мелочи», как к примеру отсутствие нормальной поддержки приема анонсов от route reflector, с next nop не из connected/static (пример: узел 1.1.1.1 анонсит дефолт через 2.2.2.2 и 2.2.2.0/24 через 1.1.1.1 — микротик это не поймет и сделает default unreachable).
а в чем здесь смысл использования л2 туннелей? какой от них профит? чисто чтобы оспф мультикаст мог слать? так это делается куда проще — ptp, и никакого мультикаста. и никаких туннелей к слову не нужно. и нет завязки на проприетарную технологию, которая ни с чем больше не совместима.
к слову, с оспф у микротика все очень печально по части реализации — вплоть до закольцовывания маршрутов, поймете как только появится более одной area…
на ровной дороге? да когда яма внезапно «выныривает» в 15 метрах впереди (такое бывает если впереди небольшой подъем, или если трасса в солнечный день с тенями от деревьев — в них ямы фиг разглядишь, и времени на реакцию практически не остается)? на реальных дорогах трамплины перед ямами не встречаются, все чаще — просто выбоины…
а вот для покатушек по пересеченной местности — таки да, электровел довольно веселый будет.
а есть еще пример MIPS и Lexra, которая не включила несколько MIPS инструкций в свое ядро именно по причине действующих патентных ограничений. из-за чего ядро фактически зафейлилось…
с горки — да. а вот по ровному без уклона — больше 30 км/ч человек не выжмет длительно (скажем, более 5 минут). а вот за каким-то авто в воздушном потоке — легко 40-50 можно, не прикладывая особо усилий (покрутил секунд 20 педали — и минуту катишься накатом, пока не начал отставать на пару метров). так что основной момент тут — сопротивление воздуха.
и да, на велосипеде если влететь в хорошую ямку (сантиметров 10-15 глубиной — я такие ловил) на 70 км/ч, да еще если вел без заднего амортизатора — обод навряд выдержит. тут мото диски (толщиной миллиметра 2-3) от такого на ура гнутся…
результат преобразования — благодаря SRAM с низкой латентностью, работающей на частоте ядра. которая, к слову, значительно упростила разработку чипа, хоть и увеличила транзисторный бюджет (сваять нормальный ИКП асинхронной DRAM — не так-то просто).
Видел в свое время авиационные коллекторные движки, где ротор был в виде залитых в эпоксидку обмоток, статор — магнит + магнитопровод. Такой мотор не имел потерь на перемагниивание вообще (нечему перемагничиваться), при довольно солидной мощности (не ниже чем классичские, с металлическим ротором тех же габаритов). Интересно, есть ли BLDC подобной конструкции?
в принципе — интересный подход. думаю, взлетит.
ИМХО на роль первого языка прекрасно подходит питон или раби — ввиду своей простоты, понятности и лаконичности. Заодно — приучает пользоваться отступами, структурировать код.
и да, если сотрудник приедет на офис на час раньше расчетного времени — что ему за это хорошего будет? если ничего — он и не будет пытаться приехать пораньше.
и да, сотруднику ничего не мешает к примеру на объекте/около объекта в салоне авто просто сидеть смотреть видео на телефоне, если он решил что не стоит перенапрягаться т.к. норматив по закрытым заявкам выполнен/заявку смог закрыть раньше времени.
то же самое и с конструированием ЭВМ с нуля на рассыпухе/логике низкой степени интеграции, и использовании современных инструментов разработки под ПЛИС с готовыми же библиотеками…
а багов таки имеется. к примеру, вис микротика наглухо при частых ssh коннектах (порядка нескольких коннектов в секунду) — эту багу фиксили более 3 лет (!). или из относительно свеженького (вроде еще непофиксенного) — вис при переполнении коннтрака… и по железу там часто все печально — тот же встроенный свич в rb2011 к примеру при наличии в л2 сегменте более 50-70 маков превращается в хаб из-за колизий хешей (спасибо дешевому AR8337), начинает рассылать трафик во все свои порты, и бороться можно только свичуя (бриджуя) все на и так чахлом проце; на тех же CCR с гигабитными портами распаяны сетевые адаптеры atheros которые на 500-600 мбитах реального трафика с мелкими пакетами начинают превращаться в тыкву, и т.п.
ну и да, микротики по цене не дешевле б/у циски/джунипера сравнительной производительности.
ИМХО микротик — скорее для тех, кто не осилил *nix и не любит думать — т.к. есть 100500 гайдов, как сконфигурить что-то, с расписанным порядком куда ткнуть мышкой для получения результата.
а с RR — пообщаться получится только если напихать микротику маршруты к аплинкам статикой через RR. возможно — еще получится если маршруты будут получаться не статикой а через ospf/rip, но не пробовал.
ну и прочие «мелочи», как к примеру отсутствие нормальной поддержки приема анонсов от route reflector, с next nop не из connected/static (пример: узел 1.1.1.1 анонсит дефолт через 2.2.2.2 и 2.2.2.0/24 через 1.1.1.1 — микротик это не поймет и сделает default unreachable).
а для быстрой сходимости есть bfd…
A1 - A2
| .. |
A3 - A4
где A1..A4 — разные area
где-то было описание этого случая на наге, но что-то с ходу найти не могу.
к слову, с оспф у микротика все очень печально по части реализации — вплоть до закольцовывания маршрутов, поймете как только появится более одной area…
а вот для покатушек по пересеченной местности — таки да, электровел довольно веселый будет.
и да, на велосипеде если влететь в хорошую ямку (сантиметров 10-15 глубиной — я такие ловил) на 70 км/ч, да еще если вел без заднего амортизатора — обод навряд выдержит. тут мото диски (толщиной миллиметра 2-3) от такого на ура гнутся…