Через відвідуваність мого старого блогу http://nerusoft.blogspot.com/ я вирішив дублювати там повідомлення з нового блогу.
Додатковим мотивом було збереження матеріалів: під час попереднього збою сервера безповоротно втрачено чимало дописів. У початковій нотатці подію віднесено до попереднього року без докладної дати.
Дублювання публікацій тоді здавалося корисним додатковим способом збереження, але воно не замінює повної резервної копії та перевірки відновлення.
Через відвідуваність мого старого блогу http://nerusoft.blogspot.com/ я вирішив дублювати там повідомлення з нового блогу.
Додатковим мотивом було збереження матеріалів: під час попереднього збою сервера безповоротно втрачено чимало дописів. У початковій нотатці подію віднесено до попереднього року без докладної дати.
Дублювання публікацій тоді здавалося корисним додатковим способом збереження, але воно не замінює повної резервної копії та перевірки відновлення.
У різні періоди для проєктів і публікацій ми створювали кілька сайтів. У цій нотатці збережено їхній тодішній перелік:
http://corp2.net — сайт системи «Корпорація 2».http://nerusoft.com — старий корпоративний сайт.http://rudjuk.kiev.ua — персональна сторінка Сергія Рудюка, один із найстаріших наших сайтів.http://i1.kiev.ua — добірка сайтів.http://users.iptelecom.net.ua/~3r/ — давній сайт на майданчику Iptelecom.http://nerusoft.blogspot.com/ — блог розробника.http://rsa.ms — сайт торгової марки RS.Це історія вебресурсів, а не підтвердження поточної належності, доступності або вмісту кожної адреси. Для звернень щодо K2: WhatsApp +380679016322.
У лютому 2009 року я опублікував перелік параметрів, які тоді обговорювали в контексті пошукової оптимізації. Він добре відображає тогочасний підхід: багато уваги приділяли підрахунку ключових слів, обсягу сторінок і формальним ознакам оформлення.
Нижче збережено зміст цього переліку, згрупований за темами. Це історичні припущення про роботу пошуку, а не підтверджена формула ранжування всіх пошукових систем.
Варто розділяти доступність для сканування, індексування та показ у результатах. Google описує ці етапи в офіційній довідці про роботу пошуку. Технічна ознака сторінки не обов'язково є окремим сигналом ранжування.
У посібнику Google Search Central прямо зазначено: meta keywords не використовується, а надмірне повторення ключових слів порушує правила щодо спаму. Підрахунок слів і кількість сторінок самі собою не утворюють рецепта високих позицій.
Практичний початок роботи — корисний зміст, зрозуміла структура, доступні сторінки, змістовні заголовки, посилання та описи зображень. Старий перелік допомагає побачити еволюцію SEO, але для поточних рішень потрібна документація конкретної пошукової системи.
У первісній нотатці був такий перелік поштових серверів Google:
ASPMX.L.GOOGLE.COM.
ALT2.ASPMX.L.GOOGLE.COM.
ALT1.ASPMX.L.GOOGLE.COM.
ASPMX4.GOOGLEMAIL.COM.
ASPMX5.GOOGLEMAIL.COM.
ASPMX2.GOOGLEMAIL.COM.
ASPMX3.GOOGLEMAIL.COM.Числових пріоритетів у джерелі немає, тому порядок рядків не можна вважати готовою конфігурацією DNS. Перелік залишено для історії.
Поточна офіційна інструкція Google Workspace наводить значення smtp.google.com із пріоритетом 1; для доменів зі старими налаштуваннями можуть використовуватися інші записи. Перед зміною перевірте інструкцію саме для вашого сценарію та чинні записи домену.
Для доменів зі старими MX-записами типу aspmx Google прямо зазначає: якщо пошта працює, змінювати ці записи не потрібно.
У старій нотатці я порівнював доступні моєму домену 1500 облікових записів Google-пошти з лімітом 50 для нових доменів, який тоді спостерігав. Наводилася квота 7,2 ГБ на скриньку.
Арифметично це давало 1500 × 7,2 = 10 800 ГБ, або 10,8 ТБ у десятковому поданні, і 50 × 7,2 = 360 ГБ. Проте сума індивідуальних квот не означає автоматично спільний простір, який можна довільно розподіляти між користувачами.
Різниця здавалася мені великою, хоча я вважав, що й меншого ліміту здебільшого мало вистачати. Це була особиста оцінка, а не результат дослідження потреб користувачів.
Ці числа збережено як опис умов того часу зі слів автора. Точну редакцію сервісу й правила для домену не зафіксовано, а твердження про достатність «у 99,9% випадків» не було підкріплено даними. Нотатка не описує поточних квот або тарифів Google Workspace: їх потрібно звіряти для конкретної підписки.
У старій нотатці я порівнював доступні моєму домену 1500 облікових записів Google-пошти з лімітом 50 для нових доменів, який тоді спостерігав. Наводилася квота 7,2 ГБ на скриньку.
Арифметично це давало 1500 × 7,2 = 10 800 ГБ, або 10,8 ТБ у десятковому поданні, і 50 × 7,2 = 360 ГБ. Проте сума індивідуальних квот не означає автоматично спільний простір, який можна довільно розподіляти між користувачами.
Різниця здавалася мені великою, хоча я вважав, що й меншого ліміту здебільшого мало вистачати. Це була особиста оцінка, а не результат дослідження потреб користувачів.
Ці числа збережено як опис умов того часу зі слів автора. Точну редакцію сервісу й правила для домену не зафіксовано, а твердження про достатність «у 99,9% випадків» не було підкріплено даними. Нотатка не описує поточних квот або тарифів Google Workspace: їх потрібно звіряти для конкретної підписки.
У лютому 2009 року я бачив, як на тлі фінансової кризи слабшав попит на київські квартири. Рієлтори в публікаціях закликали купувати, поки є нагода. Я дивився на ситуацію інакше: за моїми тодішніми спостереженнями, ціни в оголошеннях знижувалися, а угод було мало. Я припускав, що спад триватиме щонайменше рік.
Мій прогноз на вересень–листопад 2009 року був таким: окремі трикімнатні квартири в Києві могли коштувати 30–50 тисяч доларів США, а одно- й двокімнатні — менше. Я виходив із того, що за слабкого попиту продавцям, яким потрібно завершити угоду швидко, доведеться орієнтуватися на суму, яку покупці готові заплатити.
Для перевірки такого прогнозу потрібні дані про завершені угоди за відповідний період. Ціни з оголошень і ціни продажу слід порівнювати окремо, враховуючи район, площу та стан квартири.
Ця архівна публікація анонсувала підготовку версії 1.0.3.0 програми «Розрахунок і проєктування шаф» як проміжного етапу переходу до «Корпорація 2».
Після переходу на «Корпорація 2» передбачалися:
Перелік описує тодішній план, а не перевірені функції випущеної версії чи сучасну сумісність. Поточні питання щодо K2: WhatsApp +380679016322.
На момент цієї публікації ми планували нові версії програм «Розрахунок і проєктування шаф», «Екзамен», «Реплікатор» та AutoFill і подальшу підтримку цих продуктів.
Довгостроковим задумом була інтеграція в «Корпорація 2», де окремі продукти мали працювати як плагіни.
Протягом наступного місяця планувався випуск нової версії «Корпорація» з адаптацією до актуальних тоді операційних систем і врахуванням змін меблевого виробництва після 2003 року.
Це повідомлення про наміри того часу, а не підтвердження строку релізу, поточної підтримки чи складу сучасних продуктів. K2 ERP — інформаційна система, K2 Platform — платформа розробки. Звернення щодо K2: WhatsApp +380679016322.
На нашому сервері закінчилося дискове місце, після чого почалися збої MySQL. Перевірка показала проблему в резервуванні: під час архівування до вхідних даних знову потрапляли результати попереднього копіювання.
Через це обсяг продовжував зростати, і доступного запасу близько 150 ГБ не вистачило. У початковому тексті це описувалося як заповнення «до нескінченності»; точніше говорити про повторне включення архівів, обмежене місткістю носія.
Практичний висновок із цього випадку — відокремлювати каталог резервних копій від джерел або явно виключати його, контролювати вільне місце, завершення завдання та правила зберігання. Після збою бази причину й стан даних потрібно перевіряти окремо; сама поява вільного місця ще не підтверджує їхню цілісність.
Ця нотатка зберігає стару процедуру створення власного центру сертифікації та сертифіката сервера через допоміжний скрипт OpenSSL CA.sh. Вона не є готовою конфігурацією для сучасної Ubuntu або Apache.
Цю процедуру опублікував Олександр Єлісеєнко на OpenNET 11 травня 2004 року. У своїй нотатці я зберіг такі команди:
cd /usr/local/ssl/misc
# Створення власного центру сертифікації
./CA.sh -newca
# Створення запиту сервера
./CA.sh -newreq
# Підписання запиту власним центром
./CA.sh -sign
# Команди копіювання з оригіналу — див. уточнення нижче
cp newreq.pem /usr/local/etc/apache/sslkey/server.key
cp newcert.pem /usr/local/etc/apache/ssl.crt/server.crtУ джерелі також зазначалося розповсюдження сертифіката центру ./demoCA/cacert.pem на клієнтські комп'ютери. Довіра до власного центру має встановлюватися свідомо й контрольовано: такий центр не стає загальнодовіреним лише через створення сертифіката.
Не можна автоматично вважати newreq.pem приватним ключем. Наприклад, у документованому CA.pl -newreq приватний ключ записується в newkey.pem, а запит — у newreq.pem. Поведінку конкретного старого CA.sh потрібно перевіряти за його версією та вмістом файлів перед налаштуванням Apache.
Для сучасного розгортання окремо перевіряють відповідність ключа сертифікату, імена хостів, строк дії, ланцюжок довіри й права на приватний ключ. Саме виконання архівних команд не підтверджує коректної конфігурації HTTPS.
Первісні адреси: http://www.opennet.ru/tips/info/681.shtml та http://www.opennet.ru/base/net/apache_mod_ssl.txt.html. Довідка для зіставлення: OpenSSL CA.pl.
Матеріал «Найпоширеніші схеми шахрайства» перенесено до тематичного блогу.
У початковому повідомленні зазначено адресу: pravdak.blogspot.com. Цей допис збережено як повідомлення про перенесення; самого тексту статті тут немає.
У лютому 2009 року мене зацікавила добірка у Вікіпедії про впровадження Ubuntu в державних установах, освіті та великих технологічних організаціях. Я й сам користувався Ubuntu та поступово переводив на неї свої комп'ютери.
У 2007 році Національні збори Франції вирішили використовувати Ubuntu на своїх робочих станціях. У січні 2008 року жандармерія оголосила поетапний перехід; у тодішніх планах ішлося про десятки тисяч комп'ютерів. Архівний кейс європейського порталу показує, що це був процес, який спирався на попереднє впровадження відкритих програм, а не одночасна заміна всіх систем.
У листопаді 2007 року Canonical повідомила про план понад 180 тисяч учнівських робочих місць з Edubuntu в тодішній Республіці Македонія. Йшлося про поєднання звичайних ПК та віртуальних терміналів, а не про 180 тисяч окремих системних блоків.
Первинна добірка згадувала також Грузію й Іспанію. Такі повідомлення потрібно читати в контексті окремих програм і дат, а не як твердження про всі школи країни. Для Іспанії пізніший кейс Canonical за березень 2010 року описує 220 тисяч робочих місць на основі Ubuntu в Андалусії. Це інший датований показник, ніж 400 тисяч із тодішньої загальної добірки.
Google справді використовувала внутрішній дистрибутив Goobuntu на основі Ubuntu LTS для корпоративних Linux-пристроїв. Це не означало, що всі системи Google працювали на ньому. У розповіді команди Google пояснено, що у 2018 році було завершено перехід на модель rolling release на основі Debian.
Згадка про сервери Вікіпедії також має історичне підґрунтя: кейс Canonical, опублікований у 2010 році, описує вибір Ubuntu для уніфікації серверного середовища Wikimedia. Це свідчення того етапу розвитку інфраструктури, а не її поточний опис.
Для мене ці приклади були аргументом уважніше випробовувати Ubuntu у власній роботі. Практичний перехід усе одно починається з перевірки потрібних програм, обладнання та процесів.
Уже втретє за короткий час я зіткнувся з проблемами роботи сторонніх ICQ-клієнтів. Тоді я пов’язував ці відключення зі змінами протоколу ICQ. Треба визнати: такі повторення вже починали набридати.
Версій клієнтів, журналів помилок та офіційного пояснення я не зберіг. Тому точно описати масштаб збою або підтвердити відключення всіх сторонніх програм за цим записом неможливо. Це моє спостереження за повторюваною проблемою в тодішньому робочому середовищі.
Зберіг собі посилання на добірку корисних прикладів Ajax і JavaScript на WebPHP.
http://webphp.ru/60-professionalnyx-ajax-i-javascript-reshenij/Це була коротка закладка: власного переліку бібліотек, версій чи прикладів коду я до неї не додавав. Перш ніж переносити рішення з цієї добірки у власний проєкт, потрібно перевірити його код, залежності та сумісність із потрібними браузерами.
Під час роботи з TortoiseSVN через SSH мене турбували повторні запити імені користувача та пароля. У старій нотатці пропонувалося відкрити TortoiseSVN → Settings → Network і вписати пароль безпосередньо в команду SSH-клієнта.
Це небажаний спосіб збереження секрету. Архівний рядок із заповнювачами виглядав так:
C:\Program Files\TortoiseSVN\bin\TortoisePlink.exe -l ПользовательВSSH -pw ПарольДляПользователяВSSHТут немає справжнього пароля, але в реальному налаштуванні параметр -pw зберігав би секрет у відкритому вигляді в командному рядку. Також шлях із пробілами має бути взятий у лапки:
"C:\Program Files\TortoiseSVN\bin\TortoisePlink.exe"Якщо TortoisePlink.exe встановлено в іншому каталозі, у полі SSH client потрібно вказати його фактичний повний шлях, а не копіювати наведений каталог.
Для уникнення повторного введення розгляньте автентифікацію SSH-ключем з агентом Pageant відповідно до політики доступу. Офіційна довідка TortoiseSVN описує поле SSH client, лапки в шляхах і використання Pageant.
Я вирішив відмовитися від інтернету Svitonline. Коли основний канал почав регулярно підводити, довелося працювати через резервний. Після цього я порівняв обидві лінії в роботі й зрозумів, що для мене важливіші стабільність, можливість підключити виділену IP-адресу та реакція підтримки, ніж заявлена швидкість.
Заявку щодо якості зв’язку я подав 25 січня. На початку лютого з’ясувалося, що її вже закрили, хоча проблема залишалася. Спочатку мені радили перезавантажити комп’ютер. Коли це не допомогло і я телефонував знову, підтримка поверталася до статусу заявки. Тим часом працювати все одно доводилося через резервний канал.
Для моєї роботи була потрібна виділена IP-адреса. На підключенні Svitonline я не зміг отримати цю послугу, тож налаштував її на резервній лінії, хоча там був ліміт трафіку. До того ж у моєму підключенні заявлена швидкість «100 Мб» на практиці іноді була нижчою, ніж на резервній лінії «Волі».
На той час за безлімітний пакет Svitonline я платив 200 грн. Серед пропозицій «Укртелекому», які я тоді розглядав, були пакети за 60–100 грн, достатні для моїх задач. У моїй роботі лінія «Укртелекому» виявилася стабільнішою.
Я порівнював, чи можна нормально працювати під час збоїв, чи доступна потрібна IP-адреса і чи підтримка перевіряє результат перед закриттям заявки. Резервний канал уже був у роботі, тому я міг порівняти підключення на тих самих задачах, перш ніж відмовитися від основного.
Тоді змінювалася і структура власності. Golden Telecom вказувала Svit-On-Line як свій бренд інтернет-доступу в Україні, а в лютому 2008 року VimpelCom повідомила про завершення угоди з Golden Telecom.
У старих браузерних конфігураціях для взаємодії з вбудованими Flash-об'єктами іноді був потрібен попередній клік активації. У первісній нотатці я шукав спосіб зручнішого вбудовування через SWFObject.
Цю поведінку IE не слід подавати як незмінну: у бюлетені Microsoft 2008 року вже повідомлялося про її заплановане усунення. Початкове пояснення через патент не відтворюється як перевірений юридичний висновок.
Для прозорого фону та вимкнення меню Flash у моєму тодішньому проєкті використовувався такий фрагмент:
<div id="flashcontent">
Этот текст будет заменен флэшкой.</div>
<script type="text/javascript">
var flashvars = false;
var params = {
wmode: "transparent",
menu: "false"
};
var attributes = {
id: "myDynamicContent",
name: "myDynamicContent"
};
swfobject.embedSWF("/bitrix/templates/ashato/images/guitar.swf", "flashcontent", "130", "133", "8.0.0",
"expressInstall.swf", flashvars, params, attributes);
</script>Код показано як текст, тому він не запускає скрипт чи Flash у статті. Збережені назви SWF-файлів, розміри, параметри й ідентифікатори належать до старого проєкту.
http://noregret.org/tutor/swfobject/http://www.flasher.ru/forum/showthread.php?p=794865http://code.google.com/p/swfobject/http://designformasters.info/posts/flash-embed-with-swfobject-2/Adobe припинила підтримку Flash Player 31 грудня 2020 року та заблокувала виконання Flash-контенту з 12 січня 2021 року. Тому цей приклад є історичним; для нової реалізації потрібні сучасні вебтехнології. Джерело: Adobe Flash Player EOL.
Ця пам'ятка описує внутрішні домовленості історичної версії «Корпорація 2 CMS». Файл corp_runner.php містив основні класи завантаження вебчастини. Правила нижче не є специфікацією сучасних K2 ERP чи K2 Platform.
У програмній частині тоді використовували Windows-1251, називаючи її «ANSI», а в базі даних — UTF-8. Документацію зберігали в UTF-8; файли перекладів — переважно у Windows-1251, за потреби в UTF-8.
Таке рішення автор пов'язував із проблемами сесій, невидимими символами після include/require та виведенням тексту в зображення. Проте з цього не випливає, що PHP загалом краще працює з «ANSI» або не підтримує UTF-8. PHP не задає єдиного кодування рядків; важлива узгодженість даних і функцій. Передчасний вивід також може порушити надсилання заголовків сесії — його слід діагностувати окремо.
Замість прямого виведення пропонувалося користуватися обгорткою; це не було обов'язковою вимогою:
$c->myecho('Текст');Для доступу до бази застосовували функції системи. Перетворення кодування в цій пам'ятці описано так:
$c->dc('Текст'); // з UTF-8 у поточне кодування
$c->ec('Текст'); // з поточного кодування в UTF-8Це контракт, наведений для тієї версії; фактичну реалізацію потрібно звіряти з її кодом. Коротке ім'я $c використовували замість $corp. Первинні ключі отримували через:
$c->myid();Словник передавали у вигляді асоціативного масиву:
$this->s(array(
"Идентификатор перевода 1" => "Перевод 1",
"Идентификатор перевода 2" => "Перевод 2",
"Идентификатор перевода 3" => "Перевод 3"
));Ідентифікатор перекладу виводили таким викликом:
$c->tr('Идентификатор перевода');У каталогах використовували файл desc для пояснення функціональності, а в компонентах — також каталоги документації. Потрібно було описувати роботу компонента, призначення функцій і змінних.
SQL виконували через обгортки системи:
$c->q('SQL-запрос'); // виконання запиту
$c->fetch($dataset); // отримання наступних даних із джерелаТочний результат і обробка помилок залежать від реалізації. Наявність обгортки сама по собі не підтверджує безпечного формування SQL.
Джерела технічних уточнень: рядки PHP, mbstring, headers_sent. Контакт щодо K2: WhatsApp +380679016322.
У розробці «Корпорація 2» програмісти могли змінювати основне ядро. Зміни вносили через систему контролю версій Subversion (SVN).
Для роботи з репозиторієм був потрібен клієнт SVN. Тим, хто працював у Windows, я пропонував TortoiseSVN.
У повідомленні була вказана така адреса репозиторію:
svn+ssh://corp2.net/d2/svn/corp2Для підключення я просив співробітників надіслати заявку на rs@rsa.ms і після цього мав видати ім’я користувача та пароль. Зазвичай ці реквізити збігалися з обліковими даними для SSH. Це опис порядку роботи команди на час публікації; поточну доступність цього репозиторію тут не підтверджено.
Схема svn+ssh використовує автентифікацію SSH і передає протокол Subversion через зашифроване SSH-з’єднання. Механізм описано у Version Control with Subversion.
Для звернень щодо K2: WhatsApp +380679016322.
У лютому 2009 року я звернув увагу на перехід від двозначних номерів екстрених служб до тризначних: 01 → 101, 02 → 102, 03 → 103, 04 → 104.
Початковий текст попереджав про майбутню зміну «через два тижні». Це стосувалося часу тієї публікації, а не нового переходу сьогодні.
Офіційна інформація МВС про Службу 112 пояснює можливість звернення за одним номером для координації потрібних служб. Перелік 101, 102, 103, 104 та 112 також наведено на офіційній сторінці контактів ДСНС. Довідку перевірено 2 листопада 2026 року.
Нещодавно мені трапився приклад меню, який захотілося зберегти. У ньому два сніданки, обід і кілька варіантів легких перекусів. Страви можна поєднувати по-різному, наприклад узяти до сніданку яйце, кисломолочний сир або квасолю.
Перед сніданком у добірці пропонували свіжі фрукти. На перший сніданок — свіжозварену цільнозернову кашу з нежирним молоком і фруктами. До неї можна додати цільнозерновий хліб або хліб із борошна грубого помелу з висівками. Серед варіантів також були варене яйце, кисломолочний сир чи страва з квасолі. З напоїв — трав’яний чай або кава без кофеїну.
Для перекусу перед другим сніданком у записі були томатний сік або йогурт зі свіжими фруктами без випічки. Сам другий сніданок можна скласти з хліба грубого помелу, свіжих овочів, салату або сочевичного супу. До них — кисломолочний чи твердий сир, нежирне м’ясо, риба або курка. На десерт — фрукти або сік.
Перед обідом у добірці були фрукти, горіхи або насіння. Для обіду пропонували великий салат із сезонних сирих овочів, нежирне м’ясо, рибу або курку. На гарнір — печена картопля, кукурудза в качанах чи бурий рис. Завершити обід можна свіжими фруктами.
На вечір у записі були свіжі фрукти, нежирне молоко або кисломолочні продукти. Це приклад поєднання страв. Кількість прийомів їжі й порції можна добирати за власними потребами. У сучасних рекомендаціях ВООЗ серед основних джерел вуглеводів також названо цільнозернові продукти, овочі, фрукти й бобові, а вживання фруктових соків радять обмежувати. Рекомендації ВООЗ щодо харчування.
Статтю перенесено до тематичного блогу: pravdak.blogspot.com.
У цьому записі збереглося лише повідомлення про перенесення. Посилання веде на головну сторінку тематичного блогу; повного тексту перенесеної статті тут немає.
У лютому 2009 року наш розрахунковий рахунок був у банку «Надра». Через тривалі труднощі з обслуговуванням я вирішив пошукати інший банк. На той час у «Надрах» уже діяла тимчасова адміністрація. У переліку НБУ початок її роботи датовано 10 лютого 2009 року. Архів «Вісника НБУ».
На той момент ПриватБанк здавався мені надійним вибором. Я вже користувався його послугами. Поруч було два відділення, тож я збирався звернутися до більшого. Умови для нашого рахунку видавалися зіставними з попереднім банком, а набір потрібних послуг був щонайменше таким самим. Окремим аргументом був інтернет-банкінг, який за умовами, що я тоді розглядав, був безоплатним.
Я працював у Linux, тож хотів розуміти, чи зможу користуватися банківськими сервісами зі свого комп’ютера. Мене зацікавило, що ПриватБанк і сам переводив робочі місця на Linux. У пізнішому технічному звіті команди ПриватБанку зазначено, що впровадження розпочалося у 2007 році.
Тоді я сподівався, що досвід банку з Linux полегшить роботу і його клієнтам. Внутрішнє впровадження давало привід перевірити сумісність, а можливість роботи з клієнтським сервісом залежала від вимог самого сервісу та браузера.
У лютому 2009 року я натрапив у блозі ПриватБанку на відповідь на запитання з відділення: чому на робочих місцях обрали Linux, що це дало крім економії і коли запрацюють проблемні сканери, фотоапарати, флешки та кириличні шрифти? Відповідь мені сподобалася прямотою. Вибір системи пояснювали повсякденною роботою банку. Коли основні операції виконуються у браузері, до настільної ОС можна висувати інші вимоги.
У збереженій дискусії пропонували порахувати вартість ліцензії на одне місце й помножити її на кількість комп’ютерів. Для ілюстрації наводили дві ціни одного нетбука ASUS Eee PC, з Linux і з Windows. Це був приклад із тогочасної розмови. Прайса магазину в дописі немає, тому за ним не можна встановити ціну конкретної комплектації або економію банку.
Сенс прикладу лишився. Якщо пристрій потрібен для роботи у браузері, спочатку треба визначити, за які можливості справді варто платити. Для порівняння двох варіантів до ціни ліцензій варто додати обслуговування комп’ютерів, сумісність обладнання, навчання й витрати на простої. Для відділення з десятком однакових ПК і для спеціалізованого контакт-центру результат може бути різним.
У дописі 2009 року головною умовою переходу назвали вебінтерфейси внутрішніх і зовнішніх сервісів. Вебзастосунок уже виконував операцію, а комп’ютер працівника забезпечував доступ до нього. Це зменшувало залежність від локальних програм і давало змогу зберегти звичну послідовність дій у відділенні.
У інтерв’ю від 16 жовтня 2013 року ІТ-директор ПриватБанку Дмитро Дубілет підтвердив цю послідовність. Банк спочатку перевів роботу на вебзастосунки, а Ubuntu згодом дозволила централізувати конфігурацію й підтримку робочих місць. Дубілет описав поступовий перехід і назвав єдиний керований образ PrivatLinux. Він також навів окремий приклад, де банк і далі купував ПЗ Microsoft, — контакт-центр.
Питання з відділення було дуже конкретним: як під’єднати периферію й добитися коректного відображення кирилиці? Вебінтерфейс не усуває залежності від драйверів, локальних шрифтів чи способу обміну файлами. У збереженій відповіді ці труднощі визнавали. У розмові 2009 року також згадували експерименти з Android для мобільних робочих місць і кіосків приймання готівки. POS-термінал був тодішньою ідеєю для наступного кроку.
Для подібного переходу я почав би з одного типового відділення. Нехай працівники пройдуть повну операцію: відкриють вебзастосунок, під’єднають потрібний пристрій, відсканують документ і перевірять, що результат читається та зберігається. Потім варто повторити тест після оновлення системи. Так видно, які робочі місця можна перевести одразу, а де спочатку потрібні драйвери, інші пристрої або окремий образ.
У форумному передруку були різні аргументи: банк сам розробляв операційні програми, для спільної роботи використовували вебінструменти, а як приклад роботи з документами автор відповіді наводив Writely, попередника Google Docs. Водночас він згадував, що вдома користувався Windows для ігор і був готовий за це платити. У тому ж тексті з повагою відгукувався про внесок Microsoft і книги Білла Ґейтса про цифрові організації.
Мені запам’ятався саме цей контраст. Технологію обирають під задачу, і керівнику варто розуміти, як команда працює та за що платить. Для банківського відділення важили керованість і робота у браузері. Для домашнього ігрового комп’ютера важив набір доступних ігор. Це дві різні задачі, і кожна має власні критерії вибору.
Ще цікавішою для мене виявилася статистика відвідувань нашого сайту за грудень 2008 року: у ній знайшлися і Macintosh, і різні дистрибутиви Linux, і мобільні операційні системи.
Це дані конкретного ресурсу й тодішнього засобу розпізнавання ОС. Відсотки в таблиці описують цю вибірку відвідувань.
| Операційна система / категорія | Кількість | У межах групи, % | Загальна частка, % |
|---|---|---|---|
| Microsoft Windows | 11793 | 100 | 98,38 |
| Microsoft Windows XP | 10452 | 88,63 | 87,19 |
| Microsoft Windows Vista | 1062 | 9,01 | 8,86 |
| Microsoft Windows Server 2003 | 118 | 1,00 | 0,98 |
| Microsoft Windows 2000 | 113 | 0,96 | 0,94 |
| Microsoft Windows 98 | 37 | 0,31 | 0,31 |
| Microsoft Windows CE | 6 | 0,05 | 0,05 |
| Microsoft Windows 95 | 3 | 0,03 | 0,03 |
| Microsoft Windows NT 4.0 | 1 | 0,01 | 0,01 |
| Microsoft Windows ME | 1 | 0,01 | 0,01 |
| Linux | 136 | 100 | 1,13 |
| Linux Ubuntu | 53 | 38,97 | 0,44 |
| Linux - невідома версія | 45 | 33,09 | 0,38 |
| Linux Mandriva | 13 | 9,56 | 0,11 |
| Linux Debian | 11 | 8,09 | 0,09 |
| Linux SUSE | 10 | 7,35 | 0,08 |
| Linux SeaMonkey | 2 | 1,47 | 0,02 |
| Linux Fedora | 2 | 1,47 | 0,02 |
| Macintosh | 39 | 100 | 0,33 |
| Macintosh | 39 | 100,00 | 0,33 |
| ОС мобільних пристроїв | 11 | 100 | 0,09 |
| Невідома ОС мобільного пристрою | 11 | 100,00 | 0,09 |
| xBSD | 5 | 100 | 0,04 |
| FreeBSD | 5 | 100,00 | 0,04 |
| Інші ОС | 3 | 100 | 0,03 |
| Symbian OS | 2 | 66,67 | 0,02 |
| Sun OS | 1 | 33,33 | 0,01 |
У звіті спочатку наведено підсумок групи, потім її складові; підсумок і підрядки не слід додавати вдруге. Показник кількості не дає підстав ототожнювати його з числом унікальних людей.
Отже, лічильник усе-таки враховував Macintosh: у грудневій таблиці його частка становила 0,33%. Це допомогло мені уточнити питання, що виникло під час перегляду іншої вибірки статистики ОС, де Macintosh не було видно.
Linux мав 1,13%, а Windows — 98,38%. Серед усіх зафіксованих відвідувань Windows XP становила 87,19%, Windows Vista — 8,86%.
Тоді я припускав: якщо Microsoft наполегливо просуватиме Vista замість звичної користувачам XP, частина людей може перейти на системи поза сімейством Windows. Такий розвиток подій здавався мені можливим, але сама таблиця показує лише розподіл відвідувань за грудень 2008 року.
«Linux SeaMonkey» — назва категорії у старому звіті. Сам SeaMonkey є пакетом інтернет-застосунків із браузером та поштовим клієнтом, а не окремим дистрибутивом Linux. Цей рядок варто читати з урахуванням того, як лічильник розпізнавав відвідування.
У лютому 2009 року я переглянув статистику відвідувань нашого сайту за операційними системами. Хотілося зрозуміти, чим користуються наші відвідувачі та чи приходить хтось із Linux і FreeBSD.
Точного інтервалу збору цих даних я не записав. Таблиця описує відвідування конкретного сайту; її відсотки не є частками світового ринку.
| Операційна система / категорія | Кількість | У межах групи, % | Загальна частка, % |
|---|---|---|---|
| Microsoft Windows | 441 | 100 | 98,22 |
| Microsoft Windows XP | 396 | 89,80 | 88,20 |
| Microsoft Windows Vista | 35 | 7,94 | 7,80 |
| Microsoft Windows 2000 | 5 | 1,13 | 1,11 |
| Microsoft Windows Server 2003 | 3 | 0,68 | 0,67 |
| Microsoft Windows 98 | 2 | 0,45 | 0,45 |
| Linux | 6 | 100 | 1,34 |
| Linux Ubuntu | 4 | 66,67 | 0,89 |
| Linux SUSE | 1 | 16,67 | 0,22 |
| Linux Mandriva | 1 | 16,67 | 0,22 |
| xBSD | 2 | 100 | 0,45 |
| FreeBSD | 2 | 100,00 | 0,45 |
У звіті спочатку наведено підсумок групи, потім її складові; підсумок і підрядки не слід додавати вдруге. Показник кількості не дає підстав ототожнювати його з числом унікальних людей.
Windows XP залишалася беззаперечним лідером, хоча Microsoft уже просувала Windows Vista. Водночас відвідування з Linux і FreeBSD були — нехай їхня частка й залишалася невеликою.
Macintosh у таблиці не відображався. Я тоді й сам припускав, що причина могла бути в роботі лічильника, тому робити з цього висновок про всіх користувачів Mac не варто.
Мені хотілося, щоб люди активніше освоювали Linux. Його частка в цій вибірці становила 1,34%, і я очікував її зростання: під час економічної кризи люди шукали способи заощадити. Безплатне програмне забезпечення та недорогі компактні комп’ютери, зокрема нетбуки, здавалися мені одним із таких шляхів.
У старому проєкті я зіткнувся з тим, що значення параметра форми, очікуване як save, надходило з додатковими символами ¬_. Проблему помітили під час роботи з IE6, Safari та Opera. У початковій нотатці підозрювалося також передавання через POST, але окремої перевірки цього припущення не наведено.
Ілюстрація отриманого значення та порівняння з оригіналу:
$_GET['op']='save¬_'
if ($_GET['op']=='save'){'программный код'}Фрагмент вище показує задум перевірки й не є готовим виконуваним прикладом: рядок у фігурних дужках — заповнювач. Через відмінність у значенні порівняння з save не давало очікуваного результату.
У «Корпорація 2» тоді використовувалася власна функція очищення:
$GLOBALS["c"]->clrget('Поле');У тексті також був наведений такий виклик:
echo 'op= '.$GLOBALS["c"]->clrget($_GET["op"])Очікуваний результат у тому випадку — op=save. Ці записи по-різному описують аргумент: спершу назву поля, потім його значення. Без реалізації методу clrget не можна вважати їх взаємозамінним або документованим API.
Пізніше я пов’язав помилку з формою, де action містив параметри URL, а методом було обрано POST. Однак саме поєднання цих елементів не доводить причини додавання символів і не є загальною властивістю браузерів. Для діагностики потрібно перевіряти HTML форми, кодування, фактичний запит і обробник параметрів; універсальне відрізання двох символів може пошкодити правильні значення.
Механізм надсилання форм описано в стандарті HTML. Наведена нотатка стосується конкретної історичної реалізації.
У 2009 році я звернув увагу на інструменти Яндекс.Вебмайстра для власників сайтів. Додавання свого ресурсу та підтвердження прав давали доступ до відомостей про його обхід пошуковим роботом.
Мене зацікавила можливість бачити помилки обходу, час відвідування сайту роботом і пояснення проблем із присутністю в пошуку. Початкова адреса консолі була http://webmaster.yandex.ru/wmconsole/.
Сучасна документація сервісу про статистику обходу розрізняє дату відвідування, адресу сторінки та HTTP-код відповіді. Успішний обхід сторінки не тотожний гарантії її появи в пошуковій видачі.
У лютому 2009 року я зберіг уривки матеріалу про PageRank з woweb.ru/publ/31-1-0-714. Частина формул у старій публікації втратилася, а деякі поради змішували математичну модель із практикою пошукової оптимізації. Нижче — впорядковане пояснення з уточненнями.
Уявімо користувача, який переходить між вебсторінками: іноді за посиланням, іноді починає перегляд із випадково вибраної сторінки. PageRank описує стаціонарний розподіл імовірностей перебування на сторінках у такій моделі. Повторні відвідування можливі; умова «ніколи не потрапляти на ту саму сторінку двічі» зі старого переказу була неточною.
Для нормованої спрощеної моделі, де кожна сторінка має вихідні посилання, формулу можна записати так:
PR(p) = (1 - d) / N + d * sum(PR(q) / L(q))
q -> pТут N — кількість сторінок, L(q) — кількість вихідних посилань зі сторінки q, а сума охоплює сторінки, які посилаються на p. У цьому записі d — імовірність переходу за посиланням, 1 − d — випадкового переходу. У літературі позначення можуть відрізнятися, тому важливо читати визначення коефіцієнта. Приклад такого запису є в навчальному матеріалі Stanford.
Для сторінок без вихідних посилань потрібне окреме правило розподілу їхньої ваги. У матричній формі використовують матрицю переходів і повторні ітерації над вектором оцінок. Вага переходу за посиланням визначається кількістю вихідних посилань, а не просто початковим значенням 1/N. За стандартних умов моделі з додатною ймовірністю випадкового переходу отримують єдиний стаціонарний розподіл.
Google підтверджує, що PageRank розвинувся від початкової реалізації та залишається частиною основних систем ранжування. Практичні дії з посиланнями варто звіряти з правилами щодо посилального спаму. Корисні матеріали та зрозумілі переходи важливіші за спробу механічно «накрутити» одну оцінку.
У лютому 2009 року я зберіг нотатку про формування зрозумілих URL для динамічних сторінок Apache/PHP. Джерелом був матеріал woweb.ru/publ/36-1-0-336. У ньому розглядали чотири підходи: обробник помилки 404, MultiViews, ForceType і mod_rewrite.
Нижче збережено початкові фрагменти коду як історичні приклади. Вони залежать від конфігурації Apache та способу підключення PHP; некоректні конструкції окремо пояснено.
ErrorDocument 404 script.phpСтарий підхід пропонував обробляти вигаданий URL у скрипті, викликаному замість відсутньої сторінки. Наведений рядок не є готовим маршрутизатором: значення ErrorDocument має відповідати синтаксису Apache. Для наявної сторінки та справді відсутнього ресурсу потрібні різні результати обробки й HTTP-статуси.
Options MultiviewsУ нотатці припускали, що шлях на кшталт /one/two/three буде зіставлено з файлом one.php, а залишок обробить скрипт. Насправді MultiViews належить до узгодження вмісту: добір варіанта залежить від розширень і налаштувань. Це пояснює документація Apache. Такий механізм не є універсальною заміною маршрутизації.
<filesmatch index="">
ForceType application/x-httpd-php
</filesmatch>Цей блок у збереженому HTML мав некоректний запис секції FilesMatch, тому його не можна копіювати як чинну конфігурацію. ForceType задає тип вмісту; використання спеціального MIME-типу для запуску PHP залежало від історичної поведінки модулів. Apache рекомендує уникати такого покладання на «магічні» типи та налаштовувати обробник явно. Для PHP-FPM потрібна конфігурація відповідного способу підключення.
RewriteEngine On
Options +FollowSymlinks
RewriteBase /
RewriteRule ^index/(.*)$ /index.php/$1Модуль переписує шлях index/... у /index.php/.... Це не обов'язково зовнішнє перенаправлення браузера: переписування може бути внутрішнім. Контекст правила й прапорці визначають результат; дивіться mod_rewrite. Директива RewriteEngine сама собою не обмежує правила лише поточним каталогом.
У джерелі було й комбіноване налаштування:
RewriteEngine On
RewriteBase /
RewriteRule ^index/(.*)$ /index.php/$1
<filesmatch index.php="">
ForceType application/x-httpd-php
</filesmatch>Воно містить таку саму проблему запису FilesMatch. Приклад із сайтом webshops.ru пояснював задум: запит /index/webshops обробляє index.php, який визначає потрібну сторінку за URI. Це ілюстрація маршруту з давнього матеріалу, а не перевірена конфігурація цього сайту сьогодні. Замість старої змінної $REQUEST_URI у сучасному PHP зазвичай використовують $_SERVER['REQUEST_URI'].
Початковий матеріал пропонував такі рядки:
Header("HTTP/1.0 200 OK"); //строка нужна только для п. 1
Header("Last-Modified: ".gmdate("D, M d Y H:i:s",filemtime("index.php"))." GMT"); //строка пригодится в любом случаеheader() потрібно викликати до фактичного виведення вмісту. Не варто безумовно повертати 200 для будь-якого невідомого URL: відсутній ресурс має залишатися помилкою, інакше можливий soft 404.
Час зміни файла index.php не обов'язково відповідає часу зміни даних усіх сторінок, які він формує. Крім того, у форматі дати старого фрагмента переплутано порядок дня та місяця. Для HTTP-дати потрібен порядок на кшталт D, d M Y H:i:s у GMT; значення Last-Modified має описувати саме відповідне представлення ресурсу — дивіться RFC 9110.
У віртуальних каталогах старий матеріал пропонував абсолютні адреси або елемент base у секції head:
<base href="http://ваш_сайт.ru/"></base>Домен у цьому рядку — заповнювач. За стандартом HTML елемент base не має закривального тега; він впливає на всі відносні URL документа. Після зміни маршрутизації перевірте зображення, стилі, скрипти, форми та звичайні посилання.
Зрозумілі URL корисні для навігації, але динамічний сайт не потрібно «маскувати» під статичний заради самого пошуку. Для поточних рішень орієнтуйтеся на рекомендації Google щодо структури URL та конфігурацію свого сервера.
У нотатці про конфігурування файлового менеджера FCKeditor я зберігав довідкову адресу:
http://www.sergiusd.ru/scripts/fckfsys2#exampleДля роботи зі старим проєктом корисно знати, що саме налаштовувалося. Автор SergiusD у публікації про FCKfsys 2.0 від 12 січня 2009 року навів параметри цього PHP-модуля для FCKeditor 2.6.3. Сумісність із пізнішими версіями він не гарантував.
Чотири параметри керували видаленням і роботою із зображеннями:
Delete — дозвіл видаляти файли й каталоги.ThumbCreate — можливість змінювати розміри зображення під час завантаження.ThumbList — показ мініатюр для ресурсу Image.ThumbListSize — розмір квадрата, у який вписується мініатюра; у прикладі автора — 100.Для обробки зображень використовувався ImageMagick або, за його відсутності, GD2. Якщо відповідних засобів на сервері немає, автор пропонував вимкнути функції створення мініатюр. Для ресурсу ImageThumb задавалися дозволені й заборонені розширення та шляхи до каталогу imageThumb/. Сам каталог потрібно було створити на сервері, а не лише вписати його адресу в конфігурацію.
Перед змінами збережіть конфігурацію та робочі файли. Зіставте назви параметрів із кодом саме вашої копії модуля: однакова назва редактора не доводить однакової реалізації файлового менеджера.
Окремо перевірте дозволені каталоги, типи завантажень і права доступу. Тестуйте створення папки, завантаження дозволеного файлу, обробку зображення й видалення на тестових даних. Видалення варто дозволяти лише там, де воно потрібне користувачеві. Ця послідовність допомагає відрізнити помилку шляху чи дозволів від відсутності бібліотеки обробки зображень.
Свого часу знайшов непогану збірку PHP-скриптів на WoWeb. Залишаю початкову адресу:
http://www.woweb.ruНа WoWeb.ru доступний каталог скриптів із розділом PHP. Серед категорій є гостьові книги, форуми, банери, каталоги посилань, чати й пошук. Це зручний спосіб зорієнтуватися в добірці за потрібним завданням.
Сам сайт пояснює, що скрипти збиралися в різний час і чимало серверних прикладів застаріли. Тому конкретний скрипт слід розглядати окремо: перевірити код, вимоги до PHP, ліцензію та придатність до свого проєкту. Наявність у каталозі сама по собі не підтверджує сумісності чи безпеки.
Для роботи із ZIP я зберіг посилання на http://blog.webmasterschool.ru/php/48/ та клас Create ZIP File з http://www.phpclasses.org. Нижче — приклади роботи зі старим стороннім класом і процедурним ZIP API.
Клас createZip не є вбудованим класом PHP. Його реалізації у статті немає; приклад залежить від окремого файла createZip.inc.php:
// Подключаем класс для работы с zip-архивами
include_once("createZip.inc.php");
$createZip = new createZip;
// Добавляем директорию
$createZip -> addDirectory("dir/");
// Добавляем файл
$fileContents = file_get_contents("img.jpg");
$createZip -> addFile($fileContents, "dir/img.jpg");
// Создаем архив
$fileName = "archive.zip";
$fd = fopen ($fileName, "wb");
$out = fwrite ($fd, $createZip -> getZippedfile());
fclose ($fd);
// Отдаем архив браузеру
$createZip -> forceDownload($fileName);
@unlink($fileName);
?>У прикладі $dir задає каталог призначення, $file — шлях до архіву, а $log вмикає діагностичний вивід. Функція проходить елементи архіву, створює каталоги та записує вміст файлів:
/**
* Распаковывает zip-архив в указанный каталог.
* $dir - полный путь к каталогу.
* $file - полный путь к zip-архиву.
* $log - флаг вывода диагностики.
*/
function unpackZip($dir, $file, $log=0) {
if ($log) echo "Start unpack [$file] into [$dir] directory...
";
if ($zip = zip_open($file)) {
if ($zip) {
// создать каталог, если он не существует
if (! file_exists($dir)) mkdir($dir);
while ($zip_entry = zip_read($zip)) {
$name = zip_entry_name($zip_entry);
if ($log) echo " <b>unpack </b>: $name
";
// последний символ имени
$last = substr($name, strlen($name)-1);
// если это каталог
if ($last == "/" || $last == "\\") {
$subdir = $dir."/".$name;
// создать каталог, если он не существует
if (! file_exists($subdir)) mkdir ($subdir);
} else {
// распаковать файл
if (zip_entry_open($zip, $zip_entry, "r")) {
$buf = zip_entry_read($zip_entry, zip_entry_filesize($zip_entry));
$fp = fopen($dir."/".zip_entry_name($zip_entry), "w");
fwrite($fp, $buf);
zip_entry_close($zip_entry);
} else {
return false;
}
}
}
zip_close($zip);
}
} else {
return false;
}
return true;
}
?>Ці фрагменти не є готовим рішенням для обробки недовірених архівів. У функції шлях запису складається безпосередньо з імені елемента ZIP: немає перевірки виходу за межі каталогу, обмежень обсягу розпакування чи надійного контролю помилок. Дескриптор записуваного файла явно не закривається; вкладені каталоги також обробляються неповно.
Крім того, zip_open() може повертати числовий код помилки, тому проста перевірка істинності не гарантує успішного відкриття. Цю функцію позначено застарілою з PHP 8.0 на користь об'єктного API ZipArchive.
Для нового коду звертайтеся до документації ZipArchive та перевіряйте шляхи, ліміти ресурсів і всі результати операцій. Довідка щодо старого виклику: zip_open. Історичний код збережено для розбору; не запускайте його без адаптації на довільних завантаженнях.
«Ось так у нас роблять бізнес», — написав я в лютому 2009 року, коли з’явилася новина про платний вхід на київські кладовища. У першій нотатці я повторив формулювання про вхід. Після звірки з тодішнім порядком видно, що йшлося про в’їзд автомобілів. Для людей, які приходили пішки, КМДА підтвердила безкоштовний доступ.
27 січня УНІАН повідомив про платний вхід, посилаючись на заяву заступника голови КМДА Віталія Журавського. Наступного дня пресслужба КМДА передала його уточнення. Плата стосувалася автомобілів, які не були задіяні в похованні. У повідомленні йшлося про 10 грн за в’їзд на п’ять кладовищ: Південне, Байкове, Міське, Лісове й Північне.
Розпорядження № 1495 від 31 жовтня 2008 року змінило порядок утримання та роботи київських кладовищ. У тодішній редакції транспорт, задіяний у похованні, міг проїжджати за договором-замовленням. Для іншого автотранспорту передбачили платний в’їзд. Це і є різниця, яку заголовки про платний вхід стерли.
7 квітня 2009 року розпорядженням № 351 КМДА визнала відповідні положення № 1495 такими, що втратили чинність, і прибрала згадку про плату з правил проїзду. Історію цього рішення варто читати за двома редакціями: січневі повідомлення пояснюють, чому новина викликала обурення, а квітневий документ показує, що саме змінилося.
Після перезавантаження Linux у моїй тодішній конфігурації VMware почав скаржитися на зайняті ресурси: процесор, пам’ять, CD-ROM та інші пристрої. Гостьові машини в результаті не запускалися.
Я вирішив перевстановити VMware. Видалення пройшло успішно, але під час нового встановлення інсталятор повідомив про KVM і відмовився продовжувати, поки той запущений.
Активного KVM я тоді не бачив. Спробував видалити пакети, які могли бути з ним пов’язані, але це не допомогло.
Тоді я встановив KVM і відразу його видалив. І, о диво, після цього VMware нормально встановився, а віртуальні машини знову запустилися!
Проблема час від часу поверталася, і повторне встановлення та видалення KVM тимчасово її усувало. Я припускав, що справа в командах, які виконувалися під час видалення пакета. Утім, перевірки журналів або стану модулів для підтвердження цієї причини в мене не було.
Описаний результат показує послідовність дій у моїй старій системі, але не точний механізм конфлікту. Для його розбору потрібні версії VMware, KVM і ядра, повний текст помилки та журнали. Видалення пакетів навмання може зачепити потрібні компоненти, тому переносити цей обхід на іншу конфігурацію без діагностики не варто.
Сподобалася бібліотека pChart для побудови графіків у PHP. Залишаю початкову адресу зі своєї добірки:
http://pchart.sourceforge.netНа сайті pChart на SourceForge зберігся опис гілки 1.x. Бібліотека працює з даними, підготовленими вручну, з CSV або результатів SQL-запитів. Для побудови зображень потрібна підтримка GD у PHP.
У документації pChart є описи класів pChart, pData і pCache, структура даних та приклади лінійних, стовпчикових і кругових діаграм. Для розуміння коду зручно почати з підготовки набору даних, потім перейти до області побудови, підписів і легенди.
Ці приклади належать до старої гілки бібліотеки. Якщо переносите такий проєкт на іншу версію PHP чи pChart, окремо перевірте сумісність викликів і вимоги GD. Умови ліцензії беріть із тієї версії бібліотеки, яку використовуєте.
VNC, або Virtual Network Computing, — підхід до віддаленого доступу до графічного робочого столу. Сервер передає зображення екрана, а клієнт надсилає події клавіатури та миші. Для цього використовується протокол RFB — Remote Framebuffer.
Клієнт і сервер можуть працювати в різних операційних системах, якщо відповідні реалізації сумісні. Це зручно для технічної підтримки й доступу до власного робочого середовища. Можливість одночасного підключення кількох клієнтів та конкретні функції залежать від сервера і його налаштувань.
VNC створили в Olivetti & Oracle Research Lab (ORL) у Кембриджі. У 1999 році AT&T придбала лабораторію, і розробка продовжилася в AT&T Laboratories Cambridge — цю послідовність наведено в історії RealVNC. Старі згадки Java та J2ME відображають тодішні реалізації, а не гарантію підтримки цих платформ зараз. Відкриті реалізації та похідні VNC поширюються, зокрема, за GNU GPL; прикладом є код LibVNCServer із позначенням GNU GPL та авторства первісного Xvnc. Водночас умови ліцензування потрібно перевіряти для конкретного продукту: назва VNC не означає, що кожна реалізація поширюється за GPL.
Механізм RFB описано в RFC 6143. Обираючи засіб доступу, окремо перевіряйте автентифікацію, захист з'єднання та дозволи користувачів.
http://ru.wikipedia.org/wiki/Virtual_Network_Computinghttp://ask.slashdot.org/article.pl?sid=04/10/20/0132236&tid=185&tid=201&tid=4Кого криза зачіпає найболючіше? У лютому 2009 року, розмірковуючи над цим питанням, я насамперед думав про тих, кому вже бракувало грошей і ресурсів. Коли витрати перевищують можливості, запасу для несподіваного удару залишається небагато.
Але пояснити вразливість компанії лише дефіцитом бюджету було б надто просто. Значення мають і зобов'язання, і доступ до коштів, і залежність від постачальників, енергії та зовнішніх рішень. Навіть прибуткове підприємство може зіткнутися з перервою в роботі.
Великий прибуток у звіті ще не означає, що в потрібний день є чим виконати всі платежі. Прибуток і рух коштів — різні показники: IAS 7 про звіт про рух грошових коштів окремо розглядає надходження й виплати та пояснює коригування прибутку при непрямому методі.
У своєму дописі 2009 року я наводив можливі сценарії: обмеження доступу до грошей або припинення постачання газу на завод. Суть цих прикладів — у зовнішній залежності. Компанія може добре виконувати свою роботу, але втратити можливість продовжувати її через подію поза власним контролем.
Моя головна думка тоді була проста: не варто розраховувати, що криза омине саме нас або що хтось обов'язково врятує бізнес. Підготовку до перебоїв потрібно продумувати заздалегідь.
Практично це починається з кількох запитань:
Такий підхід описано в рекомендаціях Канадського центру кібербезпеки щодо безперервності бізнесу: визначити загрози й наслідки, підготувати порядок дій, розподілити відповідальність і перевіряти план на практиці.
Передбачити кожну подію неможливо. А от знати власні слабкі місця й мати погоджений порядок дій — цілком реальна робота. Саме вона допомагає не опинитися «за бортом», коли звичні умови раптом змінюються.
У лютому 2009 року я звернув увагу на повідомлення про збитки й реструктуризацію Sony. Початкова нотатка посилалася на itnews.com.ua/46310.html і поєднувала фінансову цифру зі скороченням працівників та виробничих майданчиків. Для точного розуміння ці події потрібно розділити.
У повідомленні від 9 грудня 2008 року Sony оголосила план скоротити кількість виробничих майданчиків приблизно на 10% із тодішніх 57 до 31 березня 2010 року. Звідси походить оцінка близько п'яти-шести підприємств.
В електронному бізнесі планували скорочення приблизно 8 тисяч штатних працівників, а також зменшення сезонної та тимчасової робочої сили. Стару загальну цифру «16 тисяч» не варто подавати як число вже звільнених штатних співробітників: це змішує категорії та оголошений план із результатом його виконання.
У звітності Sony від 29 січня 2009 року за квартал жовтень–грудень 2008 року наведено операційний збиток 18 млрд єн, або 197 млн доларів у перерахунку компанії. Водночас чистий прибуток цього кварталу становив 10,4 млрд єн.
У тій самій звітності прогноз операційного збитку на фінансовий рік до 31 березня 2009 року становив 260 млрд єн, приблизно 2,9 млрд доларів за наведеним курсом. Саме прогноз річного операційного результату, квартальний операційний збиток і чистий прибуток не можна називати однією цифрою «втрат».
Для мене криза тоді була перевіркою компаній на міцність: навіть великий масштаб сам по собі не захищає бізнес від боргового навантаження та втрати позицій на ринку. Так я пояснював свій інтерес до цих новин у лютому 2009 року; це авторський висновок, а не твердження про неплатоспроможність Sony.
Тодішня ситуація показувала, як падіння попиту, валютні зміни та витрати впливають на велику технологічну компанію. Ця публікація описує стан і плани на межі 2008–2009 років, а не сучасний фінансовий стан Sony.
У лютому 2009 року в мене почали зависати віртуальні машини у VMware Server. Проблема не обмежувалася гостьовою системою: разом із нею зависала вся Ubuntu 8.10.
Довго намагався знайти причину, а потім установив VMware Workstation. У ньому віртуальні машини знову почали запускатися.
Працювало, щоправда, якось повільно — але все ж працювало. Це було моє враження від роботи системи, а не вимірювання продуктивності VMware Server і Workstation.
Номерів збірок, журналів помилок і точних налаштувань у тій нотатці немає. Тому вона описує перебіг мого збою та заміну інструмента, але не встановлює його технічну причину й не визначає сумісність інших версій VMware або Ubuntu.
У лютому 2009 року я звернув увагу на повідомлення про зміни в європейських офісах Google. Тодішня нотатка спиралася на новину itnews.com.ua/46299.html. Первинне повідомлення компанії дозволяє точніше описати, що саме відбувалося.
У заяві від 14 січня 2009 року компанія повідомила про консолідацію інженерних команд в Остіні, Тронгеймі та Лулео. Зміни стосувалися близько 70 інженерних працівників у цих трьох містах разом. Google прагнула зберегти якомога більше з них, запропонувавши роботу в інших офісах, але не гарантувала переведення кожного.
Це уточнює старий переказ: йшлося про конкретні інженерні майданчики, а не про повне припинення діяльності Google у Швеції або Норвегії. Кількість 40 працівників із вторинної новини не слід підміняти загальним масштабом оголошених змін.
Того самого дня Google опублікувала повідомлення про скорочення приблизно 100 посад у рекрутингу на тлі уповільнення найму. Це інший захід, який не варто змішувати з переведенням інженерів.
У початковій нотатці я пов'язував новини з економічною кризою. Сам факт реорганізації не доводить збитковості компанії чи недостовірності її фінансової звітності. Ця публікація зберігає контекст 2009 року й описує тодішні оголошення, а не поточний стан офісів Google.
На початку 2009 року підготовка до Євро-2012 поставила питання, де розмістити гостей чемпіонату. У січневому сюжеті програми «Подробиці» йшлося про потребу збудувати 160 готелів за три роки у шести українських містах, які тоді розглядали для проведення матчів. Сюжет від 23 січня 2009 року в архіві Української асоціації футболу.
У сюжеті навели такий розподіл за категоріями:
Разом ці числа дають 160. У первинному заголовку цього допису стояло 120. У тексті допису й у телевізійному сюжеті фігурувало число 160. Воно описувало оцінену на початку 2009 року потребу в готелях.
У травні 2009 року виконком УЄФА підтвердив Київ для групових матчів і частини плей-оф. Для Донецька, Львова й Харкова залишив час виконати вимоги до стадіонів, транспорту й розміщення. Дніпропетровськ і Одесу до переліку міст проведення не включили. Травневе рішення УЄФА.
У грудні УЄФА затвердила проведення матчів у Києві, Донецьку, Львові й Харкові, а фінал залишила за Києвом. Січневу цифру 160 варто читати в контексті ранньої підготовки, коли розглядали шість міст. Грудневе рішення УЄФА.
У цій короткій нотатці я зберіг посилання на матеріал про вплив кризи на великі IT-компанії: mobilnik.ua/articles/442.html.
Самих результатів, таблиць або фінансових показників у дописі Blogger не наведено. Тому цей запис є покажчиком на джерело, а не відновленим порівнянням компаній.
Щоб оцінити такі результати, потрібні дата й період звітності, назви компаній і конкретні показники: зміна виручки, прибутку або чисельності працівників означає різні речі. У наявному тексті цих даних немає, тож приписувати компаніям певні втрати за самим заголовком не можна.
Поступово переходячи на Linux, я шукав заміну звичному ICQ-клієнту. LICQ мені не зовсім підійшов: у моїй конфігурації були спотворення під час передавання даних і питання до використаних портів.
Варіанти Pidgin і SIM знайшов у статті за адресою http://ubuntueasy.com/internet/icq-klienty-v-ubuntu-linux-7-10.
У моїй тодішній Ubuntu Pidgin уже був установлений: достатньо було відкрити «Програми → Інтернет» і запустити його. Це був мультипротокольний клієнт, який не обмежувався ICQ. Наявність у цій інсталяції не означала, що Pidgin є обов’язковою частиною кожної системи з GNOME.
Далі я додавав обліковий запис, обирав протокол ICQ, вводив потрібні дані й підключався. Спочатку вигляд здавався незвичним, та до нього можна було звикнути; нестандартні звуки теж налаштовувалися.
Для обміну зі співрозмовниками на інших системах я тоді звертав увагу на параметр cp1251. Він стосувався сумісності кодування в тому середовищі й не був універсальним налаштуванням для всіх месенджерів.
SIM нагадував звичайний ICQ-клієнт і теж підтримував кілька протоколів. Водночас для його встановлення в моїй Ubuntu доводилося додавати залежності KDE — їхня кількість тоді здалася мені суттєвим мінусом.
У старому репозиторії використовувався такий рядок встановлення:
sudo apt-get install simУстановлену програму шукали в меню «Програми → Інтернет».
Зрештою поставив собі Pidgin. Непоганий виявився пейджер: кілька протоколів, робота в Linux і, коли звик, цілком приємний інтерфейс.
Описаний вхід до ICQ стосується 2009 року. Згодом протокол змінився, і розробники Pidgin пояснили в офіційній довідці про протоколи, що самі не підтримують його новий варіант. Старий рядок встановлення SIM також не підтверджує наявності пакета в репозиторії вашої версії Ubuntu.
14 лютого 2009 року QIP сам повідомив мені про нову версію та запропонував її завантажити.
Я встановив запропоноване оновлення — і ICQ знову запрацював нормально.
Знову проблеми з ICQ у QIP… У моїй тодішній версії клієнта підключення періодично не працювало.
Мені знову надійшло сповіщення, що мій варіант ICQ-клієнта не підтримується. І це при тому, що встановлена версія QIP була однією з новіших на той момент!
Раніше подібні відключення сторонніх клієнтів я пов’язував зі змінами протоколу ICQ. Нове повідомлення нагадало ту ситуацію, але саме по собі воно не пояснювало причини повторного збою. Для точного розбору потрібні версія QIP, текст діагностики та дані про стан сервісу в той час.
Коли мій шлюз на Windows почав сильно збоїти, я вирішив перенести його функції на Ubuntu 8.10. Раніше це мені не вдавалося: провайдер надавав інтернет через VPN, а для з’єднання треба було правильно вказати чимало параметрів.
Цього разу все запрацювало на ура! Допоміг NetworkManager, у якому можна було налаштовувати різні типи з’єднань: дротові, бездротові, DSL і VPN. Саме зручніше керування з’єднанням стало для мене головною відмінністю від попередніх спроб.
Налаштування VPN я тоді розбирав за статтею:
http://openkazan.info/ubuntu-8.10-vpn-pptp
З Firestarter довелося повозитися окремо, щоб узгодити його роботу з VPN. Для цього використовував такі обговорення й матеріали:
http://liski.vsi.ru/ubuntu/index.php?page=79http://forum.ubuntu.ru/index.php?topic=42746.0Перебіг цієї спроби та обмеження знайденого обходу описав у попередньому дописі про Firestarter і VPN. Сам факт роботи з’єднання ще не засвідчує правильності правил фільтрації.
У підсумку в моїй конфігурації вдалося зробити більше, ніж до цього на Windows:
Це досвід налаштування Ubuntu 8.10 у 2009 році. Точні старі адреси залишив для зв’язку з тією конфігурацією; їхній вміст нині не вдалося перевірити. Опис типів з’єднань тогочасного NetworkManager зберігся в довідці Ubuntu для NetworkManager 0.7.
У старій конфігурації VPN я зіткнувся з проблемою взаємодії Firestarter і з'єднання через ppp0. Guarddog мені не підійшов, тому я повернувся до Firestarter й знайшов обговорення за адресою http://forum.ubuntu.ru/index.php?topic=42746.0.
Спочатку я вибрав ppp0 як інтерфейс, що дивиться в інтернет, і відредагував /etc/firestarter/user-pre. Наведений варіант із політиками ACCEPT міг істотно послабити фільтрацію — саме тому його не варто переносити як готове безпечне налаштування:
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPTЦе встановлює політику ACCEPT для відповідних вбудованих ланцюжків. Така політика дозволяє пакети, для яких не спрацювало інше завершальне правило; вона не видаляє наявні правила, але може істотно послабити фільтрацію. Відновлення VPN таким способом не підтверджує безпечного налаштування.
На інших форумах я також зустрічав такі правила:
$IPT -A INPUT -p TCP --dport 1723 -j ACCEPT
$IPT -A INPUT -p 47 -j ACCEPT
$IPT -A OUTPUT -p TCP --dport 1723 -j ACCEPT
$IPT -A OUTPUT -p 47 -j ACCEPTУ моїй тодішній конфігурації з цим варіантом з’єднання через певний час усе одно переривалося. Я припускав, що слід додати ще два рядки, але їх не перевіряв:
$IPT -A FORWARD -p TCP --dport 1723 -j ACCEPT
$IPT -A FORWARD -p 47 -j ACCEPTТут $IPT — змінна зі старого оточення, значення якої в нотатці не задано. Число 47 позначає IP-протокол GRE, а не порт; TCP 1723 використовується для керувального з'єднання PPTP. Самі ці фрагменти не визначають повного набору правил для маршрутизації, станів з'єднань і конкретної топології.
Після зміни файла в тодішній системі я перезапускав Firestarter:
sudo /etc/init.d/firestarter restartДля діагностики слід перевіряти фактичні правила, журнали та потрібні напрямки трафіку, з можливістю повернення попередньої конфігурації. Технічний опис дії правил і протоколу: Netfilter: iptables та RFC 2637: PPTP. Цей історичний розбір не є рекомендацією обирати PPTP для нового VPN.
У 2009 році для редагування правил iptables я розглядав графічні оболонки Firestarter і Guarddog. Firestarter здавався простішим, але в моїй конфігурації переривалися VPN-з’єднання; Guarddog був складнішим у налаштуванні. Це особисте спостереження, без версій і журналів збою.
Ядро Linux містить підсистему Netfilter, а правила налаштовують відповідними інструментами. Не всі конфігурації зводяться до редагування одного текстового файла й не кожна система автоматично має потрібні правила.
У сучасному контексті також є nftables і засоби керування на кшталт ufw. Конкретний інструмент і спосіб збереження правил залежать від дистрибутива та його версії. Для Ubuntu це пояснює документація щодо міжмережевих екранів.
На час цієї нотатки 2009 року я працював із Unix-подібними системами вже близько п’яти років, якщо не більше, і особисто не стикався з Linux-вірусами. Проте цей досвід не дає підстав стверджувати, що Linux не буває заражений або не потребує засобів захисту.
Перевірка файлів корисна, зокрема, коли до спільних каталогів або розділів мають доступ комп’ютери з Windows: файл, який не виконується в Linux, може потрапити до іншої системи. У моїй добірці були:
Засоби мають різні завдання, тому їх не слід вважати взаємозамінними чи гарантією виявлення всіх загроз. Кількість установлених сканерів сама по собі не визначає рівень захисту, а вплив на швидкодію залежить від режиму їхньої роботи.
Для спостереження за мережею я також звертав увагу на EtherApe та IPTraf. EtherApe графічно показує мережеву активність і протоколи, а IPTraf подає мережеву статистику в консолі. Це засоби діагностики трафіку, а не антивірусні сканери.
Див. офіційну документацію ClamAV: вона описує можливості сканера та прямо відрізняє його від повного комплексу захисту кінцевого пристрою.
Перевірити швидкість інтернету можна через Speedtest: сервіс вимірює з’єднання між вашим пристроєм і вибраним тестовим сервером.
У результаті можна оцінити швидкість завантаження, швидкість передавання даних і затримку. Це показники конкретного тесту: інший сервер, час або спосіб підключення можуть дати інший результат.
Зміна сервера допомагає побачити різницю між напрямками, але один тест не описує швидкість роботи з усіма сайтами чи будь-яким регіоном світу.
У лютому 2009 року я порівнював окремі робочі місця та мережевий варіант програми «Корпорація-Салон». Головна ідея — об'єднати роботу салонів, спростити обмін інформацією й супровід. Наведені нижче суми збережено як історичний приклад; це не чинний прайс.
У тодішню комплектацію входили склад, виробництво, послуги, відрядна зарплата, дисконтна система, облік коштів і менеджер звітів.
За цими історичними цінами різниця становила 1 569,75 долара, або приблизно 59,9% вартості п'яти окремих ліцензій. Окремий варіант коштував приблизно у 2,5 раза дорожче за мережевий.
Спільне інформаційне середовище допомагає уникати повторного введення, збирати зведені дані для керівника та бачити стан продажів у різних салонах. У початковому матеріалі також ішлося про дистанційні консультації, оновлення програм і вебсервіси зі звітами.
Централізований супровід може скоротити кількість окремих баз і виїздів спеціаліста. Загальні витрати залежать також від зв'язку, інфраструктури та способу обслуговування. Самого підключення філій до інтернету недостатньо, щоб визначити умови ліцензії: кількість дозволених робочих місць і сценарії використання потрібно звіряти з конкретною пропозицією та договором.
У публікації 2009 року нову на той час версію представляли як зручнішу для розподіленої роботи. Основним варіантом бази даних називали MySQL, тоді як «Корпорація 1» працювала з Firebird 2. Твердження про підтримку «практично будь-якої SQL-бази» потребувало перевірки конкретного адаптера й версії.
Також зазначали модульність на основі програмного коду, керування доступом до команд меню та правами читання й запису. Окремо описували можливість тому самому користувачеві працювати з різними наборами прав — наприклад, керівникові виконувати звичайні операції з обмеженим доступом. Це історичний опис «Корпорація 2», який не замінює перевірки можливостей і умов сучасної версії.
Чому після однієї чашки кави хтось бадьорий до вечора, а хтось за кілька годин знову засинає? Кількість кофеїну залежить від напою й порції, а чутливість до нього різниться. П’ять запитань нижче допомагають розібратися, коли має значення час чашки, коли спосіб приготування, а коли звичка пити каву із цукром.
Кофеїн може тимчасово підвищувати артеріальний тиск. За даними FDA, реакція залежить від чутливості людини, стану здоров’я та ліків. Кількість чашок теж не дає точного уявлення про дозу: порції й міцність напою різні. Тимчасова реакція після чашки відрізняється від діагнозу гіпертонії. Якщо у вас уже є підвищений тиск або серцебиття, індивідуальну межу споживання варто обговорити з лікарем.
Кофеїн стимулює нервову систему, і цей ефект може тривати кілька годин. У контрольованому дослідженні сну 2013 року доза 400 мг порушувала сон навіть тоді, коли її приймали за шість годин до сну. Це конкретна доза в експерименті. У повсякденні має значення також кофеїн із чаю, коли, енергетиків та інших напоїв.
Американська стоматологічна асоціація називає каву одним із напоїв, які можуть залишати поверхневі плями на зубах. Карієс має інший механізм. Якщо додавати цукор і пити солодкий напій потроху протягом дня, зуби частіше контактують із цукром, яким живляться бактерії зубного нальоту. Довідка асоціації пояснює ризик солодких напоїв.
У нефільтрованій каві залишаються дитерпени, зокрема кафестол і кахвеол. У рандомізованому дослідженні 1996 року порівнювали міцну каву з френч-преса та фільтровану. У групі, яка вживала п’ять-шість чашок нефільтрованої кави на день протягом 24 тижнів, рівень холестерину ЛПНЩ був вищим. Це результат для зазначеного способу приготування й кількості. Кофеїн і дитерпени — різні речовини, тому зниження кофеїну саме по собі не дає відповіді щодо вмісту кафестолу.
Після регулярного споживання різке зменшення кофеїну може спричинити головний біль, сонливість чи інші симптоми відміни. FDA радить скорочувати споживання поступово, якщо людина хоче пити менше кофеїну. Якщо змінилася якість сну, спочатку корисно простежити, коли і скільки кофеїну ви споживаєте. Для порівняння впливу способів заварювання важливо окремо враховувати, чи кава проходила через паперовий фільтр.
У лютому 2009 року я написав про вплив економічної кризи на ІТ-компанії. Новини про реструктуризацію з'являлися одна за одною, але їхні цифри потрібно співвідносити з конкретними датами й масштабом оголошених заходів.
У повідомленні Intel від 21 січня 2009 року йшлося про консолідацію виробництва, яка мала торкнутися 5–6 тисяч працівників до кінця 2009 року. Компанія зауважувала, що частині людей могли запропонувати роботу на інших майданчиках.
Тому число «20 тисяч» зі старої нотатки не підходить для опису саме цього оголошення. Кількість працівників, яких стосується реорганізація, також не дорівнює автоматично кількості звільнених.
У листі Стіва Балмера від 22 січня 2009 року, поданому до SEC, зазначено план скорочення до 5 тисяч посад за 18 місяців, із них 1 400 — того дня. Одночасно компанія планувала створювати нові посади в пріоритетних напрямах. Очікуване чисте зменшення чисельності в зазначених функціях становило 2–3 тисячі.
Початкове число «близько 15 тисяч» не відповідало цьому першоджерелу. План скорочення посад і чиста зміна кількості працівників — різні показники.
У матеріалі CRN про січневу заяву AMD наведено відповідь представника компанії: продуктова частина AMD, без виробничого бізнесу The Foundry Company, планувала зменшити чисельність приблизно на 9%. До цього входили природне вибуття працівників, продаж бізнесу для портативних пристроїв і додаткове скорочення приблизно 900 посад. Отже, 9% стосувалися визначеної частини бізнесу та сукупності заходів, а не одного загального числа звільнень.
Пізніший річний звіт AMD, поданий 24 лютого 2009 року, підтверджує, що в січні компанія оголосила додаткове скорочення чисельності, тимчасове зниження зарплат у США й Канаді та призупинення окремих виплат. Цей документ підтверджує характер заходів; точну базу відсотка він у наведеному описі не деталізує.
У формі 8-K щодо оголошення HP від 15 вересня 2008 року йшлося про усунення приблизно 24 600 посад протягом трирічної програми після придбання EDS. Водночас компанія очікувала замістити приблизно половину цих посад у межах зміни структури глобальної команди. Це був план інтеграції з власним строком і механізмом, а не число людей, уже звільнених до лютого 2009 року.
Цифри різних компаній не слід складати в одну статистику звільнень без зіставлення дат, охоплення й фактичного виконання. Скорочення посад, переведення до іншого офісу, продаж підрозділу та чиста зміна чисельності описують різні процеси.
Мій тодішній висновок полягав у тому, що компанії, які збережуть спроможність працювати під час спаду, можуть отримати можливості для розвитку. Це авторська оцінка в контексті 2009 року, а не гарантія результату чи опис нинішнього ринку праці.
У лютому 2009 року я спостерігав перебої підключення Svitonline (Білайн): спочатку мережа працювала нестабільно, а наступного дня доступ до інтернету зник.
Тоді я підозрював проблему з DNS, але в нотатці немає результатів діагностики, які підтверджували б саме цю причину.
Деякий час довелося працювати через резервну лінію. На момент публікації основне підключення вже відновилося.
Після оновлення мого комп’ютера з Ubuntu 8.04 до Ubuntu 8.10 виникла проблема з мережею: NetworkManager не хотів нормально працювати. У нотатці 2009 року я описав спосіб, який допоміг саме в цій конфігурації.
Я перейменував файл зі старими мережевими налаштуваннями /etc/network/interfaces та перезавантажив комп’ютер. Після цього NetworkManager знову належно керував мережею.
Мій початковий висновок, ніби NetworkManager взагалі не працює, коли існує цей файл, був надто широким. За документацією NetworkManager.conf, якщо використовується плагін ifupdown, параметр managed=false змушує NetworkManager ігнорувати інтерфейси, перелічені в /etc/network/interfaces. Має значення спосіб керування конкретним інтерфейсом і вміст налаштувань.
Це пояснює, чому старі записи могли впливати на керування мережею. Але без збереженої конфігурації мого комп’ютера неможливо встановити точну причину того збою лише за сучасною документацією.
Спочатку з’ясуйте, яка служба керує потрібним інтерфейсом, і збережіть його чинні налаштування. Потрібен також спосіб повернути попередню конфігурацію, якщо мережа зникне: під час віддаленої роботи зміна файла може перервати саме з’єднання, через яке ви адмініструєте машину.
Мій результат стосувався локального переходу Ubuntu 8.04 → 8.10. Він не робить перейменування /etc/network/interfaces універсальним способом виправлення мережі в інших версіях.
У лютому 2009 року, на тлі світової фінансової кризи, мене непокоїла думка: чи може влада, якій дедалі важче відповідати на внутрішні проблеми, шукати вихід у зовнішньому конфлікті? Я давно підозрював, що воєнна кампанія може відвертати увагу від економічних труднощів. Але збіг у часі сам по собі не показує, чому уряд вирішив застосувати силу, і з кількох прикладів неможливо вивести частоту воєн.
У серпні 2008 року Росія і Грузія воювали. У грудні почалася ізраїльська воєнна операція в секторі Гази, яка тривала й у січні. Того самого січня під час газового спору між Росією та Україною перервалися поставки до країн ЄС через Україну. Біля берегів Сомалі Євросоюз розпочав операцію проти піратства. На той час мені здавалося, що напруження зростає всюди. Проте збройні дії, суперечка про постачання газу й охорона морських шляхів були різними подіями, кожна зі своїми причинами.
Хронологію підтверджують рішення ЄС про розслідування конфлікту в Грузії, звіт про події в Газі, оцінка переривання газопостачання та рішення про початок операції Atalanta.
Найбільше мене непокоїла можливість, що Росія застосує збройні сили проти України. У 2009 році я уявляв, як регіональна війна могла б перерости у світову, і припускав, що це могло статися вже у 2010-му. Ось послідовність, яку я тоді розглядав.
Я припускав, що така війна могла б тривати чотири-п’ять років, перш ніж сторони дійшли б до перемир’я або одна з них перемогла б. Зростання після війни спершу виглядало б швидким через низьку базу порівняння. Повернення до довоєнного рівня я оцінював у десять-п’ятнадцять років або довше. Найгіршим у цьому сценарії мені здавалося застосування зброї масового ураження. Дай Боже, щоб цього не сталося.
У 2010 році світова війна за описаним сценарієм не почалася. У 2014 році Генасамблея ООН підтвердила територіальну цілісність України й закликала не визнавати зміни статусу Криму на підставі так званого референдуму. Після повномасштабного вторгнення 2022 року Генасамблея засудила російську агресію та зажадала виведення російських військ. Ризик нападу Росії, який непокоїв мене у 2009 році, був реальним. Подальші події мали іншу хронологію і самі по собі не доводять припущень про мотиви, перебіг чи наслідки, які я описував тоді.
Демонстраційна база швидко відкривається, презентація переконлива, а справжня перевірка починається перед відправленням машин: склад проводи...
