Oracle тихо разшири платената поддръжка и надстройките за Solaris 11.4 до 2037 – три години след предишния краен срок – и направи същото за по-ранните версии на операционната система миналата година.

Solaris е патентован Unix, който Oracle придоби заедно със Sun Microsystems през 2010 г. Съчетана със собствения SPARC силикон на Sun, операционната система беше необичайно мащабируема и надеждна опция в своето време и ранното внимание на Sun към технологиите в уеб мащаб я направи обичаен избор за уеб 1.0 играчи.

Но по времето, когато Oracle придоби Sun, Solaris беше на път да се превърне в наследена технология. И през 2018 г. Oracle почти потвърди това състояние, като спря разработката на основен ъпгрейд и замрази операционната система на версия 11.4, плюс непрекъснати корекции и актуализации на пакети.

Признавайки, че Solaris е вид комплект, който е в основата на критични за мисията приложения, които могат да работят десетилетия, Oracle обеща да предложи постоянна поддръжка и непрекъснати актуализации за Solaris и в бъдеще – но без допълнителни издания на Big Bang.

Big Red предлага три вида поддръжка:

• Premier – Поддръжка на хардуер и интегриран софтуер на Oracle Sun, като фърмуер.
• Разширено – Платена поддръжка и надстройки за Oracle Solaris и Oracle Linux.
• Поддържане – Неограничен достъп до инструменти за поддръжка и пачове на Oracle, плюс „помощ от експерти по техническа поддръжка“ за тези, които желаят да платят.

Solaris 11.4 беше под Premier поддръжка до 2031 г., разширена поддръжка до 2034 г., а Oracle обеща поддържаща поддръжка за неопределен период от време.

Но миналата седмица Oracle тихо се отказа от актуализация на своята политика за поддръжка през целия живот [PDF], която гласи, че разширената поддръжка за Solaris 11.4 ще продължи до 2037 г. Датата за 2031 г. за прекратяване на Premier Support остава същата.

През 2023 г. Oracle добави още три години разширена поддръжка към Solaris 10 и Solaris 11.3, като и двете вече ще влязат в сферата на поддържащата поддръжка през 2027 г. вместо през 2024 г.

Тези разширения не трябва да се приемат като знак за ентусиазъм за Solaris. Oracle продължава да насърчава миграцията на приложенията на Solaris към версия 11.4 и се опита да направи тези усилия по-лесни, като опакова операционната система в удобни за разработчици форми.

Но очевидно все още има потребители на Solaris, които виждат операционната система като голяма част от своето бъдеще и са готови да платят за тази привилегия. Oracle със сигурност не е благотворителна организация и не би разширила подкрепата си, ако това не беше печелившо. ®

CockroachDB пусна своята итерация 23.2, съдържаща нови функции, предназначени да изкушат потребителите на мейнфрейм и други наследени бази данни да прехвърлят работните натоварвания към своята разпределена облачна система.

В новата версия компанията за база данни като услуга, чиито клиенти включват Comcast, аудио компанията Bose и козметичната фирма Lush , каза, че е преустроила съхранените процедури, за да бъдат значително по-мощни.

Съхранените процедури са подпрограми на базата данни, предоставени на приложенията. Те обикновено се използват за контрол на достъпа, например в утвърдени корпоративни системи за бази данни като Oracle и Db2 на IBM.

Нейт Стюарт, главен продуктов директор на Cockroach Labs, каза, че работата по съхранените процедури е част от плана на компанията за осигуряване на по-добра поддръжка за проекти, включващи миграция на корпоративни работни натоварвания, вместо да се фокусира върху внедрявания на зелено.

CockroachDB е кабелно съвместим с PostgreSQL и има за цел да подобри своята съвместимост с течение на времето. Новата им реализация, PL/pgSQL за съхранени процедури, използва машината за разпределено изпълнение, така че потребителите да могат да обработват големи количества транзакционни данни паралелно, каза компанията.

„Съхранените процедури бяха интересна тема в Cockroach, защото първоначално бяхме склонни да се съсредоточим малко повече върху приложенията на зелено. Когато погледнахме новите работни натоварвания от този обектив, не видяхме нови приложения да се изграждат със запомнени процедури, защото ако щяхме да добавим логика на приложението, ще ги поставим в микроуслуга: можем да я отделим от базата данни“, каза Стюарт пред The Register .

Въпреки това, тъй като лабораториите на Cockroach започнаха да виждат клиентите да мигрират критични работни натоварвания като плащания, управление на инвентара и управление на достъпа, мисленето започна да се променя.

Въпреки че Стюарт посочи IBM Db2 като база данни, която може да доведе до преместване на някои работни натоварвания към CockroachDB, той бързо подчерта, че „мейнфреймът няма да отиде никъде“.

По-добрата поддръжка за съхранени процедури е в списъка за пазаруване за PostgreSQL, базата данни с отворен код, с която CockroachDB е съвместим по кабел.

Професорът по компютърни науки от Масачузетския технологичен институт Майкъл Стоунбрейкър, който за първи път предложи Postgres през 1986 г., описа как студент от Станфорд проведе проучване сред разработчици и откри в обратната връзка, че препъни точките включват липса на дебъгер, без версии, без тестова среда, липса на стандарти, и липса на езикова поддръжка.

„Потребителски дефинираните функции и съхранените процедури са мъка, за да стигнете до производство, защото при разработката и отстраняването на грешки те са наистина болезнени. Така че, моля, моля, моля PostgreSQL: можете да поправите инструментите за дефинирани от потребителя функции и съхранени процедури. Можете да внедрите дебъгер, не е толкова трудно“, каза той на конференцията на Postgres Vision през 2022 г.

В допълнение към съхранените процедури, Cockroach Labs обяви така наречената програма за мигриране на наследени технологии или MOLT, която обещава гъвкави опции за движение на данни, съобразени с различни приложения и бизнес изисквания, и физическа репликация на клъстер, предназначена за организации, изградени около два центъра за данни без достъп до трети локален или облачен регион. ®

Линус Торвалдс написа една от най-силно формулираните си публикации в пощенския списък за ядрото на Linux от години, нападайки сътрудник от Google за неговите предложения относно файловите системи.

Предметът на гнева на Торвалдс са inodes, всеки от които, както Red Hat казва, е „уникален идентификатор за конкретна част от метаданни в дадена файлова система“.

Inodes бяха обект на дебат в пощенския списък на ядрото на Linux през последните няколко седмици, като служителите на Google Стивън Ростед и Торвалдс участваха в някои солидни обмени по въпроса. В тема, озаглавена „Нека всички inodes за файлове и директории да бъдат еднакви“, плакати отбелязаха, че inodes може все още да имат роля, когато използват tar за архивиране на файлове. Торвалдс контрира , че inodes са си изкарали деня.

„Да, номерата на inode бяха специални и зад това стои история. Но по същество трябва да се опитаме много да се отдалечим от тази счупена история“, пише той. „Номерът на inode просто вече не е уникален дескриптор. Не живеем през 70-те години и файловите системи са се променили.“

Но дебатът относно inodes продължи. Rostedt в крайна сметка предложи всички inodes да имат уникални номера.

Отговорът на Торвалдс използва език и тон, които рядко се срещат през последните години.

Припомнете си, че през 2018 г. той обяви решение да си вземе почивка и да потърси помощ, след като се извини за това, което той описа като „лекомислени атаки в имейли“ към колеги Linux програмисти и сътрудници на проекти, които той призна, че са „както непрофесионални, така и ненужни. Особено в моменти, когато Направих го лично… Сега знам, че това не беше наред и наистина съжалявам.“

Разкаянието на Торвалдс дойде отчасти, защото пощенският списък на ядрото на Linux всъщност е работно място за много сътрудници. Злоупотребяващите публикации не създават щастливо работно място. И като се има предвид, че Linux разчита на доброволци, сътрудници и поддържащи, неприятната среда на работното място има потенциал да навреди на проекта.

В отговор на предложението на Rostedt за уникалните номера на inode, Торвалдс отвори: „Спрете да правите нещата по-сложни, отколкото трябва да бъдат.“

Тогава той малко се развика.

„И, по дяволите, СПРЕТЕ ДА КОПИРАТЕ ФУНКЦИИТЕ НА VFS СЛОЯ. Беше лоша идея миналия път, ужасно лоша идея е и този път. Не приемам този вид глупости.“

Основната критика на Торвалдс към подхода на Ростед е, че разработчикът на Google не е разбрал напълно темата – което Ростед по-късно признава.

Дотогава обаче Торвалдс го пламна по следния начин:

Дебатът продължи известно време, в по-хладен тон, като Торвалдс предложи предложения за това какво според него би бил по-добър подход към проблемите, които Rostedt се надяваше да адресира. Императорът на пингвините написа, че не възнамерява да се занимава веднага с въпроса, тъй като „загубих достатъчно време за това и съм много изостанал с другите си отговорности, така че това не е нещо, върху което мога да работя сега“.

Отговорът на Rostedt предлага следното – може би насочено – наблюдение:

В неделя Торвалдс публикува по-щастливи неща: дебютът на версия 6.8-rc2 на ядрото на Linux.

Торвалдс отбеляза, че rc1 включва „бъг в графика на amdgpu, който може да причини зависнал работен плот (което *в крайна сметка* ще се възстанови, но след достатъчно дълго изчакване, че повечето хора вероятно ще рестартират вместо това.“

„Този изглежда е ударил доста хора.“

Самият Торвалдс беше обезпокоен от грешка в btrfs, която за щастие не влезе в rc1, както беше забелязано преди пускането.

„Както и да е, надявам се, че с rc2 сега сме в по-стабилната част от цикъла на издаване, като тези проблеми, които могат да засегнат много тестери, са подредени. Така че се надяваме, че корекциите ще бъдат по-фини и няма да засегнат често срещаните основни настройки“, написа той.

„Така че излезте и тествайте. Сега е безопасно. Имате ми доверие, нали?“

Разбира се – ако въпросът е само за разработване на ядро. ®

Доставчикът на ексклузивен софтуер за архивиране Veeam прави ранно проучване на алтернативата на VMware Proxmox, потенциално с оглед на създаването на продукт за защита на данните, създадени с помощта на инструмента.

„Ние проучваме и правим някои прототипи около Proxmox, за да видим какво е възможно там, що се отнася до архивирането“, публикува Антон Гостев, старши специалист на Veeam за управление на продукти на 11 януари.

Друг продуктов мениджър на Veeam, Фабиан Кеслер, миналата седмица потвърди това усилие, като написа „Proxmox е нещо, върху което правим ранни изследвания“.

Публикацията на Kessler дойде в тема във форумите на Veeam, озаглавена „Провал на Broadcom/VMware“, в която потребителите на Veeam разказаха за действията на Broadcom, като ефективно повишаване на цените за продуктите на VMware и дисквалифициране на някои партньори на VMware.

„Някой партньор на VMware тук мисли да премине към друг хипервайзор след провала на Broadcom? И може би да проучи също решения за архивиране на трети страни, които се преместват от Veeam?“ поставя началната публикация в темата.

Темата включва обсъждане на алтернативи на VMware. В хода на дискусията Гостев предложи следните съвети и новини:

Купувачите на интелигентни технологии знаят, че продуктите са жизнеспособни само когато са заобиколени от екосистема от допълващи се инструменти – и като се има предвид, че архивирането е съществено допълнение към всяка инфраструктура или приложение, знаейки, че Oracle Linux KVM и Proxmox са в полезрението на Veeam, улеснява обмислянето и двете като алтернативи на VMware.

Broadcom също знае това. И знае, че ако основен доставчик като Veeam популяризира стоките си като улесняващи работата на VMware, повече може да изберат да потърсят алтернативен инструмент за виртуализация на сървъри.

Дали Broadcom се интересува от това да се случи е въпросът за 61 милиарда долара – придобиващата организация обеща да увеличи бързо печалбите, генерирани от VMware. Загубата на клиенти би направила това по-трудно, независимо че Broadcom предпочита да се фокусира върху големите купувачи. ®

Кой аз ли? Поздрави и поздрави, могъщи читателю, и добре дошъл отново в Кой, аз? в който читатели на Register като вас споделят истории за моментите, когато усилията ви да предоставите техническа поддръжка са се провалили.

Тази седмица се срещнете с читател, когото ще преименуваме като „Тоби“, който някога е работил като маркетинг консултант и технолог – доста комбинация – за агенция за дигитален маркетинг. По принцип, както той казва, „всичко, което включваше код, падна в скута ми.“

Един прекрасен ден клиент се обърна към тази агенция, търсейки актуализация на нейната CRM система. Съществуващата CRM беше „ужасяваща“ според Тоби: „нямаше проверка на входа и беше изцяло локална и можеше да работи само на един единствен компютър.“

Ергх Очевидно беше необходима актуализация.

За да направи нещата още по-забавни, клиентът искаше нов уебсайт едновременно със своя лъскав нов CRM, с допълнителното изискване контактите в CRM да се синхронизират с потребителските акаунти на уебсайта и обратно. Само по себе си не беше твърде сложно, но уебсайтът се обработваше от външна агенция, която беше в различна часова зона от агенцията на Тоби.

Създаденото решение беше да се изпращат уебкукички от сайта с помощта на WordPress плъгин към CRM всеки път, когато нещо се актуализира. След това CRM ще направи същото, обратно към сайта, използвайки Zoho Flow.

На теория звучеше добре. При първоначалното тестване се държеше според очакванията, така че всичко беше наред. Данните бяха качени според очакванията, изпратени бяха уеб кукички, данните бяха актуализирани от другата страна и всички бяха доволни.

И така, със задоволителна свършена работа за един ден, Тоби започна.

След това, разбира се, настъпи следващият ден, както беше обичайно. Когато Тоби се захвана за работа, той отвори имейла си и намери спешна заявка: „Някаква представа защо имаме около 500 заявки за актуализиране на потребител?“

Случи се, че Тоби нямаше представа. Но скоро намери такъв.

Оказа се, че докато Тоби спеше, уеб агенцията е извършила собствено тестване, като е качила полезен товар, за да актуализира даден потребител в CRM. CRM отговори, като актуализира потребителя и изпрати уеб кука обратно към сайта, който отговори, като изпрати друг полезен товар към CRM. CRM отговори, като актуализира потребителя и изпрати още уеб кукички … и така нататък до безкрайност .

Или не съвсем ad infinitum . По-скоро като реклама до изчерпване на кредитите на Zoho на агенцията . И когато те се изчерпаха, уебкукичките спряха и всичко спря. Проектът беше ефективно осакатен от самопричинен DDoS.

Тоби неразумно бе предположил, че уеб агенцията разполага с предпазни мерки, за да предотврати този вид рекурсия. Агенцията беше неразумно предположила, че Тоби ще вгради такива предпазни мерки. Тъй като всички знаем клишето за това какво се случва, когато предполагате, няма да го повтаряме тук. Достатъчно е да се каже, че всички бяха задници.

Най-лошото беше, че абонаментът за Zoho за агенцията на Тоби беше подновен само преди няколко дни и тази малка глупост беше изразходвала цялата сума за месеца. Нещо повече, този клиент далеч не беше единственото нещо, за което агенцията разчиташе на Zoho. Така че липсата на комуникация между агенциите не създаде голям проблем за клиента (все пак системата все още беше в процес на тестване), но имаше голямо въздействие върху работодателя на Тоби.

Някога попадали ли сте в средата на бъркотия, която можеше да бъде избегната, ако само някой беше казал нещо? Е, не го пазете за себе си, съобщете го на Кой, Аз? и ние ще споделим вашия предметен урок с други, така че те да избегнат същата съдба. И се засмя. ®

Миналата седмица Huawei представи подробно голямо издание на своята HarmonyOS, което ще накара китайския гигант да скъса с екосистемата на Linux.

HarmonyOS стартира през 2019 г. – първоначално като операционна система за IoT устройства, но по-късно адаптирана да работи на смартфони и друг хардуер. Huawei предположи, че операционната система може да работи на нейните преносими устройства, таблетни компютри, смартфони и смарт телевизори и да предлага унифицирано изживяване във всички.

Това много прилича на нещо, което Google може да достави с Android, с който HarmonyOS беше съвместим.

Но между геополитическите трудности на трансграничния трансфер на технологии и желанието да се изгради възможно най-доброто предложение, до 2023 г. Huawei посочи, че ще изгради версия на HarmonyOS, която скъса с екосистемата на Android – дори това да означава болка за разработчиците и потребителите .

Миналата седмица Huawei пусна това предложение без Android: HarmonyOS Next. И твърди, че също е създал ядрото, за да го захранва – което означава, че Huawei се е развел както от Android, така и от Linux. Изпълнителите твърдят, че ядрото превъзхожда Linux по някои показатели, включително ефективност на паметта.

Потребителите бяха подразнени с трейлър видео , което показва как изглежда потребителски интерфейс, който е взаимствал много от iOS и основни версии на Android от Samsung и Oppo.

Huawei обеща HarmonyOS Next да дебютира за потребителите през четвъртото тримесечие на 2024 г. и че дотогава ще са обучени милиони разработчици и ще са осигурени хиляди собствени приложения, които да работят на операционната система. Версия за разработчици е обещана за скорошно пускане.

В сесии за разработчици Huawei подробно описа вътрешностите на операционната система и как ще се достави с всички основни приложения и услуги, които потребителите ще очакват – неща като карти, управление на снимки и калкулатор – и инструментите за разработчици, които създава.

Huawei също така разработи „отворена“ версия на HarmonyOS Next – вероятно с надеждата, че трети страни могат да обмислят операционната система за захранване на техните собствени устройства.

Стремежът на разработчиците и възможното приемане на HarmonyOS Next от OEM са толкова важни, колкото и самият софтуер. Ако Huawei може да развие екосистема от играчи на трети страни, това може да създаде жизнеспособна алтернатива на дуопола Android/iOS.

Възродената гама смартфони на Huawei беше приветствана като патриотична алтернатива за китайските купувачи. И все пак дори няколкостотин милиона устройства на Huawei, работещи с HarmonyOS Next, не биха били значително предизвикателство за Apple и Google извън Китай.

Нито други китайски производители на телефони, които приемат операционната система, непременно биха направили разлика. Спомнете си, че Microsoft се свърза с компании като HTC, LG и Samsung за създаване на телефони с Windows Phone, но не успя да пробие пазара. Само Samsung остава сила на пазара на мобилни телефони – и той е ол-ин за Android.

Huawei има едно огромно предимство: правителството на Китай е на негова страна и вече даде да се разбере, че предпочита държавните служители да не използват iOS за официален бизнес. Ако правителствата на Китай изразят предпочитание към HarmonyOS, платформата може да се превърне в де факто стандарт зад Голямата защитна стена. ®