Раньше FirstVDS были очень неплохими (у них даже была FreeBSD среди ОС для VM-ок!)
Вот как раз раньше, году в 2008 это был постоянный нервяк — постоянно что-то ломалось и отваливалось. Имя «Святослав Лемперт» я видел на экране чаще, чем имена родных. По нескольку тикетов висело открытыми в один и тот же момент.
Сейчас аптайм и стабильность кратно выше стали.
А что касается FreeBSD — расскажите, как в конце 2016 нода с фришкой грохнулась так, что они две недели её пытались воскресить, а потом объявили, что данные невосстановимы, а потом архивы файловых систем VDS-ок (ту часть, которую удалось восстановить) выложили даже без паролей на FTP — где только (не)знание URL чужого дампа как-то ограждало одних клиентов от доступа к данным других клиентов.
Я после таких событий, например, серьёзно заболел. Совпадение или нет — отдельный вопрос.
После того инцидента они, кстати, в качестве извинения прислали промокод на смешную скидку около 15 процентов. На моей вопрос о том, сколько он действует, сказали, что бессрочно. Я им так и не воспользовался. Готов поспорить, что если применить его сейчас, окажется, что он уже давно не действует, а про тот инцидент никто не помнит.
Что за баллончик? Типа тех, что в советские времена были нужны для сифонов для газводы?
Так там объем мизерный. А пропан, в отличие от углекислого газа, не получится загнать туда под давлением 300 атмосфер, он сжижается раньше, в отличие от цэ-о-два.
Да и вообще, какой смысл что-то изобретать, если есть готовые фабричные пропановые баллоны. Расчитанные, испытанные, разного литража?..
Ну плохо, что вы не понимаете этого простейшего физического принципа, но на самом деле это, я думаю, легко поправимо. Гораздо хуже то, что вы пропагандируете потенциально опасные действия.
Ещё раз, если кратко: заправлять пропан в ёмкость, рассчитанную на изобутан нельзя, потому что при тех же условиях (температуре, главным образом) давление в сосуде будет в разы больше. Наоборот — можно, в ёмкость, расчитанную под пропан, заливайте изобутана сколько хотите.
Но если пропан загонять в тонкостенный изобутановые сосуды, то до запас до исчерпания предела прочности остаётся значительо меньший.
Компрессор нужен по сути для регенерации жидкого хладагента. Если у вас есть запас оного, например в баллоне, можете выпускать его в испаритель, а испарения стравливать в атмосферу.
Вполне себе работающий холодильник/кондиционер будет, пока запас жидкого хладагента не кончится.
Нет, вы делаете популярную ошибку. Холодильник работает благодаря фазовым переходам жидкости. То, что там газ сжимается/расширяется и при этом нагревается/охлаждается это вообще незначительный побочный эффект, который есть, но погоду особо не делает.
Я правильно понимаю, что основной посыл автора в том, что неведомо что предлагается называть не тёмной материей, а космическим эфиром, а кроме как другого названия для абсолютно непонятого пока явления предложить нечего?
Ошибаетесь. Разрабатывал, хоть и не так много, как под Windows.
Ну опишите открытым текстом, что вашим приложениям мешает жить на линукс-машины без завёртывания в контейнер?
И, каким бы ни был ответ, почему вместо допиливнаия линукса (что было бы идеологически верным) лепят нашлёпку поверх недопиленного линукса и ещё и радуются этому?
И как тогда по вашему существовал мир до создания докера? Как кромешный ад и ужас? Это мне напоминает «ощущение» у неофитов, что 100 лет назад мир в принципе был чёрно-белым.
Непонятно только, почему этим так называемым разработчикам приложений так «зашла» идея заворачивать приложения в изолированных ящиках.
Может потому, что они настолько криворукие разработчики, что не могут написать приложения, которые бы не мешали работе друг-друга?
В 2000-х была популярна шутка про начинающих разработчиков, которые пишут приложения, которые нигде больше не запускаются, кроме как на компе своего создателя. Такое ощущение, что весь тот докер про это.
Если же всё дело в изоляции, то чем системные механизмы изоляции не устраивают? И если все-таки не устраивают, с какого перепугу проблему изоляции прикладных программ решает другая прикладная программа, а не решается это на уровне ОС?
В каком виде вам нужен пруф, чтобы он считался пруфом? Если мой комментарий о том, что вещи устроены так, это не пруф, то будет ли моя статья об этом же самом считаться пруфом?
Я единолично разреверсил VB/VBA (по крайней мере эту его часть), задокументировал все типы узлов синтаксического дерева, организцию структур, типы сущностей RPN-подобного представления кода (дерево вскоре после своего построения конвертируется в линейную RPN-like цепочку из 16-битных сущностей и именно эти линейные структуры долговременно хранятся в памяти IDE, именно они представляют код и именно из них регенерируется текстовое представление кода, когда его нужно отрисовать на экране, скопировать в буфер обмена или сохранить в файл.
Вот вам пруф, к достоверности которого вы явно не прикопаетесь:
Откройте VB/VBA и в IDE напишите какой-нибудь код, например такой:
If Minute(Now) Mod 2 = 0 Then MsgBox "Hello World!" Else MsgBox "Goodbye!"
Теперь присоединитесь к процессу IDE отладчиком и попробуйте в памяти процесса найти эту строчку. Вы её там не найдёте. Ни в виде ANSI-строки, ни в виде UCS2-строки, ни в виде UTF8-строки. Ни в каком виде.
Точнее, есть шанс, что вы её случайно найдёте в памяти, но это просто просто мусор — незанулённый и никем более не используемый регион памяти. Можете затереть в таком случае всю найденную строку буквами «Ы», вернуться в IDE и строка с If-ом как была, так и останется.
А, ну окей, скажете вы, наверное IF как структура как-то хитро представляется, но вот условие IF-а, then-clause или else-clause должны храниться как строка.
Нет, тоже мимо.
Подстроку «Minute(Now) Mod 2 = 0», подстроку «MsgBox "Hello World!"» и подстроку «MsgBox "Goodbye!"» вы тоже не найдёте. Их не будет в памяти. А если вдруг и будет, то это мусор, перезатирение которого чем-либо иным ни на что не влияет.
Гораздо больше подробностей о том, как это устроено под капотом, можно прочитать в этом комменте
Конечно, дизайн языка должен соответствовать такой концепции. Но не нужно писать «этого не может быть, потому что этого не может быть никогда», в то время как подобное десятилетиями работало (и продолжает работать, или в современных Офисах выпилили VBA? — простите, я не слежу). Такие высказывания говорят скорее о малом кругозоре. В мире чего только не бывает.
А что значит само по себе выражение «передача метода в язык автоматическим управлением»?
В COM у метода могут быть аттрибуты (hidden, restricted), из из языка типа VB вы этот метод не увидите или не вызовите.
А вот что есть в спецификации COM, так это запрет на то, чтобы вызывать AddRef у одного интерфейса, а комплиментарный ему Release у другого. То есть, хотя 90% имплементаций имеют один счётчик ссылок «на объект», согласно спецификации у каждого интерфейса объекта (а интерфейсов у объекта может быть много) должен быть свой счётчик ссылок, и каждый интерфейс может порождаться/уничтожаться независимо от других.
Соответственно, вызывая AddRef или Release вы не управляете временем жизни объекта, вы управляете временем жизни конкретного интерфейса. Другое дело, что имплементация в 90% (а то и больше) случаев в угоду упрощения скатывается до единой для всех реализации AddRef/Release и единому счётчику ссылок. Более того, если реализовывать COM-объект на C++ как C++-класс, то по другому и не получится сделать, не прибегая к извратам.
Боюсь, я несколько подзабыл такие материи, как интеграция с Visual Basic (для этого же нужны диспинтерфейсы?), поэтому поправьте, если что-то не так.
Нет, не для этого. Visual Basic прекрасно может работать с объектами, не поддерживающими IDispatch. И с другой стороны, хотя любой экземпляр класса, написанного на VB, будет поддерживать IDispatch, вы прекрасно можете работать с такими объектами из других языков, не поддерживающими IDispatch.
Так что нет, IDispatch нужен не для интеграции с VB, он нужен для позднего связывания. А вот для VBScript он конечно же нужен, потому что там априори всё связывание — позднее, в момент интерпретации скрипта.
Имеется, видимо, в виду перетопление в том смысле, в каком топят печь.
Длинна и колличество это детские шалости.
Вот эбоксидка, инвектор, подшибник, саленблок, в крации и спасибо за ранние — вот это уже уровень.
Вот как раз раньше, году в 2008 это был постоянный нервяк — постоянно что-то ломалось и отваливалось. Имя «Святослав Лемперт» я видел на экране чаще, чем имена родных. По нескольку тикетов висело открытыми в один и тот же момент.
Сейчас аптайм и стабильность кратно выше стали.
А что касается FreeBSD — расскажите, как в конце 2016 нода с фришкой грохнулась так, что они две недели её пытались воскресить, а потом объявили, что данные невосстановимы, а потом архивы файловых систем VDS-ок (ту часть, которую удалось восстановить) выложили даже без паролей на FTP — где только (не)знание URL чужого дампа как-то ограждало одних клиентов от доступа к данным других клиентов.
Я после таких событий, например, серьёзно заболел. Совпадение или нет — отдельный вопрос.
После того инцидента они, кстати, в качестве извинения прислали промокод на смешную скидку около 15 процентов. На моей вопрос о том, сколько он действует, сказали, что бессрочно. Я им так и не воспользовался. Готов поспорить, что если применить его сейчас, окажется, что он уже давно не действует, а про тот инцидент никто не помнит.
Что за баллончик? Типа тех, что в советские времена были нужны для сифонов для газводы?
Так там объем мизерный. А пропан, в отличие от углекислого газа, не получится загнать туда под давлением 300 атмосфер, он сжижается раньше, в отличие от цэ-о-два.
Да и вообще, какой смысл что-то изобретать, если есть готовые фабричные пропановые баллоны. Расчитанные, испытанные, разного литража?..
Как можно было не указать дискретность, цену деления датчика?
Ну плохо, что вы не понимаете этого простейшего физического принципа, но на самом деле это, я думаю, легко поправимо. Гораздо хуже то, что вы пропагандируете потенциально опасные действия.
Ещё раз, если кратко: заправлять пропан в ёмкость, рассчитанную на изобутан нельзя, потому что при тех же условиях (температуре, главным образом) давление в сосуде будет в разы больше. Наоборот — можно, в ёмкость, расчитанную под пропан, заливайте изобутана сколько хотите.
Но если пропан загонять в тонкостенный изобутановые сосуды, то до запас до исчерпания предела прочности остаётся значительо меньший.
Компрессор нужен по сути для регенерации жидкого хладагента. Если у вас есть запас оного, например в баллоне, можете выпускать его в испаритель, а испарения стравливать в атмосферу.
Вполне себе работающий холодильник/кондиционер будет, пока запас жидкого хладагента не кончится.
Нет, вы делаете популярную ошибку. Холодильник работает благодаря фазовым переходам жидкости. То, что там газ сжимается/расширяется и при этом нагревается/охлаждается это вообще незначительный побочный эффект, который есть, но погоду особо не делает.
Ни в коем случае. Читайте:
https://habr.com/ru/companies/ruvds/articles/773470/comments/#comment_26272414
Я правильно понимаю, что основной посыл автора в том, что неведомо что предлагается называть не тёмной материей, а космическим эфиром, а кроме как другого названия для абсолютно непонятого пока явления предложить нечего?
Повторение — мать учения!
Чем больше окурков, тем меньше голов, ещё способных эффективно работать.
А почему очень больно?
Этот лозунг больше бы подошёл Джаве, а не системе контейнеризации.
А у оно не run anywhere, а работает на линуксе в контейнере. И что мешает ему работать точно так же на линуксе без контейнера?
Ошибаетесь. Разрабатывал, хоть и не так много, как под Windows.
Ну опишите открытым текстом, что вашим приложениям мешает жить на линукс-машины без завёртывания в контейнер?
И, каким бы ни был ответ, почему вместо допиливнаия линукса (что было бы идеологически верным) лепят нашлёпку поверх недопиленного линукса и ещё и радуются этому?
И как тогда по вашему существовал мир до создания докера? Как кромешный ад и ужас? Это мне напоминает «ощущение» у неофитов, что 100 лет назад мир в принципе был чёрно-белым.
Непонятно только, почему этим так называемым разработчикам приложений так «зашла» идея заворачивать приложения в изолированных ящиках.
Может потому, что они настолько криворукие разработчики, что не могут написать приложения, которые бы не мешали работе друг-друга?
В 2000-х была популярна шутка про начинающих разработчиков, которые пишут приложения, которые нигде больше не запускаются, кроме как на компе своего создателя. Такое ощущение, что весь тот докер про это.
Если же всё дело в изоляции, то чем системные механизмы изоляции не устраивают? И если все-таки не устраивают, с какого перепугу проблему изоляции прикладных программ решает другая прикладная программа, а не решается это на уровне ОС?
В каком виде вам нужен пруф, чтобы он считался пруфом? Если мой комментарий о том, что вещи устроены так, это не пруф, то будет ли моя статья об этом же самом считаться пруфом?
Я единолично разреверсил VB/VBA (по крайней мере эту его часть), задокументировал все типы узлов синтаксического дерева, организцию структур, типы сущностей RPN-подобного представления кода (дерево вскоре после своего построения конвертируется в линейную RPN-like цепочку из 16-битных сущностей и именно эти линейные структуры долговременно хранятся в памяти IDE, именно они представляют код и именно из них регенерируется текстовое представление кода, когда его нужно отрисовать на экране, скопировать в буфер обмена или сохранить в файл.
Вот вам пруф, к достоверности которого вы явно не прикопаетесь:
Откройте VB/VBA и в IDE напишите какой-нибудь код, например такой:
Теперь присоединитесь к процессу IDE отладчиком и попробуйте в памяти процесса найти эту строчку. Вы её там не найдёте. Ни в виде ANSI-строки, ни в виде UCS2-строки, ни в виде UTF8-строки. Ни в каком виде.
Точнее, есть шанс, что вы её случайно найдёте в памяти, но это просто просто мусор — незанулённый и никем более не используемый регион памяти. Можете затереть в таком случае всю найденную строку буквами «Ы», вернуться в IDE и строка с If-ом как была, так и останется.
А, ну окей, скажете вы, наверное IF как структура как-то хитро представляется, но вот условие IF-а, then-clause или else-clause должны храниться как строка.
Нет, тоже мимо.
Подстроку «
Minute(Now) Mod 2 = 0», подстроку «MsgBox "Hello World!"» и подстроку «MsgBox "Goodbye!"» вы тоже не найдёте. Их не будет в памяти. А если вдруг и будет, то это мусор, перезатирение которого чем-либо иным ни на что не влияет.Гораздо больше подробностей о том, как это устроено под капотом, можно прочитать в этом комменте
https://habr.com/ru/articles/582566/comments/#comment_23578554
трёхлетней давности. Там и с примерами того, как те или иные конструкции кодируются и гораздо больше.
И вот тут продолжение того коммента: https://habr.com/ru/articles/582566/comments/#comment_23589108
Конечно, дизайн языка должен соответствовать такой концепции. Но не нужно писать «этого не может быть, потому что этого не может быть никогда», в то время как подобное десятилетиями работало (и продолжает работать, или в современных Офисах выпилили VBA? — простите, я не слежу). Такие высказывания говорят скорее о малом кругозоре. В мире чего только не бывает.
А что значит само по себе выражение «передача метода в язык автоматическим управлением»?
В COM у метода могут быть аттрибуты (hidden, restricted), из из языка типа VB вы этот метод не увидите или не вызовите.
А вот что есть в спецификации COM, так это запрет на то, чтобы вызывать AddRef у одного интерфейса, а комплиментарный ему Release у другого. То есть, хотя 90% имплементаций имеют один счётчик ссылок «на объект», согласно спецификации у каждого интерфейса объекта (а интерфейсов у объекта может быть много) должен быть свой счётчик ссылок, и каждый интерфейс может порождаться/уничтожаться независимо от других.
Соответственно, вызывая AddRef или Release вы не управляете временем жизни объекта, вы управляете временем жизни конкретного интерфейса. Другое дело, что имплементация в 90% (а то и больше) случаев в угоду упрощения скатывается до единой для всех реализации AddRef/Release и единому счётчику ссылок. Более того, если реализовывать COM-объект на C++ как C++-класс, то по другому и не получится сделать, не прибегая к извратам.
Нет, не для этого. Visual Basic прекрасно может работать с объектами, не поддерживающими IDispatch. И с другой стороны, хотя любой экземпляр класса, написанного на VB, будет поддерживать IDispatch, вы прекрасно можете работать с такими объектами из других языков, не поддерживающими IDispatch.
Так что нет, IDispatch нужен не для интеграции с VB, он нужен для позднего связывания. А вот для VBScript он конечно же нужен, потому что там априори всё связывание — позднее, в момент интерпретации скрипта.