Александр Лыкасов, в той Вере громко хвалились, как закрыли (некритичные для меня) ошибки в ТС и тихо наделали своих собственных. Причем, по косвенным признакам - улучшения "курировались". Так что я не вижу смысла менять проверенный ТС на "улучшенную" Веру.
mayton2019, до сих пор храню то, что нужно переносить на флешке, но не должно утечь, если я ее потеряю, в контейнере TrueCrypt. Не только открытый софт, но и прошедший аудит, не выявивший ни багов, ни закладок. Правда, после (а может, и вследствие) этого проект быстренько свернули ;)
А точно - ничего не сделать? Просто открыть это шаманство в gparted и переформатировать раздел из той Страшно Секретной ФС, которую поддерживает только драйвер на другом разделе, в FAT32 - нельзя?
Впрочем, без всего этого обвеса просто теряется смысл брать именно эту флешку.
На фрилансе мне будут давать на половину сделанный проект, а мне уже останится дописать Бэк и теги шаблонизатора по ходу, и на Ajax js. Ведь также все!?
Ну, разве что еще спросят, сколько сахару в кофе положить, чтобы вы не перетрудились, считаючи. Все заказчики на фрилансе ведут себя крайне предупредительно и тщательно изучают дыры в образовании соизволившего до них снизойти фрилансера.
Где вы вообще увидели такое описание?
На офсайте про эту флешку вообще ничего сверх обычного бла-бла про скорость, надежность и дизайн.
Аппаратное шифрование заявлено у DataTraveler Locker - но и там "пользователь может установить пароль".
Разработчики МойОфиса признают заимствование кода Тандерберда, но утверждают, что остальной свой офис писали сами.
Р7-Офис - это разработчики ОнлиОфиса, продающие в РФ под другим брендом то, что бесплатно раздавали в Европе. Видимо, именно из-за этого и сменено название. https://www.linux.org.ru/news/proprietary/16736494...
Впрочем, я предпочитаю LO и всем рекомендую того же ;)
AlexVWill, вполне возможно, что Realtek RTL8822CE у него тоже еще на этой установке не работает ;)
Если уж человек взялся изучать линь, как-нибудь с изменением одной строчки в конкретном файле справится. Не на этой установке - так на следующей. Я в него верю.
Народ жалуется на аналогичные глюки в 22.04 на встроенной интеловской графике - похоже, очередная регрессия в обработке механизма энергосбережения процессора.
Лечат отрубанием лишних режимов при загрузке: https://askubuntu.com/questions/1404771/screen-fli...
Александр Фалалеев, особенно не стоит путать жалкие потуги как-то упорядочить живой и слабо упорядоченный язык типа вордовского волнистого подчеркивания с реальной проверкой чего бы то ни было на правильность.
Оно уже на одной этой фразе может сломаться ;)
Максим Федоров, я и подтвердил, что в этом случае сеттер неуместен.
Но он уместен там, где какие-то (ни на что больше не влияющие) данные все-таки надо задавать извне. Как альтернатива публичному полю.
vitaly_74, боги, ну это же совсем примитивный пример. Ну, представьте, что заголовки таки назначаются в одном методе, а запрос делается в другом.
Или вы предпочитаете представить подобные проблемы в потрохах современного фреймворка, где классы вызывают друг друга по прописанным совсем в другом месте цепочкам вызовов с определением того, с чем вообще сейчас работаем, по записанному при инициализации списка значению Class::class?
vitaly_74, например, класс-обертка над курлом Curl.
Вызывающий код может задавать массив $curl->headers, который класс-обертка тупо отправит в запросе, ничего внутри себя не меняя.
Создав метод Curl::setHeaders, вы можете быть четко уверены, что нигде больше в коде заголовки запроса не менялись. Не проверяя значения переменных в каким-то образом работающей неподалеку строчке $$one->$two = $three; %)
..там, где значение переменной важно для какой-либо иной логики в классе.
Если же это просто значение, которое может меняться снаружи и ничего при этом не затрагивает внутри - сеттер и геттер уместен для контроля обращения к этой переменной. Просто потому, что интерпретируемые языки позволяют обратиться к полям класса довольно кучерявыми и неочевидными способами, и для чистоты кода важно удерживать программиста от их использования.