Это та история, которая лишний раз доказывает что бэкапы не надо делать. Вот у них случилась именно та история которой пугают всех начинающих ИТ-шников. Потеряли все – и данные и бэкапы.
И что? А ничего плохого не случилось. Все восстановилось. А что не восстановилось, оно никому и не нужно. Клиентов не потеряли. Информацию восстановили.
Так выходит, что бэкапы нужны только для сбережения нервов. А можно просто не делать бэкапы и не волноваться. И все будет ОК – лишние усилия не понадобится, а нужная информация не потеряется.
Ну, вам уже подсказали как такое лечится. Как по мне, здесь напрашиваются всякие анимации и визуальные эффекты. Например можно сделать чтобы весь экран становился красным на время записи – моргнуло красным, значит все записалось. Такое никак не пропустить, а время не занимает и работой не мешает.
Мы знали о таком варианте и отбросили его как не пригодный в нашем случае.
А вот чем именно ваш графический редактор так отличается от всех других графических редакторов? Да и текстовых. Повсюду, нажимаешь на "save", файл сохраняется, а иконка становится неактивной. Все сохранилось.
Если бы объяснили, может и не минусовали бы, а плюсовали. Ну или минусовали бы больше, если сочли объяснение неубедительным. ;)
Ну-у-у, чтобы разложить перхлораты, температура понадобится побольше. Не знаю точно, но несколько сотен градусов неверное. Можно построить небольшой заводик для переработки почвы, выделенного кислорода использовать для дыхания а переработанная почва в оранжереях. Нагревать можно и от солнца, параболическими зеркалами.
Кстати, вполне возможно что перхлораты не так уж и распространённые на Марсе. Возможно есть места где в почве перхлоратов и нет.
Что за производства такие, которые производят одно и тоже десятилетиями?
Если станки проектированы и сделаны достаточно гибко, с заделом на будущее, то производство меняется, а станки нет. В этом ничего «такого» нет.
Мы (это не такой уж и секрет) производим холодильники. Модели меняются, а оборудование не так чтобы очень часто. Конечно, новые линии внедряются, производительность поднимаем. (Вот например: https://youtu.be/W1B3NTB2wfQ )
Это никому не удается, но стремиться к этому хорошо.
Почему сразу «не удается» – у меня есть несколько проектов, которые после несколько недель отладки не ломаются уже десятилетиями.
Кстати, это тоже проблема – когда в конце концов такое сооружение повреждается (ничего не вечно под луной), оказывается что никто уже и не помнит как все это работает и как его надо чинить. Исходники неясно где и не компилятся, схемы со временем выцвели и порвались, а файлы открываются только досовской CAD системой, сгоревшие детали давным-давно уже не производят. ;)
Вот и плюс открытого кода. Но кстати, мы вообще станки, производственные линии да и просто софт без исходников не берём. И производители делятся. Да, это не то что открытый код, но когда счёт идёт на миллионы, исходниками делятся. А бывало, меняли всю электронику и писали свой софт. Просто софт, когда нужен, как правило пишем сами. Всякое бывало. Но в результате, аксиома всегда та же самая – Ломаться ничего нельзя. А то придётся поддержке работать, а нам не хочется, мы ленивые.
Никакого хлора выделятся не будет. Просто окислится вся органика в почве, а перхлораты превратятся в хлориды. Конечно прямо сажать не надо, для растении ничего хорошего не будет. Но перхлораты очень химически активные, так что нейтрализуются просто. Кстати, при нагреве перхлораты разлагаются с выделением кислорода. Так что надеюсь на Марсе их будет много, много. :)
Я сам работаю в поддержке. 20 лет уже. Правда, не ИТ а поддержка автоматизации производства. Так у меня несколько аксиомы и первая из них – "Поддержка должна не работать. Потому что когда поддержка работает, производство стоит."
Мы никогда тикеты не использовали – это очень медленно и не оперативно. Но пытаемся так организовать работу, чтобы нас не звали никогда. Если машина ломается часто, совершенствуем пока она перестанет ломаться. Если софт – дебажим и фиксим. Если кабели рвутся, меняем на такие которые не рвутся.
Так что, если мышки у вас ломаются, то сделайте так, чтобы не ломались. Если софт глючит, исправьте чтобы не глючил. Если компьютер тормозит, никакие пруфы не надо – это пользователь работает быстрее компа. Сделайте чтобы у него компьютер работал быстрее человека. Это возможно в 2022ом? Или нет?
Сейчас активно используются и прекрасно работают компьютеры сделанные в 2012-ом году. (Примерно Sandy/Ivy Bridge) Да, немножко подтормаживают, но вполне даже ничего.
Да я сам и пишу вот с компьютера на Intel N3540 — выпуск 2014-ого года.
А теперь посмотрим как было раньше – в 2002-ом году выпускался процессор Pentium III. А если кому-то пришлось в голову использовать процессор десятилетней давности, то пришлось бы ему использовать Pentium I (50MHz!) — что уже было совершенно невозможно в плане производительности.
А я вот, на Pentium III (1000..1400MHz) даже и сейчас запустил бы кое-что и работало бы более менее хорошо.
То есть, выходит, что уже 20 лет, производительность компьютеров увеличивается как О(n), ну пусть будет О(n^2), но далеко не О(2^n) как было раньше.
Пока хватает. Да и то как вы написали «за глаза», выглядит что чуть-чуть хватает.
Но ведь здесь есть только два варианта
– VSCode продолжат развивать и он станет медленнее. А компьютеры увы быстрее не будут. И производительность VSCode вам уже хватать не будет, а будет раздражать. Поэтому придется оптимизировать старый код, чтобы можно было впихнуть новые функции не уменьшая быстродействие. В конечном итоге, придется отказываться от электрона. А если это невозможно, просто забросят проект и сделают все сначала на другой платформе.
– VSCode не будут развивать дальше. Но такие программы всегда прекращают использовать, какими бы они хорошими не были.
Это та история, которая лишний раз доказывает что бэкапы не надо делать. Вот у них случилась именно та история которой пугают всех начинающих ИТ-шников. Потеряли все – и данные и бэкапы.
И что? А ничего плохого не случилось. Все восстановилось. А что не восстановилось, оно никому и не нужно. Клиентов не потеряли. Информацию восстановили.
Так выходит, что бэкапы нужны только для сбережения нервов. А можно просто не делать бэкапы и не волноваться. И все будет ОК – лишние усилия не понадобится, а нужная информация не потеряется.
Ну, вам уже подсказали как такое лечится. Как по мне, здесь напрашиваются всякие анимации и визуальные эффекты. Например можно сделать чтобы весь экран становился красным на время записи – моргнуло красным, значит все записалось. Такое никак не пропустить, а время не занимает и работой не мешает.
То есть бутона "Save" для нажимания мышкой тоже нет?
А вот чем именно ваш графический редактор так отличается от всех других графических редакторов? Да и текстовых. Повсюду, нажимаешь на "save", файл сохраняется, а иконка становится неактивной. Все сохранилось.
Если бы объяснили, может и не минусовали бы, а плюсовали. Ну или минусовали бы больше, если сочли объяснение неубедительным. ;)
Ничего не мешает улавливать воду вместе с кислородом и накачивать ее куда захочется.
Да и использовать солнечную энергию на марсе, это признак нищеты, а не экологичности. Нужно ставить АЭС и не париться больше насчет энергии.
Вы пишете, как будто это что-то плохое.
Счас исправим, пойду сломаю чё-нибудь. ?︎?︎
Ну-у-у, чтобы разложить перхлораты, температура понадобится побольше. Не знаю точно, но несколько сотен градусов неверное. Можно построить небольшой заводик для переработки почвы, выделенного кислорода использовать для дыхания а переработанная почва в оранжереях. Нагревать можно и от солнца, параболическими зеркалами.
Кстати, вполне возможно что перхлораты не так уж и распространённые на Марсе. Возможно есть места где в почве перхлоратов и нет.
Посмотрю я на того, кто мне запретит делать свою работу. Сотрудник озвучивающий такое или врёт, или сам тряпка и уважение не заслуживает ни на грош.
Если станки проектированы и сделаны достаточно гибко, с заделом на будущее, то производство меняется, а станки нет. В этом ничего «такого» нет.
Мы (это не такой уж и секрет) производим холодильники. Модели меняются, а оборудование не так чтобы очень часто. Конечно, новые линии внедряются, производительность поднимаем. (Вот например: https://youtu.be/W1B3NTB2wfQ )
Почему сразу «не удается» – у меня есть несколько проектов, которые после несколько недель отладки не ломаются уже десятилетиями.
Кстати, это тоже проблема – когда в конце концов такое сооружение повреждается (ничего не вечно под луной), оказывается что никто уже и не помнит как все это работает и как его надо чинить. Исходники неясно где и не компилятся, схемы со временем выцвели и порвались, а файлы открываются только досовской CAD системой, сгоревшие детали давным-давно уже не производят. ;)
Вот и плюс открытого кода. Но кстати, мы вообще станки, производственные линии да и просто софт без исходников не берём. И производители делятся. Да, это не то что открытый код, но когда счёт идёт на миллионы, исходниками делятся. А бывало, меняли всю электронику и писали свой софт. Просто софт, когда нужен, как правило пишем сами. Всякое бывало. Но в результате, аксиома всегда та же самая – Ломаться ничего нельзя. А то придётся поддержке работать, а нам не хочется, мы ленивые.
Глючный софт был. А альтернативы и решения все равно находятся.
Никакого хлора выделятся не будет. Просто окислится вся органика в почве, а перхлораты превратятся в хлориды. Конечно прямо сажать не надо, для растении ничего хорошего не будет. Но перхлораты очень химически активные, так что нейтрализуются просто. Кстати, при нагреве перхлораты разлагаются с выделением кислорода. Так что надеюсь на Марсе их будет много, много. :)
Я сам работаю в поддержке. 20 лет уже. Правда, не ИТ а поддержка автоматизации производства. Так у меня несколько аксиомы и первая из них – "Поддержка должна не работать. Потому что когда поддержка работает, производство стоит."
Мы никогда тикеты не использовали – это очень медленно и не оперативно. Но пытаемся так организовать работу, чтобы нас не звали никогда. Если машина ломается часто, совершенствуем пока она перестанет ломаться. Если софт – дебажим и фиксим. Если кабели рвутся, меняем на такие которые не рвутся.
Так что, если мышки у вас ломаются, то сделайте так, чтобы не ломались. Если софт глючит, исправьте чтобы не глючил. Если компьютер тормозит, никакие пруфы не надо – это пользователь работает быстрее компа. Сделайте чтобы у него компьютер работал быстрее человека. Это возможно в 2022ом? Или нет?
Только загвоздка в том, что далеко не все задачи можно распараллелить. Вот вам: Закон Амдала
Так что, удваивание процессоров не дает удвоенная производительность. Увы.
Такие «прорывы» в девяностых и начале нулевых случались каждые полтора года. А сейчас вы это воспринимаете как прорыв. Об этом я и говорю.
Отнюдь!
Дам только один пример:
Сейчас активно используются и прекрасно работают компьютеры сделанные в 2012-ом году. (Примерно Sandy/Ivy Bridge) Да, немножко подтормаживают, но вполне даже ничего.
Да я сам и пишу вот с компьютера на Intel N3540 — выпуск 2014-ого года.
А теперь посмотрим как было раньше – в 2002-ом году выпускался процессор Pentium III. А если кому-то пришлось в голову использовать процессор десятилетней давности, то пришлось бы ему использовать Pentium I (50MHz!) — что уже было совершенно невозможно в плане производительности.
А я вот, на Pentium III (1000..1400MHz) даже и сейчас запустил бы кое-что и работало бы более менее хорошо.
То есть, выходит, что уже 20 лет, производительность компьютеров увеличивается как О(n), ну пусть будет О(n^2), но далеко не О(2^n) как было раньше.
Пока хватает. Да и то как вы написали «за глаза», выглядит что чуть-чуть хватает.
Но ведь здесь есть только два варианта
– VSCode продолжат развивать и он станет медленнее. А компьютеры увы быстрее не будут. И производительность VSCode вам уже хватать не будет, а будет раздражать. Поэтому придется оптимизировать старый код, чтобы можно было впихнуть новые функции не уменьшая быстродействие. В конечном итоге, придется отказываться от электрона. А если это невозможно, просто забросят проект и сделают все сначала на другой платформе.
– VSCode не будут развивать дальше. Но такие программы всегда прекращают использовать, какими бы они хорошими не были.