Личная вещь человека, приобретённая как частная покупка — это его сакральное право
Вот только ПО — это не личная вещь
Страну забыли уточнить.
Что до права на копирование, извлечение данных из ROM — то в США и РФ принципиально различный подход.
В США ты даже трактор свой отремонтировать не можешь сам. Нет у тебя такого права.
В РФ, являясь законным владельцем ПО, ты можешь его крякать, с целью отвязать от аппаратного ключа, к примеру. Если после этого используешь сам, а не предоставляешь другим, то ничего не нарушаешь.
Вы о них узнаете, когда они стали достаточно массовыми, известными.
Ну а поддержка большого количества пользователей уже имеет большую себестоимость.
Зачем кому-то за вас платить?
Разве что если вас заставляют смотреть на рекламу — тут хоть понятно на чём зарабатывают.
Нет, это оригинальная разработка. Общался с разработчиками.
API там от PostgreSQL, чтобы клиентов не переписывать — это да.
А собственно СУБД, вся работа с данными — это вполне себе полноценно уникальная разработка.
Для широкого использования нужна реляционная база.
Не согласен, что для широкого. Просто это привычнее, переучивать себя не нужно. Не зря NoSQL столь быстро внедрился, почва-то уже готова.
Но и реляционные есть у нас, причем оригинальные разработки, а вовсе не «MySQL с другим логотипом». СУБД Linter
Возможно это только потому, что это «длинная дистанция». СУБД Линтер уже очень и очень давно создается.
На короткой дистанции — можно только логотип поменять успеть.
Получается, что вы исключение из правила.
У меня перед глазами стоимость обновления сотни используемых нами продуктов, пока не встретился ни один, на который цена бы не поднялась.
Скажите, а продукты питания подешевели?
Зарплата тем же программистам тоже не менялась 2 года?
Это банальная инфляция.
У того, у кого не дорожает — держит цены ибо не может дороже, ибо конкуренция мешается.
В моей реальности код автоматом уезжает на «боевые» сервера после того, как ветка «production» в Git пройдет все тесты. И процентов 80% когда этого не происходило — как раз в тех случаях, когда программисты что то с конфигурационными файлами накосячили или тесты не все 100% выполнены были. Вины админа в косяках при ежедневном деплое у нас минимум. Остальные 20% косяков — это всё больше из-за того не хватает аппаратных ресурсов.
Было бы интересно почитать развернутое описание того, что именно происходит в вашей реальности.
В концепции DevOps админ как раз не отвечает за всё и вся в production. Дело админа предоставить ресурсы.
А если программист ресурсы некорректно задействовал — виноват уже программист.
В старом классическом подходе — у админа больше ответственности. Он и за разворачивание ПО отвечает. Пусть и по инструкциям программиста.
В DevOps деплой того кода, что есть результат работы программиста (на основе настроенной админом инфраструктуры) — всё больше чаще дело разработчика, а не админа.
С точки зрения программиста — это все на уровне «ресурсов, выделяемые под исполнение моего кода», а вовсе не то, что программисты устанавливают ОС. И стандартизованное развертывание, иначе тебе придется админу всё требования разжёвывать, и, скорее всего, еще и забудешь чего и получим «у меня на машине все работает, про сервер ничего не знаю».
Вполне себе удобный плюс, что программист знает как оно там в production, а то и прозрачный образом влияет на те ресурсы, что использует его программа в production.
А как же направление сил/мотивации в нужном направлении?
Толку-то от замотивированного спеца, если он делает не то, что нужно бизнесу? А рискует свою собственную новейшую СУБД, просто потому что ему это интересно. Но не потому что это нужно.
Соответствующие устройства должны иметь возможность ограничивать доступ к ресурсам и сервисам с запрещенной информацией — причем не только по сетевым адресам, но и при помощи запрета пропуска проходящего трафика
Вангую — «хороший одобренный государство трафик» тоже будет ломаться. И в больших масштабах.
Так как не существует возможностей 100% определить что именно за трафик.
А наказания за порчу «хорошего трафика» не предусмотрено.
Нас ждет эпоха нестабильного интернета. Прям как на заре его — в прошлом веке.
Но уже по причине искусственно внедренных багов — то есть систем глубокого анализа трафика.
Страну забыли уточнить.
Что до права на копирование, извлечение данных из ROM — то в США и РФ принципиально различный подход.
В США ты даже трактор свой отремонтировать не можешь сам. Нет у тебя такого права.
В РФ, являясь законным владельцем ПО, ты можешь его крякать, с целью отвязать от аппаратного ключа, к примеру. Если после этого используешь сам, а не предоставляешь другим, то ничего не нарушаешь.
Из Индии?
Страна хорошая, отличные воспоминания о поездке.
Но не об знании английского средним индийцем.
Ядро Ubuntu Server не так чтобы принципиально отличается от ядра Ubuntu Desktop. Можно и десктопную версию использовать.
А еще есть всевозможные web-панели управления.
Безусловно. Только это исключение, а не правило.
А можно ваш опыт более развернуто описать?
Если он есть конечно, а это не были умозрительные теоретические заключения
Ну как можно быть таким наивным
Вы о них узнаете, когда они стали достаточно массовыми, известными.
Ну а поддержка большого количества пользователей уже имеет большую себестоимость.
Зачем кому-то за вас платить?
Разве что если вас заставляют смотреть на рекламу — тут хоть понятно на чём зарабатывают.
Можно побольше конкретики что там у вас такое случилось?
Зачем им туда лезть?
Разве что админ не научился что есть DevOps/архитектура не полностью учла как положено по «12 факторам»
Нет, это оригинальная разработка. Общался с разработчиками.
API там от PostgreSQL, чтобы клиентов не переписывать — это да.
А собственно СУБД, вся работа с данными — это вполне себе полноценно уникальная разработка.
Не согласен, что для широкого. Просто это привычнее, переучивать себя не нужно. Не зря NoSQL столь быстро внедрился, почва-то уже готова.
Но и реляционные есть у нас, причем оригинальные разработки, а вовсе не «MySQL с другим логотипом».
СУБД Linter
Возможно это только потому, что это «длинная дистанция». СУБД Линтер уже очень и очень давно создается.
На короткой дистанции — можно только логотип поменять успеть.
Импортозамещение и не должно быть дешевле.
Было бы дешевле — не произошло бы изначального обратного экспортозамещения.
А зачем он там?
Скажите, а продукты питания подешевели?
Зарплата тем же программистам тоже не менялась 2 года?
Это банальная инфляция.
У того, у кого не дорожает — держит цены ибо не может дороже, ибо конкуренция мешается.
В моей реальности код автоматом уезжает на «боевые» сервера после того, как ветка «production» в Git пройдет все тесты. И процентов 80% когда этого не происходило — как раз в тех случаях, когда программисты что то с конфигурационными файлами накосячили или тесты не все 100% выполнены были. Вины админа в косяках при ежедневном деплое у нас минимум. Остальные 20% косяков — это всё больше из-за того не хватает аппаратных ресурсов.
Было бы интересно почитать развернутое описание того, что именно происходит в вашей реальности.
В концепции DevOps админ как раз не отвечает за всё и вся в production. Дело админа предоставить ресурсы.
А если программист ресурсы некорректно задействовал — виноват уже программист.
В старом классическом подходе — у админа больше ответственности. Он и за разворачивание ПО отвечает. Пусть и по инструкциям программиста.
В DevOps деплой того кода, что есть результат работы программиста (на основе настроенной админом инфраструктуры) — всё больше чаще дело разработчика, а не админа.
С точки зрения программиста — это все на уровне «ресурсов, выделяемые под исполнение моего кода», а вовсе не то, что программисты устанавливают ОС. И стандартизованное развертывание, иначе тебе придется админу всё требования разжёвывать, и, скорее всего, еще и забудешь чего и получим «у меня на машине все работает, про сервер ничего не знаю».
Вполне себе удобный плюс, что программист знает как оно там в production, а то и прозрачный образом влияет на те ресурсы, что использует его программа в production.
DevOps это процесс разработки, плотно интегрированный с развертыванием. Так что, да, это «про разработку ПО».
Программировать что именно?
Координироваться-то с другими надо.
А как же направление сил/мотивации в нужном направлении?
Толку-то от замотивированного спеца, если он делает не то, что нужно бизнесу? А рискует свою собственную новейшую СУБД, просто потому что ему это интересно. Но не потому что это нужно.
Вангую — «хороший одобренный государство трафик» тоже будет ломаться. И в больших масштабах.
Так как не существует возможностей 100% определить что именно за трафик.
А наказания за порчу «хорошего трафика» не предусмотрено.
Нас ждет эпоха нестабильного интернета. Прям как на заре его — в прошлом веке.
Но уже по причине искусственно внедренных багов — то есть систем глубокого анализа трафика.
Сижу в Firefox.
Всё работает.
Уже починили?