Случились уже, наверное, сотни катастроф, которые летчики могли бы предотвратить если бы вспомнили, следовали, использовали... Я не летчик, но все обзоры катастроф приводят меня к выводу, что работа летчика - сложная и стрессовая. А в условиях стресса - увы, человек не робот чтобы безошибочно распознавать ситуацию и действовать по чеклисту. Неожиданное поведение самолета создало стресс с которым летчики не справились. Это не делает чести экипажу, но и не снимает вины с производителя, который допустил грубую ошибку (в первую очередь не став перепроектировать фюзеляж из-за увеличенных габаритов новых двигателей, то есть погнался за прибылью)
Они были первыми, поэтому они не знали как нужно делать и как нельзя делать. В отличие от разработчиков "Титана", к услугам которых был весь накопленный опыт глубоководных погружений.
А можно чуть подробнее про "теоретическая теория вероятности не подтверждается фактическими наблюдениями"? Про игру Пенни я писал выше - они никоим образом не является опровержением теории вероятностей. Наоборот - шансы победы в этой игре прекрасно рассчитываются при помощи теории вероятностей.
Во-первых, Котлин умеет компиляцию (транспиляцию) в JavaScript
Во-вторых, Котлин умеет компиляцию даже в native
В-третьих, у Андроида, насколько я знаю, своя VM, несовместимая с JVM
И в четвертых, а почему JVM под капотом означает что мы кого-то обманываем? Кроме Java на JVM работают многие другие языки - Scala, Groovy, JRuby и т.д. Точно также как на платформе .net существует не только C#, но и другие языки.
Преимущества и недостатки предполагают какое-то сравнение: "здесь сделано так, поэтому в сравнении с X это преимущество, а вот здесь так, поэтому в сравнении с Y это недостаток"
Вы же, по большому счету, просто перепечатали фрагмент документации языка.
Игра Пенни притянута за уши, ни о какой зависимости случайных событий в этом случае говорить не приходится. Потому что игроки наблюдают одну последовательность случайных чисел, а не две (каждый свою).
Посмотрим на простой пример: игрок А выбирает последовательность 111, игрок Б (зная выбор игрока А) выбирает наилучшую для себя последовательность 011. Если в послевательности сразу же выпадут три единицы - игрок А выигрывает. Но если выпадет хоть один 0 - выигрывает игрок Б. Потому что любой 0 начинает его последовательность. И если за ним последуют две единицы - он выиграл. А если за ним последует 0 или 10 - то его последовательность просто сдвинется на одну дальше.
Все что утверждает игра Пенни - для любой комбинации игрока А существует контркомбинация игрока Б, работающая по описанному выше принципу - она опережает комбинацию игрока А, встречаясь раньше с вероятностью более 1/2. И никаким нарушением случайности здесь и не пахнет.
Вы неправы. Во-первых, уже есть немало игр, которые native для линукса. Из того во что я играю - Factorio и Kerbal Space Program. Unity умеет в линукс. Unreal Engine умеет в линукс. Поэтому не соглашусь, игры для линукса постепенно появляются и их становится больше. Ну и wine / proton этому способствуют.
Консоль. Очень много вещей можно сделать в консоли. В частности такие утилиты как grep, sed, awk при грамотном использовании творят чудеса. Да, в винде они тоже есть (MinGW/Cygwin/WSL), но в линукс они органично вплетены в систему.
Docker. Не знаю как сейчас, в Win7 он ставился как-то нетривиально (и вроде работал через виртуалку). В линуксе - "искаропки".
Оконный менеджер. Под любые запросы. Я предпочитаю тайловый i3wm - виндовс мне может что-нибудь подобное предложить?
Ну и, наконец, настраиваемость всего что только можно.
Ну и последнее - это уже специфика моей работы. Я разрабатываю бэкэнд, который потом будет развернут в кубернете. Использование линукса снижает шансы того, что поведение сервиса будет отличаться (при использовании Win у меня была прекрасная ситуация, что у меня все работало, а на сервере упало - винда не различает регистр в имени файла, а линукс различает)
Первый момент - вопрос вероятностей. Какой шанс взлома ключа за фиксированное время мы готовы допустить? Положим, что при определенных затратах, полным перебором ключ взламывается за 1000 лет. Сделаем допущение, что алгоритм перебирает варианты линейно. Тогда шанс взлома ключа за год равен 1/1000 = 0,1%. Насколько это приемлемый риск - зависит от того что именно защищено этим ключом.
Второй момент - алогоритм может не перебирать все значения, а приходить к решению за определенное число шагов (насколько я понимаю, алгоритмы факторизации работают именно так). И тогда рассуждения выше не имеют силы - пока мы не завершим работу алгоритма (на что требуется 1000 лет) - конечного результата мы не получим.
Будет. Допустим часов за 16 до события. А дальше начинается интересный вопрос: кто возьмет на себя ответственность за блэкаут? А если другие страны не отключат и не пострадают? А чего будет стоить запустить все отключенное обратно? И на каждом уровне прохождения информации будут согласования, одобрения, решения... Это только в кино о таком сразу докладывают президенту.
В роли сборщика мусора - компилятор. Это я по джавовской привычке так написал. Насколько я понимаю, там тот же принцип работы что и в C++ с его умными указателями: когда объект ссылки уничтожается (например по выходу из области видимости или по любой другой причине), то его деструктор уменьшает значение счетчика ссылок. Если счетчик ссылок уменьшается до нуля - память освобождается. Собственно, "сборщика мусора" как отдельной подсистемы нет, но эффект освобождения памяти без необходимости заботиться об этом со стороны программиста - аналогичен
Можно, вопрос во времени которое для этого потребуется. Если на аэродроме, условно, в обычных условиях 50 самолетов, то внезапно прилетевшие туда 150 (которым просто деваться больше некуда) - это проблема.
Ну как бы в днем в ясную погоду - это одно. А в сложных метеоусловиях, в дождь при видимости 500 на 50? Когда самолет "сам" идет к полосе по приводным маякам и они вдруг пропадают - что экипажу делать? Для примера - катастрофа 747 в Манасе 16 января 2017 года. Ночь, сложные метеоусловия и нормально работающая автоматика, но пилоты не справились. А в отсутствие связи с землей и приводных маяков?
А если ночь? Элементарно погасли огни полосы, ни приводов, ни связи. Даже не факт что получится добраться до другого аэродрома - куда лететь без радиомаяков?
На основании чего отключатся? Новостных передач по телевизору или статей в интернете? Я, конечно, в деталях не знаю как это устроено, но полагаю что штатное отключение электростанции происходит через диспетчерскую энергосистемы.
Разве MCAS используется только на взлете? Насколько я читал - она работает весь полет.
Случились уже, наверное, сотни катастроф, которые летчики могли бы предотвратить если бы вспомнили, следовали, использовали... Я не летчик, но все обзоры катастроф приводят меня к выводу, что работа летчика - сложная и стрессовая. А в условиях стресса - увы, человек не робот чтобы безошибочно распознавать ситуацию и действовать по чеклисту. Неожиданное поведение самолета создало стресс с которым летчики не справились. Это не делает чести экипажу, но и не снимает вины с производителя, который допустил грубую ошибку (в первую очередь не став перепроектировать фюзеляж из-за увеличенных габаритов новых двигателей, то есть погнался за прибылью)
Они были первыми, поэтому они не знали как нужно делать и как нельзя делать. В отличие от разработчиков "Титана", к услугам которых был весь накопленный опыт глубоководных погружений.
А можно чуть подробнее про "теоретическая теория вероятности не подтверждается фактическими наблюдениями"? Про игру Пенни я писал выше - они никоим образом не является опровержением теории вероятностей. Наоборот - шансы победы в этой игре прекрасно рассчитываются при помощи теории вероятностей.
Во-первых, Котлин умеет компиляцию (транспиляцию) в JavaScript
Во-вторых, Котлин умеет компиляцию даже в native
В-третьих, у Андроида, насколько я знаю, своя VM, несовместимая с JVM
И в четвертых, а почему JVM под капотом означает что мы кого-то обманываем? Кроме Java на JVM работают многие другие языки - Scala, Groovy, JRuby и т.д. Точно также как на платформе .net существует не только C#, но и другие языки.
А где, простите, преимущества? Где недостатки?
Преимущества и недостатки предполагают какое-то сравнение: "здесь сделано так, поэтому в сравнении с X это преимущество, а вот здесь так, поэтому в сравнении с Y это недостаток"
Вы же, по большому счету, просто перепечатали фрагмент документации языка.
Игра Пенни притянута за уши, ни о какой зависимости случайных событий в этом случае говорить не приходится. Потому что игроки наблюдают одну последовательность случайных чисел, а не две (каждый свою).
Посмотрим на простой пример: игрок А выбирает последовательность 111, игрок Б (зная выбор игрока А) выбирает наилучшую для себя последовательность 011. Если в послевательности сразу же выпадут три единицы - игрок А выигрывает. Но если выпадет хоть один 0 - выигрывает игрок Б. Потому что любой 0 начинает его последовательность. И если за ним последуют две единицы - он выиграл. А если за ним последует 0 или 10 - то его последовательность просто сдвинется на одну дальше.
Все что утверждает игра Пенни - для любой комбинации игрока А существует контркомбинация игрока Б, работающая по описанному выше принципу - она опережает комбинацию игрока А, встречаясь раньше с вероятностью более 1/2. И никаким нарушением случайности здесь и не пахнет.
Вы неправы. Во-первых, уже есть немало игр, которые native для линукса. Из того во что я играю - Factorio и Kerbal Space Program. Unity умеет в линукс. Unreal Engine умеет в линукс. Поэтому не соглашусь, игры для линукса постепенно появляются и их становится больше. Ну и wine / proton этому способствуют.
Скажу за себя:
Консоль. Очень много вещей можно сделать в консоли. В частности такие утилиты как grep, sed, awk при грамотном использовании творят чудеса. Да, в винде они тоже есть (MinGW/Cygwin/WSL), но в линукс они органично вплетены в систему.
Docker. Не знаю как сейчас, в Win7 он ставился как-то нетривиально (и вроде работал через виртуалку). В линуксе - "искаропки".
Оконный менеджер. Под любые запросы. Я предпочитаю тайловый i3wm - виндовс мне может что-нибудь подобное предложить?
Ну и, наконец, настраиваемость всего что только можно.
Ну и последнее - это уже специфика моей работы. Я разрабатываю бэкэнд, который потом будет развернут в кубернете. Использование линукса снижает шансы того, что поведение сервиса будет отличаться (при использовании Win у меня была прекрасная ситуация, что у меня все работало, а на сервере упало - винда не различает регистр в имени файла, а линукс различает)
Вот именно! Особенно что касается старых игр - линукс однозначно лучше.
В линуксе стим точно также все нужное установит. И Lutris тоже.
Единственное что мне пришлось установить руками и подключить к стиму - Proton-GE (а вот Lutris сам его может установить)
Это чуть более глубокий вопрос.
Первый момент - вопрос вероятностей. Какой шанс взлома ключа за фиксированное время мы готовы допустить? Положим, что при определенных затратах, полным перебором ключ взламывается за 1000 лет. Сделаем допущение, что алгоритм перебирает варианты линейно. Тогда шанс взлома ключа за год равен 1/1000 = 0,1%. Насколько это приемлемый риск - зависит от того что именно защищено этим ключом.
Второй момент - алогоритм может не перебирать все значения, а приходить к решению за определенное число шагов (насколько я понимаю, алгоритмы факторизации работают именно так). И тогда рассуждения выше не имеют силы - пока мы не завершим работу алгоритма (на что требуется 1000 лет) - конечного результата мы не получим.
Это прикол или реально так работало?
Будет. Допустим часов за 16 до события. А дальше начинается интересный вопрос: кто возьмет на себя ответственность за блэкаут? А если другие страны не отключат и не пострадают? А чего будет стоить запустить все отключенное обратно? И на каждом уровне прохождения информации будут согласования, одобрения, решения... Это только в кино о таком сразу докладывают президенту.
Невладеющие ссылки - могут "провиснуть", агрегатные - не могут. В этом и отличие, насколько я его понял.
В роли сборщика мусора - компилятор. Это я по джавовской привычке так написал. Насколько я понимаю, там тот же принцип работы что и в C++ с его умными указателями: когда объект ссылки уничтожается (например по выходу из области видимости или по любой другой причине), то его деструктор уменьшает значение счетчика ссылок. Если счетчик ссылок уменьшается до нуля - память освобождается. Собственно, "сборщика мусора" как отдельной подсистемы нет, но эффект освобождения памяти без необходимости заботиться об этом со стороны программиста - аналогичен
Можно, вопрос во времени которое для этого потребуется. Если на аэродроме, условно, в обычных условиях 50 самолетов, то внезапно прилетевшие туда 150 (которым просто деваться больше некуда) - это проблема.
Ага. А еще - без связи. Одна надежда - что аварийные дизель-генераторы нормально запустятся и проработают достаточное время.
Ну как бы в днем в ясную погоду - это одно. А в сложных метеоусловиях, в дождь при видимости 500 на 50? Когда самолет "сам" идет к полосе по приводным маякам и они вдруг пропадают - что экипажу делать? Для примера - катастрофа 747 в Манасе 16 января 2017 года. Ночь, сложные метеоусловия и нормально работающая автоматика, но пилоты не справились. А в отсутствие связи с землей и приводных маяков?
А если ночь? Элементарно погасли огни полосы, ни приводов, ни связи. Даже не факт что получится добраться до другого аэродрома - куда лететь без радиомаяков?
На основании чего отключатся? Новостных передач по телевизору или статей в интернете? Я, конечно, в деталях не знаю как это устроено, но полагаю что штатное отключение электростанции происходит через диспетчерскую энергосистемы.