Ну вот, мне кажется, зря автор пытается выдергивать слова из контекста в статье. Благо видео приложено, и из него ситуация становится понятной. Спасибо автору за это.
Но ситуация очень даже не смешная : лицо принимающее решение требует у юристов - как у экспертов - точно ответить, кто ответственен за конкретные документы (в частности правила опубликованные на портале ) - а юристы раз за разом увиливают и отвечают общими фразами в третьем лице (они опубликованы, правила приняты и прочее) - мол кем-то там это опубликовано....
А это очень важный вопрос и важный ответ - ответ который должен был прозвучать именно "для протокола". От этого зависит с кого спрашивать и с кем разговоривать.
И фраза которую использовали для высмеивания ситуации в статье в первом абзаце - по сути уже сарказм, после того, как юристы несколько раз подряд не ответили на четко поставленный вопрос.
И что в итоге мы услышали? Услышали, что юрист не знает кто главнее - российское отделение "эппла" или "эппл инкорпорейтед". Занавас. Хороший юрист, видимо.
"Юристы не смогли ответить на вопрос "кто главнее - российское отделение эппл или американское эппл инкорпорейтед?"" - вот это должно было быть в заголовке.
А вы высмеиваете должностное лицо, которое пытается разобраться в ситуации... еще и опрос юморной создаете. Ну зачем так?
Кстати. Внимательные _американские_ зрители уже заметили на кадрах трансляции «первую мышь-астронавта которая улетела в космос без скафандра» на корпусе корабля Илона Маска. :)
Вот ссылка на ютуб с привязкой ко времени: youtu.be/e_5NCze1ZVg?t=11241
(смотреть на левую картинку — там где работает раскаленный до красна двигатель. нечто выпадает из-за золотинки на трубу, и «убегает» на верхнюю (относильно кадра) поверхность двигателя)
Выглядит и ведет себя действительно как мышь. но ведь её там быть не могло. ну не могло же…? или часть кадров «трансляции» — вовсе не трансляция и не то, за что нам это выдают"?
Ожидаем скандалЪ, по сравнению с которым наезды на Кубрика и лунную миссию были детской возней в песочнице?
Ну а если серьезно — вопрос к «знатокам» — что фигня творится на 6й с половиной минуте полета на между 30й и 35й секундами на камере показывающей работающий двигатель корабля ?!
Что это такое могло быть?
Маск сделал лоукост вариант. «Лоукост» — именно что во всех отношениях и ограничениях.
Молодец.
Только ведь жизнедеятельнсоть авиакомпании «победа» не привела к кончине «аэрофлота»? Так ведь?
И когда еще Маск сделает тяжелые ракетоносители — тоже еще вопрос.
И сделает ли. Но будем надеяться, что его намерение их сделать — «наши» будут рассматривать уже всерьез.
И предлагаю не ставить знак равно между «российским космосом» и текущим «роскосмосом». Менеджеров роскосмоса (в том числе и бывших) как бы можно и расстрелять… хотя нет, времена не те...… в отставку текущих отправить. ( но пиарщикам Рогозина (если они такие есть) — точно надо дать по голове за то, что позволили ему такие высказывания на публику — теперь Рогозину за это все косточки перемоют, но он как бы и сам виноват)
Отрасли был нужен пинок. «топы зажрались»)
Маск молодец что такой пинок сделал.
Посмотрим. интрига-ж, ведь )
Вы, кажется, сильно заблуждаетесь.
Ну или, может быть, у меня очень плохо с географией.
Давно Сан-Франциско отделился от сша? )
В пользовательском соглашении, как «основной» адрес компании Atlassian, которая целиком и полностью владеет сервисом «bitbucket» (который, вопреки вашим предположениям, «компанией» не является. поправьте?) указан адрес именно в Сан-Франциско. www.atlassian.com/legal/privacy-policy
А в соглашении на использвоании облачных технологий ( www.atlassian.com/legal/cloud-terms-of-service ) так и вообще идет прямое указание на экспортные соглашения соединенных штатов и другие законы, тоже, штатов. не Европейсткие законы, ни Российские законы, ни законы других стран.
Вы точно уверены что компании, которые, как вы предполагаете, «не являются американскими фирмами» — будут подчиняться американским законам, руководствоваться в своей деятельности этими законами, и как головной офис указывать офис в Сан-Франциско? )
правда? имхо, ваша уверенность основана на весьма зыбких предположениях.
возьмем gitlab, sourceforge, bitbucket — они что — тоже прогнулись под «левую пятку заокеанских сенаторов» в этот раз? нет. они (поправьте?) в прошлом году никого не блокировали «из-за санкий».
PS: я да, я помню, что тот же sourceforge уже был ранее замечен в подобных действиях в период небезызвестных событий в персидском заливе. но в этот же раз они одумались? )
айкрософт внезапно прикроет доступ к опен-сорс проектам на гитхабе или в том же nuget'e? Или попытается брать деньги за доступ?
ну вот, блин.
извините, но вот «прямо как вчера родились»)))
напомню события 31 июл 2019 г.: «GitHub ограничивает учётные записи разработчиков из Ирана, Крыма, Сирии и других регионов, находящихся под санкциями США».
или вам напомнить события послужившие причиной появления «Libre Office»?
или рассказать как оракл сейчас ужом извивается, всеми силами пытается «закрыть/монетизировать джаву», вот прямо спит и видит как ему будут платить за любой чих использования джавы? (и очень хорошо, что в свое время Sun сделал много, что бы сейчас не один оракл это решал)
___________________________________
Крайне наивно считать, что «ничего не случится» в головах людей, которые нацелены на максимизацию прибыли любыми средствами.
Тем более при смене управляющего. Вам разве сама история появления этого завяления не показала, что «развернуться на 180 градусов», забыть все свои заявления и обещания, сделанные до того момента, делать все что хочется с имеющимися активами — для таких компаний в норме вещей?
Оно по разному может аукнуться.
И деньги могут начать брать, и доступ могут закрыть.
И «лутбоксы» с «баннерами» могут вам к код подкладывать.
Ведь, если это делается без нарушения лицензии — с сохранением опенсорсности кода — то никто же не мешает это делать тому же майкрософту/ораклу/etc?
тем более когда они уже засветились в «крайне странных и сомнительных» телодвижениях.
Вам никто не обещал по «пользовательскому соглашению github », что ваш код будет хранится неизменным, а владелец репозитория не будет вмешивать в ваш код в github свои правки.
Покажете мне пункт в соглашении который запрещает это делать?
Покажете мне пункт, который запрещает владельцу github менять этот пункт в соглашении в одностороннем порядке?
а у меня есть коллега на работе — который нашел баг в эклипсе, выкачал сорсы, пропатчил, и отправил патч разрабам. и патч приняли. никакого ожидания по несколько лет.
с вендой же — даже официально зарегистрированные баги в операционке с красными рейтингами не патчат лет по 10. потому что «пиплз схавает», да и как тогда зарабатывать на антивирусах?
под нож идет все, что нарушает работу их сервисов или противоречит их политике не взирая на то, опенсорс это или нет.
и из этого нельзя сделать вывод, что яндекс любит или не любит опенсорс.
вот если бы были наблюдения, что режут доступ только для оенсорсных утилит — а для вот этих проприетарных — доступ разрешают — тогда еще можно было бы сделать предположениею что опенсорс не любят.
упоминая в заголовке факты или аспекты, которые не являюется главной закономерностью — вы играете грязно, в стиле желтых бульварных газет.
вы пытаетесь поднять хайп, выдавая недоказанное или частное, как главное.
то, что утилита rclone является опенсорсной — совсем не важно.
важно что яндекс блокирует доступ утилит автоматического бакапа и синхронизации. вот эта мысль важна. и уже потом — можно упомянуть, что вы обнаружили это на примере утилиты rclone, которая, как и 90% утилит в вашем дистрибутиве линукса — опенсорсные.
ваш же заголовок — некорректен. как например, и заголовок вида «у меня при игре в кости выпадают шестерки!» — некорректен, потому что он как бы намекает что у вас при подбрасывании кубика выпадают «только шестерки».
вы создали заголовок задача которого вызвать хайп выдавая одно за другое.
вас уже указали пару раз в опенсорсных пабликах люди не прочитавшие статью. вот спрашивается при чем тут опенсорс? вы скажете что это хорошо что вас показывают? я скажу что это желтизна, и за такое надо банить. все таки хабр — это не бульварная газета с кричащими заголовками. был по карйней мере.
более того, вы приводите в статье цитаты про любовь яндекса к опенсорс, и подогревая хайп, подсовываете вывод, который не имеет под собой оснований, типа а вот нет не любят.
на основании чего вы делаете такой вывод?
опенсорсность утилит должна давать какую то неприкосновенность?
например, опенсорсный вирус не надо удалять с компьютера?
вы, что — полагаете что опенсорсность должна давать протекцию в вопросе «отключать или нет если утилита создает нагрузку»?
извините, но не надо выворачивать одно в другое.
или получается нечто аналогичное обратному фашизму
вида «тебя что, должны любить, только потому что ты негр?»(с)
т.е. «утилитой должны пользоваться и не запрещать, только потому, что она опенсорсная»? даже если она нарушает нормальную работу системы?
итог: подобными заголовками и выводами — вы вредите опенсорс движению.
вы выворачиваете саму идею опенсорсности, и идете по модели поведения современных «борцов за права меньшинств», которые своей неадекватностю и нападками не только выставляют себя на посмешище, но и фактически вывернули исходную идею в формат «обратного фашизма». не надо так.
как другой приверженец опенсорс, я бы просил вас изменить заголовок, т.к. текущий выворачивает картину в несоответствующий действительности аспект, и либо убрать из статьи пассаж про «вот нет, не любят» — или хотя бы изложить его в формате вопроса. под которым, кстати, вы сможете набрать статистику что где и когда банил яндекс. вдруг там действительно вырисуется картина, что есть проприетарные утилиты которые не блокируют? (свои от яндекса утилиты — не в счет).
в конце концов — мы же тут ит-спецалисты, инженеры. с логикой, адекватностью и честностью у нас должно быть гораздо лучше, чем у журналистов бульварной желтизны. или вы хотите поднять хайп, а потом, когда все разберутся, войти в историю в аспекте аналогичном автору болгеноса и «антивируса попова»
Мне кажется, ситуация является прямым продолжением бездумного хайпа вокруг гибких/итерационных технологий разработки, который мы имели лет 5 назад.
Вспоминайте — все кому не лень вешали себе ярлыки «мы работаем по эджайлу», хотя у многиз даже итерационных процессов разработки и в помине не было.
Что в итоге? Молодые, насмотревшись на это, закрепили у себя в голове ассоциацию — «если говорят про agile — значит 90% пытаются обмануть».
И я даже из в этом не просто понимаю, я их поддерживаю.
К молодым, тоже, есть вопрос вида — а вы разобраться в сути вопроса не пробовали? (потому что, увы, не разбирались в большинстве своем).
Но повторюсь, что когда я вижу компанию, которая в вакансиях в первую очередь говорит про модные хайпанутые в этом сезоне технологии, процессы, или вещи — не важно будет это «эджайл», «девопс», «ангуляр на первом месте», «всем сотрудникам макбуки», «работаем только в идее», «git-flow» и тд и тп. — степень доверия к вакансии и к компании падает в разы, пропорционально числу использованных «слов для привлечения внимания». Не первостепенные это вещи. ;)
Как с бороться с негативов в сторону «эджайла» — не знаю.( и надо ли — «бороться»? пусть будет урок — вы хайпанули? попытались легковесную не масштабируемую технологию воткнуть везде? использовали «эджайл» как рекламный слоган в вакансиях для фактического обмана соискателей? — «получите негатив, распишитесь вот тут»… и пусть это будет памятник всем кто решил верить рекламе и хайпу)…
Наверное, надо, в первую очередь учить думать, не вестись на хайп, не раздувать хайп, не подменять понятия, вести разъяснительную работу.
В первую очередь — представлять из себя разумного рассуждающего человека.
И не пытаться выставлять очередную технологию как «мировую вакцину» — не пихать ее везде и всегда. Технология, процесс — это не серебрянная пуля. это просто тезнология, как и все технологии ограниченная.
Пять лет назад пихали эджайл во все дыры? — пихали. Даже туда, где эджайл не применим в силу условий среды; совершенно не разбираясь и не думая о границах применимости технологии…
Получили (ну наконец то!) негативный фидбек. Все закономерно, «шила в мешке не утаить», «нельзя обманывать всех людей все время» и тд.
Эджайл хорошая технология, но и как всякая технология она применимы далеко не во всех условиях, не на всех типах проектов. Об этом надо помнить, и, имхо, в таком направлении вести разъяснительную работу, а не пытаться обелить «имя эджайла» разбирая конкретные вопросы за и против.
Эджайл уже стал жертвой хайпа, извратившего суть термина. Ближайшее время это не изменится. Тут только разъяснять конкретным людям и объяснять про то, что «вы знаете о том, когда надо прекратить применять эджайл» и переходить на более тяжеловестный или другие по структуре процессы, и, в том числе, — доказывать, что вы знаете на какие процессы переходить и когда.
Простите, но мне одному кажется, что автор подменяет понятия?
Яндекс заблокировал конкретные действия — вне зависимости от того, открыты исходники инструмента или нет.
А автор пытается выдать это в плоскость борьбы с опенсорсом.
Или у автора есть примеры того, что яндекс разрешает автоматическую синхронизацию проприетарным утилитам? (свои клиенты яндекс-диска не в счет, по понятным причинам).
К яндексу, конечно, есть вопросы, но того характера что «вы в своем праве, но вы делаете не удобно вашим фанатам. Не даете автоматический бакап на яндекс диск — ок, но предложите путь как это делать по другому — тариф другой, или другой сервис?...»
Но и искажать ситуацию в статье, пытаться выдавать одно (ограничение нагрузки на свои сервисы) за другое (обвинять яндекс в нелюбви к опенсорс) — ради красного словца и хайпа — это же тоже не дело?
Это опенсорс. Когда вы берете опенсорсное решение, вы должны понимать риски. Если нет, ну решение тут непричем.
ну, ну… не смешивайте опенсорс и бесплатность/отсутствиеподдержки.
скажем так, Java — тоже сейчас опенсорс.
но можно заказать официальную коммерческую поддержку. а в связи с обновлениями лицензий оракла — еще, и обязаны, если у вас не openJDK.
Не знаю) Вы как человек от бизнеса, не проработали этот вопрос, когда решили его использовать?
я то вот как раз, (вроде) проработал в своё время, и выбираю как правило совсем не питон. и не советую питон в иных ролях кроме как скриптование мелких одноразовых задач. но некоторые заказчики находятся в таком диком убеждении что на питоне можно всё и вся, и для всего пригодно, так свято верят,… что я подумал — «может я что забыл ?»…
Внезапно, Питон тоже язык с динамической типизацией, только строгой.
всё лучше, чем те безобразия как у js или руби )))
и кажется же, что были разговоры про введение статической типизации?.. писал на питоне совсем давно, еще когда только третий был в самую новинку. подумал, может что изменилось. хотя бы методически — описание, стандарт внятный как у js например может появился… <_<
или может питоновцы что то «действительно новое придумали» в плане как быть с большими задачами и рефакторингом…
но, похоже, что принципиально пока ничего не изменилось. вопрос с позиционированием питона на ближайшее время, как минимум для меня, снова закрыт.
Иначе берите JS, на нем сейчас чего только не пишут. Там обратная совместимость практически 100%, со всеми вытекающими.
вообще, js плохо подходит для больших систем, в следствии динамической типизации.
опять же вспомню про создателей node.js, которые (честь и хвала им) осознали это достаточно быстро, и пересаживают всех на typescript. но, имхо, им этого тоже не надолго хватит, потому что «та же многопоточность», от которой никуда не деться, но которую нельзя впилить внятно в это «дитя js». потому js — нет, не подходит для сложных систем.
про красоту я не писал, вы сами это придумали. Писал я про эволюцию. А это совсем другое. Например, изменение существующих решений. Пример я уже привел про строки в юникоде.
как эта «эволюция» помогает бизнесу эффективнее выполнять производственные функции?
что, лямбда-выражения, которые даже в джаву воткнули, повысили скорость обработки транзакций? нет.
а переход на юникод понизил расход ресурсов? опять же, утрируя — нет.
а «про юникод» бизнес вас вообще спросит: а почему вы сразу так не сделали? а когда вы разведете руками — запишет в графе «минусы»: "принимали необдуманные рещения, теперь просят с нас денег на перевод системы на вовую версию питона исправление своих ошибок в прошлом".
понимаете? во главе угла не эволюция ))) во главе угла сохранение работоспособности и минимизация расходов.
Если ваш бизнес не готов вложиться в переход на новую версию, можно сидеть на старой, никто ее не ломает, работать она будет, пока ваш проект на ней живёт
в этой фразе нет проработки рисков.
бизнес не может (вернее здравомыслящий бизнес не будет) сидеть на неподдерживаемой версии языка/системы, потому что в этом случае, все риски и ответственность связанные с ошибками в платформе/sdk/языке и убытками в следствии этих убытков — лягут на плечи подразделений этого самого бизнеса. а это никому из здравомыслящих менеджеров не надо — никто не хочет быть «виноватым без вины».
потому они будут «страховать свои риски» — если есть деньги, покупая техподдержку и перекладывать таким образом ответсенность за косяки в коде на плечи производителя.
но! повторюсь, что переход на новые версии языка, с целью сохранения поддержки — может быть крайне дорогостоящим предприятием в случае поломки совместимости. в итоге, такую постоянную гонку с переходом на новые версии можно похволить себе только для небольших систем.
Если же вы хотите получать новый функционал в языке,…
вы продолжаете мыслить не теми категориями.
«бизнесу» — глубоко все равно какие там функции в языке.
… меньше ошибок и уязвимостей в том же интерпретаторе, то бизнес должен понимать, что это не всегда нахаляву дается
никто не говорит про халяву. но затраты бывают разные
есть одна стоимость техподдержки, она линейна от времени.
и есть другая стоимость — стоимость по переработке системы на новую версию платформы/языка. и это требуется выполнить что бы иметь возмодность заплатить за первое. и эта стоимость растет нелинейно от объема кода.
а новые фичи языка — бизнусу побоку. не нужно ему это.
ему нужны функции в производственной системе.
имхо, самый большой риск бизнеса связанный с it: это остаться в ситуации, когда производитель больше не оказывает услуг по техподдержке старых версий (не на кого переложить ответственность), а пересаживать систему на новую версию языка крайне затратно, потому что они вкладывались в разработку системы последние лет 5, и они стала очень большой.
и я снова спрашиваю: может ли питон 3 предложить что либо для минимизации таких рисков кроме LTS ( который, как было описано выше — не очень сильно помогает на большом сроке )?
вдумчивое отношение (см ответ выше) — оно включает в себя и выбор базовых решений. опять же, не к ночи, джава от рождения (кажется) была (почему то?) юникодной ( или если это появилось потом — то, кажется, не поломало обратной совместимости ).
с выделение байта в тип — мне прокомметировать сложнее ( не так хорошо знаю питон) но опять же в джаве вспоминается трюк с boxing-unboxing для простых и объектных типов.
согласен, проще — плюнуть на старый механизм, чем придумать как это должно работать совместно.
но поймите, что именно такое «наплевательство» делает питон не выгодным «для бизнеса» с точки зрения длительных инвестиций и разработки больших систем.
и, увы, имхо, то что вы восхваляете как правильное и хорошее в 3м питоне — это, хотя и действитеьно (верю вам) правильное и хорошее, но это прямое следствие необдуманных решений при создании первоначального стандарта языка; а ситуацию из топика — мы имеем в виду «наплевателского» стиля при введении новых фич. имхо.
хотя, иногда такое наверное и надо делать. если вспомнить преход с Qt3 на Qt4 — это было действительно правильно. троллтечю пока еще были троллтечами, вообще с нуля переписали весь апи, получилось очень стройно, удобно и красиво. но, ВАЖНО, что у систем на базе C++/Qt и срок жизни куда менее чем 5-10 лет. ни о какой долгосрочности или громадности систем речи нет.
вы меня простите, но вы, имхо, по прежнему мыслите категориями «давайте сделаем наш инструмент красивым».
бизнесу глубоко положительно и на «прогресс языка» и на неудачную архитектуру — как минимум, пока код работает и делает то что должен и не требует к себе лишнего внимания. потому, что работающий код — это хорошо вложенные деньги, дающие отдачу и экономию.
вы ставите во главу угла некий «проресс», кстати не детализаруя что это конкретно значит, а бизнес задается вопросом: «а сколько денег будет стоить этот прогресс» и «кто конкретно за это будет платить»?
мы можем и должны развивать экспериментальные языки для новых изучения новых возможностей, архитектуры, но для долговременных больших, промышленных проектов надо нечто совершенное иное. и экспериментальные языки не должны выбираться для разработки больших систем.
— Обратную совместимость поддерживать, имхо, можно, достаточно долго, сильно больше чем любая LTS; хотя и при соблюдении ряда условий:
1. во перых требуется автомтический контроль за этой совместимостью (читай автоматические тесты валидности интерпритаторов/компиляторов под каждую версию). иначе как эту совместимость действительтно проверять?
2. требуется полное описание спецификации языка, работы интерпретатора, включая исключения под работу старых стандартов. полная спека, достаточная для того, что бы написать тестф из пункта 1 и провести валидацию стороннего интерпретатора. пункт 1 будет гарантировать что новая спека не ломает работу старой.
не к ночи будет сказано, но у джавы и джаваскрипта такие спеки есть.
и есть альтернативные реализации, и процессы валидации/тестирования/проверки сторонних интерпритаторов тоже есть. и джава и а 13й версии продолжает поддерживать работоспособность версии 1.
у питона есть такое? а когда появится?
есть альтернативные реализации, совместимые с исходным стандартом?
3. требуется вдумчивое отношение к нововведениям, и аккуратное прописывание стандарта новой версии. не на поводу у модно-хипстеров, а с учетом действительной необходимости. опять же, не к ночи будет упомянута джава. что там с js в этой частию мне сказать сложнее, я не отслеживал развитие js в деталях.
— вот я и спрашиваю: питон 3 — это всё еще экспериментальный язык, для небольших систем со сроком жизни полгода-год, «с новыми фичами» и с «правильной по последнему слову архитектурой», которая целенаправленно и осознанно ломает обратную совместимость ради новых фич…
или это уже язык, претендуюший на звание «промышленный язык» — язык, в разработку кода на котором бизнес может вкладываться на горизонте более 5-10 лет, не боясь, что в какойто момент, все то, что было создано перестанет работать, потому что версия языка перестанет поддерживаться?
это не к рассуждениям плохо-хорошо.
это к позиционированию, и осознанию места и ниши языка, границ его применимости, внушения толпам молодых красноглазых неофитов/фанатиков правильного понимания о том, «где это можно применять».
мне, например, очень нравится идея когда питон применяют математики для расчетов и скриптования повседневных ad-hoc задач. вплоть до того, что я подумывал ввести скриптование на питоне в одной из систем.
допускаю изучение питона как учебного языка (на замену паскалю),
но меня, же вот буквально подташнивает от попыток и заявлений неофитов создать на этом языке что-то действительно большое, с претензией на долгосрочность. потому что я раз за разом, не первый год, вижу чем кончаются такого рода попытки, и как быстро проходит мода на «очередной заменитель джавы», (опять, простите, «не к ночи будет сказано»).
Я как раз и говорю, что новые фичи вобще являются несущественным фактором для промышленного языка. Существенным является что бы поведение системы не менялось при переводе ее на новый интерпретатор/компилятор/платформу, и не требовалось менять код для такого перевода.
Более того, я считаю, что проблема EOL средств разработки для больших систем гарантированно наступает. (какой бы не был LTS длительным — он кончится).
И _единственный_ путь по предотвращению проблемы окончания EOL — это обеспечение обратной соместимости между версиями языка, когда новая версия пусть и добавляет новвые фичи, но гарантирвоанно не меняет поведение старого кода.
Вот я и пытаюсь узнать — что делается создателями питона 3, что бы помочь избежать проблем связанных с EOL?
Ну вот, мне кажется, зря автор пытается выдергивать слова из контекста в статье.
Благо видео приложено, и из него ситуация становится понятной. Спасибо автору за это.
Но ситуация очень даже не смешная : лицо принимающее решение требует у юристов - как у экспертов - точно ответить, кто ответственен за конкретные документы (в частности правила опубликованные на портале ) - а юристы раз за разом увиливают и отвечают общими фразами в третьем лице (они опубликованы, правила приняты и прочее) - мол кем-то там это опубликовано....
А это очень важный вопрос и важный ответ - ответ который должен был прозвучать именно "для протокола". От этого зависит с кого спрашивать и с кем разговоривать.
И фраза которую использовали для высмеивания ситуации в статье в первом абзаце - по сути уже сарказм, после того, как юристы несколько раз подряд не ответили на четко поставленный вопрос.
И что в итоге мы услышали? Услышали, что юрист не знает кто главнее - российское отделение "эппла" или "эппл инкорпорейтед". Занавас.
Хороший юрист, видимо.
"Юристы не смогли ответить на вопрос "кто главнее - российское отделение эппл или американское эппл инкорпорейтед?"" - вот это должно было быть в заголовке.
А вы высмеиваете должностное лицо, которое пытается разобраться в ситуации... еще и опрос юморной создаете. Ну зачем так?
Вот ссылка на ютуб с привязкой ко времени: youtu.be/e_5NCze1ZVg?t=11241
(смотреть на левую картинку — там где работает раскаленный до красна двигатель. нечто выпадает из-за золотинки на трубу, и «убегает» на верхнюю (относильно кадра) поверхность двигателя)
Выглядит и ведет себя действительно как мышь. но ведь её там быть не могло. ну не могло же…? или часть кадров «трансляции» — вовсе не трансляция и не то, за что нам это выдают"?
Ожидаем скандалЪ, по сравнению с которым наезды на Кубрика и лунную миссию были детской возней в песочнице?
Ну а если серьезно — вопрос к «знатокам» — что фигня творится на 6й с половиной минуте полета на между 30й и 35й секундами на камере показывающей работающий двигатель корабля ?!
Что это такое могло быть?
но в любом случае настроения первого комментатора вида «конец российскому космосу» — это паникерсво и нагнетание — согласитесь?
( нашел статистику запусков за 2019й год — она как бы сама говорит, что такие настроения — далеки от реального положения дел )
И почему паникеры не орут про успехи Китая и не пророчат конец обоим космосам — и американскому и российскому? ))
Маск сделал лоукост вариант. «Лоукост» — именно что во всех отношениях и ограничениях.
Молодец.
Только ведь жизнедеятельнсоть авиакомпании «победа» не привела к кончине «аэрофлота»? Так ведь?
И когда еще Маск сделает тяжелые ракетоносители — тоже еще вопрос.
И сделает ли. Но будем надеяться, что его намерение их сделать — «наши» будут рассматривать уже всерьез.
И предлагаю не ставить знак равно между «российским космосом» и текущим «роскосмосом». Менеджеров роскосмоса (в том числе и бывших) как бы можно и
расстрелять… хотя нет, времена не те...… в отставку текущих отправить. ( но пиарщикам Рогозина (если они такие есть) — точно надо дать по голове за то, что позволили ему такие высказывания на публику — теперь Рогозину за это все косточки перемоют, но он как бы и сам виноват)Отрасли был нужен пинок. «топы зажрались»)
Маск молодец что такой пинок сделал.
Посмотрим. интрига-ж, ведь )
Ну или, может быть, у меня очень плохо с географией.
Давно Сан-Франциско отделился от сша? )
В пользовательском соглашении, как «основной» адрес компании Atlassian, которая целиком и полностью владеет сервисом «bitbucket» (который, вопреки вашим предположениям, «компанией» не является. поправьте?) указан адрес именно в Сан-Франциско. www.atlassian.com/legal/privacy-policy
А в соглашении на использвоании облачных технологий ( www.atlassian.com/legal/cloud-terms-of-service ) так и вообще идет прямое указание на экспортные соглашения соединенных штатов и другие законы, тоже, штатов. не Европейсткие законы, ни Российские законы, ни законы других стран.
Вы точно уверены что компании, которые, как вы предполагаете, «не являются американскими фирмами» — будут подчиняться американским законам, руководствоваться в своей деятельности этими законами, и как головной офис указывать офис в Сан-Франциско? )
возьмем gitlab, sourceforge, bitbucket — они что — тоже прогнулись под «левую пятку заокеанских сенаторов» в этот раз? нет. они (поправьте?) в прошлом году никого не блокировали «из-за санкий».
PS: я да, я помню, что тот же sourceforge уже был ранее замечен в подобных действиях в период небезызвестных событий в персидском заливе. но в этот же раз они одумались? )
извините, но вот «прямо как вчера родились»)))
напомню события 31 июл 2019 г.: «GitHub ограничивает учётные записи разработчиков из Ирана, Крыма, Сирии и других регионов, находящихся под санкциями США».
или вам напомнить события послужившие причиной появления «Libre Office»?
или рассказать как оракл сейчас ужом извивается, всеми силами пытается «закрыть/монетизировать джаву», вот прямо спит и видит как ему будут платить за любой чих использования джавы? (и очень хорошо, что в свое время Sun сделал много, что бы сейчас не один оракл это решал)
___________________________________
Крайне наивно считать, что «ничего не случится» в головах людей, которые нацелены на максимизацию прибыли любыми средствами.
Тем более при смене управляющего. Вам разве сама история появления этого завяления не показала, что «развернуться на 180 градусов», забыть все свои заявления и обещания, сделанные до того момента, делать все что хочется с имеющимися активами — для таких компаний в норме вещей?
Оно по разному может аукнуться.
И деньги могут начать брать, и доступ могут закрыть.
И «лутбоксы» с «баннерами» могут вам к код подкладывать.
Ведь, если это делается без нарушения лицензии — с сохранением опенсорсности кода — то никто же не мешает это делать тому же майкрософту/ораклу/etc?
тем более когда они уже засветились в «крайне странных и сомнительных» телодвижениях.
Вам никто не обещал по «пользовательскому соглашению github », что ваш код будет хранится неизменным, а владелец репозитория не будет вмешивать в ваш код в github свои правки.
Покажете мне пункт в соглашении который запрещает это делать?
Покажете мне пункт, который запрещает владельцу github менять этот пункт в соглашении в одностороннем порядке?
с вендой же — даже официально зарегистрированные баги в операционке с красными рейтингами не патчат лет по 10. потому что «пиплз схавает», да и как тогда зарабатывать на антивирусах?
и из этого нельзя сделать вывод, что яндекс любит или не любит опенсорс.
вот если бы были наблюдения, что режут доступ только для оенсорсных утилит — а для вот этих проприетарных — доступ разрешают — тогда еще можно было бы сделать предположениею что опенсорс не любят.
упоминая в заголовке факты или аспекты, которые не являюется главной закономерностью — вы играете грязно, в стиле желтых бульварных газет.
вы пытаетесь поднять хайп, выдавая недоказанное или частное, как главное.
то, что утилита rclone является опенсорсной — совсем не важно.
важно что яндекс блокирует доступ утилит автоматического бакапа и синхронизации. вот эта мысль важна. и уже потом — можно упомянуть, что вы обнаружили это на примере утилиты rclone, которая, как и 90% утилит в вашем дистрибутиве линукса — опенсорсные.
ваш же заголовок — некорректен. как например, и заголовок вида «у меня при игре в кости выпадают шестерки!» — некорректен, потому что он как бы намекает что у вас при подбрасывании кубика выпадают «только шестерки».
вы создали заголовок задача которого вызвать хайп выдавая одно за другое.
вас уже указали пару раз в опенсорсных пабликах люди не прочитавшие статью. вот спрашивается при чем тут опенсорс? вы скажете что это хорошо что вас показывают? я скажу что это желтизна, и за такое надо банить. все таки хабр — это не бульварная газета с кричащими заголовками. был по карйней мере.
более того, вы приводите в статье цитаты про любовь яндекса к опенсорс, и подогревая хайп, подсовываете вывод, который не имеет под собой оснований, типа а вот нет не любят.
на основании чего вы делаете такой вывод?
опенсорсность утилит должна давать какую то неприкосновенность?
например, опенсорсный вирус не надо удалять с компьютера?
вы, что — полагаете что опенсорсность должна давать протекцию в вопросе «отключать или нет если утилита создает нагрузку»?
извините, но не надо выворачивать одно в другое.
или получается нечто аналогичное обратному фашизму
вида «тебя что, должны любить, только потому что ты негр?»(с)
т.е. «утилитой должны пользоваться и не запрещать, только потому, что она опенсорсная»? даже если она нарушает нормальную работу системы?
итог: подобными заголовками и выводами — вы вредите опенсорс движению.
вы выворачиваете саму идею опенсорсности, и идете по модели поведения современных «борцов за права меньшинств», которые своей неадекватностю и нападками не только выставляют себя на посмешище, но и фактически вывернули исходную идею в формат «обратного фашизма». не надо так.
как другой приверженец опенсорс, я бы просил вас изменить заголовок, т.к. текущий выворачивает картину в несоответствующий действительности аспект, и либо убрать из статьи пассаж про «вот нет, не любят» — или хотя бы изложить его в формате вопроса. под которым, кстати, вы сможете набрать статистику что где и когда банил яндекс. вдруг там действительно вырисуется картина, что есть проприетарные утилиты которые не блокируют? (свои от яндекса утилиты — не в счет).
в конце концов — мы же тут ит-спецалисты, инженеры. с логикой, адекватностью и честностью у нас должно быть гораздо лучше, чем у журналистов бульварной желтизны. или вы хотите поднять хайп, а потом, когда все разберутся, войти в историю в аспекте аналогичном автору болгеноса и «антивируса попова»
я не про бизнес модель яндекса.
я вопрос задаю про подмену понятий в статье хабра.
вне зависимости от того, что там думает яндекс про свои диски, в данной статье выводы про «яндекс не любит опенсорс» притянуты за уши.
в статье с логикой проблемы. я один это вижу?
Вспоминайте — все кому не лень вешали себе ярлыки «мы работаем по эджайлу», хотя у многиз даже итерационных процессов разработки и в помине не было.
Что в итоге? Молодые, насмотревшись на это, закрепили у себя в голове ассоциацию — «если говорят про agile — значит 90% пытаются обмануть».
И я даже из в этом не просто понимаю, я их поддерживаю.
К молодым, тоже, есть вопрос вида — а вы разобраться в сути вопроса не пробовали? (потому что, увы, не разбирались в большинстве своем).
Но повторюсь, что когда я вижу компанию, которая в вакансиях в первую очередь говорит про модные хайпанутые в этом сезоне технологии, процессы, или вещи — не важно будет это «эджайл», «девопс», «ангуляр на первом месте», «всем сотрудникам макбуки», «работаем только в идее», «git-flow» и тд и тп. — степень доверия к вакансии и к компании падает в разы, пропорционально числу использованных «слов для привлечения внимания». Не первостепенные это вещи. ;)
Как с бороться с негативов в сторону «эджайла» — не знаю.( и надо ли — «бороться»? пусть будет урок — вы хайпанули? попытались легковесную не масштабируемую технологию воткнуть везде? использовали «эджайл» как рекламный слоган в вакансиях для фактического обмана соискателей? — «получите негатив, распишитесь вот тут»… и пусть это будет памятник всем кто решил верить рекламе и хайпу)…
Наверное, надо, в первую очередь учить думать, не вестись на хайп, не раздувать хайп, не подменять понятия, вести разъяснительную работу.
В первую очередь — представлять из себя разумного рассуждающего человека.
И не пытаться выставлять очередную технологию как «мировую вакцину» — не пихать ее везде и всегда. Технология, процесс — это не серебрянная пуля. это просто тезнология, как и все технологии ограниченная.
Пять лет назад пихали эджайл во все дыры? — пихали. Даже туда, где эджайл не применим в силу условий среды; совершенно не разбираясь и не думая о границах применимости технологии…
Получили (ну наконец то!) негативный фидбек. Все закономерно, «шила в мешке не утаить», «нельзя обманывать всех людей все время» и тд.
Эджайл хорошая технология, но и как всякая технология она применимы далеко не во всех условиях, не на всех типах проектов. Об этом надо помнить, и, имхо, в таком направлении вести разъяснительную работу, а не пытаться обелить «имя эджайла» разбирая конкретные вопросы за и против.
Эджайл уже стал жертвой хайпа, извратившего суть термина. Ближайшее время это не изменится. Тут только разъяснять конкретным людям и объяснять про то, что «вы знаете о том, когда надо прекратить применять эджайл» и переходить на более тяжеловестный или другие по структуре процессы, и, в том числе, — доказывать, что вы знаете на какие процессы переходить и когда.
Яндекс заблокировал конкретные действия — вне зависимости от того, открыты исходники инструмента или нет.
А автор пытается выдать это в плоскость борьбы с опенсорсом.
Или у автора есть примеры того, что яндекс разрешает автоматическую синхронизацию проприетарным утилитам? (свои клиенты яндекс-диска не в счет, по понятным причинам).
К яндексу, конечно, есть вопросы, но того характера что «вы в своем праве, но вы делаете не удобно вашим фанатам. Не даете автоматический бакап на яндекс диск — ок, но предложите путь как это делать по другому — тариф другой, или другой сервис?...»
Но и искажать ситуацию в статье, пытаться выдавать одно (ограничение нагрузки на свои сервисы) за другое (обвинять яндекс в нелюбви к опенсорс) — ради красного словца и хайпа — это же тоже не дело?
основное его «достоинство» — это «поднимать в воздух клубами ту самую пыль, которую он должен был бы собирать» )
побить этот рекорд бесполезности сможет только, DIY-щик, сделавший пылесос, который
будет вредитьбудет производить пыль ;)ссылочку Доктору Дью уже отослал кто-нибудь? :)
скажем так, Java — тоже сейчас опенсорс.
но можно заказать официальную коммерческую поддержку. а в связи с обновлениями лицензий оракла — еще, и обязаны, если у вас не openJDK.
я то вот как раз, (вроде) проработал в своё время, и выбираю как правило совсем не питон. и не советую питон в иных ролях кроме как скриптование мелких одноразовых задач. но некоторые заказчики находятся в таком диком убеждении что на питоне можно всё и вся, и для всего пригодно, так свято верят,… что я подумал — «может я что забыл ?»…
всё лучше, чем те безобразия как у js или руби )))
и кажется же, что были разговоры про введение статической типизации?.. писал на питоне совсем давно, еще когда только третий был в самую новинку. подумал, может что изменилось. хотя бы методически — описание, стандарт внятный как у js например может появился… <_<
или может питоновцы что то «действительно новое придумали» в плане как быть с большими задачами и рефакторингом…
но, похоже, что принципиально пока ничего не изменилось. вопрос с позиционированием питона на ближайшее время, как минимум для меня, снова закрыт.
спасибо за диалог.
опять же вспомню про создателей node.js, которые (честь и хвала им) осознали это достаточно быстро, и пересаживают всех на typescript. но, имхо, им этого тоже не надолго хватит, потому что «та же многопоточность», от которой никуда не деться, но которую нельзя впилить внятно в это «дитя js». потому js — нет, не подходит для сложных систем.
что, лямбда-выражения, которые даже в джаву воткнули, повысили скорость обработки транзакций? нет.
а переход на юникод понизил расход ресурсов? опять же, утрируя — нет.
а «про юникод» бизнес вас вообще спросит: а почему вы сразу так не сделали? а когда вы разведете руками — запишет в графе «минусы»: "принимали необдуманные рещения, теперь просят с нас денег на
перевод системы на вовую версию питонаисправление своих ошибок в прошлом".понимаете? во главе угла не эволюция ))) во главе угла сохранение работоспособности и минимизация расходов.
в этой фразе нет проработки рисков.
бизнес не может (вернее здравомыслящий бизнес не будет) сидеть на неподдерживаемой версии языка/системы, потому что в этом случае, все риски и ответственность связанные с ошибками в платформе/sdk/языке и убытками в следствии этих убытков — лягут на плечи подразделений этого самого бизнеса. а это никому из здравомыслящих менеджеров не надо — никто не хочет быть «виноватым без вины».
потому они будут «страховать свои риски» — если есть деньги, покупая техподдержку и перекладывать таким образом ответсенность за косяки в коде на плечи производителя.
но! повторюсь, что переход на новые версии языка, с целью сохранения поддержки — может быть крайне дорогостоящим предприятием в случае поломки совместимости. в итоге, такую постоянную гонку с переходом на новые версии можно похволить себе только для небольших систем.
вы продолжаете мыслить не теми категориями.
«бизнесу» — глубоко все равно какие там функции в языке.
никто не говорит про халяву. но затраты бывают разные
есть одна стоимость техподдержки, она линейна от времени.
и есть другая стоимость — стоимость по переработке системы на новую версию платформы/языка. и это требуется выполнить что бы иметь возмодность заплатить за первое. и эта стоимость растет нелинейно от объема кода.
а новые фичи языка — бизнусу побоку. не нужно ему это.
ему нужны функции в производственной системе.
имхо, самый большой риск бизнеса связанный с it: это остаться в ситуации, когда производитель больше не оказывает услуг по техподдержке старых версий (не на кого переложить ответственность), а пересаживать систему на новую версию языка крайне затратно, потому что они вкладывались в разработку системы последние лет 5, и они стала очень большой.
и я снова спрашиваю: может ли питон 3 предложить что либо для минимизации таких рисков кроме LTS ( который, как было описано выше — не очень сильно помогает на большом сроке )?
с выделение байта в тип — мне прокомметировать сложнее ( не так хорошо знаю питон) но опять же в джаве вспоминается трюк с boxing-unboxing для простых и объектных типов.
согласен, проще — плюнуть на старый механизм, чем придумать как это должно работать совместно.
но поймите, что именно такое «наплевательство» делает питон не выгодным «для бизнеса» с точки зрения длительных инвестиций и разработки больших систем.
и, увы, имхо, то что вы восхваляете как правильное и хорошее в 3м питоне — это, хотя и действитеьно (верю вам) правильное и хорошее, но это прямое следствие необдуманных решений при создании первоначального стандарта языка; а ситуацию из топика — мы имеем в виду «наплевателского» стиля при введении новых фич. имхо.
хотя, иногда такое наверное и надо делать. если вспомнить преход с Qt3 на Qt4 — это было действительно правильно. троллтечю пока еще были троллтечами, вообще с нуля переписали весь апи, получилось очень стройно, удобно и красиво. но, ВАЖНО, что у систем на базе C++/Qt и срок жизни куда менее чем 5-10 лет. ни о какой долгосрочности или громадности систем речи нет.
бизнесу глубоко положительно и на «прогресс языка» и на неудачную архитектуру — как минимум, пока код работает и делает то что должен и не требует к себе лишнего внимания. потому, что работающий код — это хорошо вложенные деньги, дающие отдачу и экономию.
вы ставите во главу угла некий «проресс», кстати не детализаруя что это конкретно значит, а бизнес задается вопросом: «а сколько денег будет стоить этот прогресс» и «кто конкретно за это будет платить»?
мы можем и должны развивать экспериментальные языки для новых изучения новых возможностей, архитектуры, но для долговременных больших, промышленных проектов надо нечто совершенное иное. и экспериментальные языки не должны выбираться для разработки больших систем.
— Обратную совместимость поддерживать, имхо, можно, достаточно долго, сильно больше чем любая LTS; хотя и при соблюдении ряда условий:
1. во перых требуется автомтический контроль за этой совместимостью (читай автоматические тесты валидности интерпритаторов/компиляторов под каждую версию). иначе как эту совместимость действительтно проверять?
2. требуется полное описание спецификации языка, работы интерпретатора, включая исключения под работу старых стандартов. полная спека, достаточная для того, что бы написать тестф из пункта 1 и провести валидацию стороннего интерпретатора. пункт 1 будет гарантировать что новая спека не ломает работу старой.
не к ночи будет сказано, но у джавы и джаваскрипта такие спеки есть.
и есть альтернативные реализации, и процессы валидации/тестирования/проверки сторонних интерпритаторов тоже есть. и джава и а 13й версии продолжает поддерживать работоспособность версии 1.
у питона есть такое? а когда появится?
есть альтернативные реализации, совместимые с исходным стандартом?
3. требуется вдумчивое отношение к нововведениям, и аккуратное прописывание стандарта новой версии. не на поводу у модно-хипстеров, а с учетом действительной необходимости. опять же, не к ночи будет упомянута джава. что там с js в этой частию мне сказать сложнее, я не отслеживал развитие js в деталях.
— вот я и спрашиваю: питон 3 — это всё еще экспериментальный язык, для небольших систем со сроком жизни полгода-год, «с новыми фичами» и с «правильной по последнему слову архитектурой», которая целенаправленно и осознанно ломает обратную совместимость ради новых фич…
или это уже язык, претендуюший на звание «промышленный язык» — язык, в разработку кода на котором бизнес может вкладываться на горизонте более 5-10 лет, не боясь, что в какойто момент, все то, что было создано перестанет работать, потому что версия языка перестанет поддерживаться?
это не к рассуждениям плохо-хорошо.
это к позиционированию, и осознанию места и ниши языка, границ его применимости, внушения толпам молодых красноглазых неофитов/фанатиков правильного понимания о том, «где это можно применять».
мне, например, очень нравится идея когда питон применяют математики для расчетов и скриптования повседневных ad-hoc задач. вплоть до того, что я подумывал ввести скриптование на питоне в одной из систем.
допускаю изучение питона как учебного языка (на замену паскалю),
но меня, же вот буквально подташнивает от попыток и заявлений неофитов создать на этом языке что-то действительно большое, с претензией на долгосрочность. потому что я раз за разом, не первый год, вижу чем кончаются такого рода попытки, и как быстро проходит мода на «очередной заменитель джавы», (опять, простите, «не к ночи будет сказано»).
питон 3 готов стать чем то иным?
Я как раз и говорю, что новые фичи вобще являются несущественным фактором для промышленного языка. Существенным является что бы поведение системы не менялось при переводе ее на новый интерпретатор/компилятор/платформу, и не требовалось менять код для такого перевода.
Более того, я считаю, что проблема EOL средств разработки для больших систем гарантированно наступает. (какой бы не был LTS длительным — он кончится).
И _единственный_ путь по предотвращению проблемы окончания EOL — это обеспечение обратной соместимости между версиями языка, когда новая версия пусть и добавляет новвые фичи, но гарантирвоанно не меняет поведение старого кода.
Вот я и пытаюсь узнать — что делается создателями питона 3, что бы помочь избежать проблем связанных с EOL?