VSCodium na Debianie

Jak pisałem wcześniej, nadchodzi koniec edytora Atom. Z pewnych względów, na maszynie służbowej i tak zacząłem korzystać z Visual Studio Code . Dlatego postanowiłem przyspieszyć proces migracji także na prywatnej maszynie. VSC nie było złe, więc zgodnie z zapowiedzią dałem szansę VSCodium.

Czym jest VSCodium?

VSCodium to fork microsoftowego Visual Studio Code, zbudowany z otwartego kodu źródłowego, dostępny na wolnej licencji. Dodatkowo pozbawiony dodatków od Microsoft służących do zbierania telemetrii/śledzenia. Poza tym, wszystko powinno działać tak samo.

VSCodium logo
Źródło: https://vscodium.com/

Instalacja VSCodium

Na początek instalacja pod Debianem. Z tego co widzę, na Ubuntu będzie identycznie. Szczęśliwie dostępne jest repozytorium pakietów deb. Skorzystałem z opisu instalacji spod tego linka: https://www.linuxcapable.com/how-to-install-vscodium-on-debian-11-bullseye/. Wersja skrócona poniżej.

Dodajemy klucz GPG do zaufanych:

curl https://gitlab.com/paulcarroty/vscodium-deb-rpm-repo/raw/master/pub.gpg | gpg --dearmor > /etc/apt/trusted.gpg.d/vscodium.gpg

Dodajemy źródło pakietów:

echo "deb https://download.vscodium.com/debs vscodium main" > /etc/apt/sources.list.d/vscodium.list

Po tym zostaje już tylko aktualizacja danych o repozytoriach i instalacja pakietu codium:

apt update; apt install codium

Wtyczki z marketplace

Nieprzypadkowo napisałem, że wszystko powinno działać tak samo. Słowo powinno powinno dać do myślenia. Otóż po instalacji pozwoliłem sobie „ściągnąć” konfigurację, a w zasadzie używane wtyczki, z marketplace od kolegi z pracy, korzystającego z VSC. Mocno się zdziwiłem, bo większość potrzebnych wtyczek, tych od Microsoft, nie była w VSCodium dostępna do instalacji. Nie drążyłem wtedy tematu i po prostu zainstalowałem VSC.

Jednak po szybkim zbadaniu tematu okazuje się, że nie ma najmniejszego problemu z korzystaniem z marketplace Microsoft w VSCodium. Zgodnie z tym, co piszą w dokumentacji, wystarczy w pliku

~/.config/VSCodium/product.json

dodać stosowną zawartość, czyli:

{
  "extensionsGallery": {
    "serviceUrl": "https://marketplace.visualstudio.com/_apis/public/gallery",
    "cacheUrl": "https://vscode.blob.core.windows.net/gallery/index",
    "itemUrl": "https://marketplace.visualstudio.com/items",
    "controlUrl": "",
    "recommendationsUrl": ""
  }
}

I możemy cieszyć się dostępem do wtyczek zupełnie jak w Visual Studio Code.

Wtyczki

Nie ukrywam, że bardziej podobało mi się działanie wtyczek w Atomie. Na przykład isort wywołany tamże po prostu sortował wszystkie importy. W przypadku VSC nie ma tak dobrze. Z tego co udało mi się znaleźć, można „naprawić” pojedynczy import.

Istnieje obejście, które jest podpowiadane w opisie konfiguracji wtyczki, czyli dodanie do settings odpowiedniej sekcji. Jest to nieco nieintuicyjne, bo w czytamy to będąc w… ustawieniach, czyli settings. Chodzi jednak o inne settings. Jak znalazłem pod tym linkiem, trzeba zmienić zawartość pliku

~/.config/Code/User/settings.json

Na razie tyle. Z doświadczeń w pracy wynika, że spokojnie da się żyć z VSC zamiast Atoma. Na razie pracuje mi się w VSC gorzej, ale raczej chodzi o drobną zmianę przyzwyczajeń i dokładniejsze poznanie nowego programu. Z wyboru zamiennika jestem wstępnie zadowolony.

Goodbye Atom

W roku 2014 pojawił się a hackable editor for the 21st century czyli Atom. Od początku mnie zaintrygował. Był to edytor międzyplatformowy, open source, działający w GUI, reklamowany jako rozszerzalny… Samo dobro. Pobrałem i… skasowałem, ze względu na rozmiar. Ważył bowiem grube kilkadziesiąt MB, co wydało mi się sporą przesadą.

Screenshot ze strony projektu
Screenshot ze strony projektu. Źródło: https://atom.io/

Później jednak przekonałem się do Atoma, a nawet go polubiłem. Uzbrojony w pluginy był bardzo przyjemnym narzędziem wspomagającym edycję różnych formatów plików. Więcej, niż edytorem, bardziej traktowałem go jako IDE. Choć z rasowymi IDE nie mam doświadczenia. Czy to Python, Puppet czy zwykłe YAMLe – wszystko edytowało się przyjemnie, ze stosownym kolorowaniem, linterami itp. Pamiętam, że na jednym ze szkoleń z Pythona śmiało współzawodniczył z PyCharm. IIRC wówczas jednej rzeczy nie dało się zrobić w Atomie, i jednej w PyCharmie. W każdym razie, niczego mi w Atomie nie brakowało.

Dlatego w ogłoszeniu o wygaszeniu projektu zdanie Atom has not had significant feature development for the past several years wydaje mi się dwuznaczne. Skoro program ma wszystko, co potrzebne, to co tu rozwijać? No i jeśli oparty jest o wtyczki – a tak było w przypadku Atoma – to ficzery w samym programie też stają się drugorzędne.

Tak czy inaczej, decyzja mnie nie dziwi. Skoro Microsoft ma swoje Visual Studio Code, to będzie je promował, więc po co mu wewnętrzna konkurencja? Artykuł wspomina właśnie VSC jako alternatywę. Zapewne nieprzypadkowo. Z drugiej zaś strony jak robiłem przegląd ewentualnych alternatyw w głowie, to VSC jak najbardziej się pojawiło.

Nie ukrywam, że mam pewien sentyment do Atoma i parę wspomnień z nim związanych. Towarzyszył mi przy nauce Pythona, która zbiegła się ze zmianą pracy. Był nieodłączną częścią DSP2017.

Potem spojrzałem na listę alternatyw i… nie jest wiele lepiej. Nie widzę żadnego następcy czy też zastępcy. Chwilowo najbardziej skłaniam się ku wolnej wersji VSC czyli VSCodium. Ale to bez pośpiechu. W końcu Atom jest open source, więc może jednak okaże się, że będzie utrzymywany.

UPDATE Polecę jeszcze wpis, który właśnie przeczytałem. Nie o edytorze, a o desktopie, ale jest i o edytorach (vim).

Delegalizacja noży

Czy noże są legalne? Odpowiedź jest nieoczywista, w przypadku noży fizycznych i różni się mocno między państwami. Wygląda na to, że delegalizacja noży to etap do którego dotarła nasza cywilizacja. Przynajmniej w przypadku oprogramowania. Noże są metaforą, chodzi o narzędzia w postaci oprogramowania.

Tym razem wirtualnym nożem został program youtube-dl. W całej sprawie chodzi o zamknięcie jego repozytorium na GitHubie po otrzymaniu niedawnego żądania usunięcia na podstawie DMCA. Polecam lekturę, mi uzasadnienie wydaje się ciekawe – oprogramowanie służy do omijania zabezpieczeń i robienia nieautoryzowanych kopii. I rzekomo posłużyło do zrobienia nieautoryzowanych kopii artystów zrzeszonych w RIAA. W to ostatnie akurat jestem skłonny uwierzyć.

Zastanawiam się jednak nad pierwszą częścią. Pobranie z YouTube jest możliwe przy pomocy wielu narzędzi. Potrafi to każda przeglądarka internetowa. Kopię można zrobić smartfonem. O masie oprogramowania dedykowanego do odtwarzania multimediów, w tym z YouTube nie wspominam. Poza tym, w grę wchodzi dowolne oprogramowanie do rejestracji obrazu, nagrywania dźwięku czy nagrywania pulpitu. Tak wiele noży do zdelegalizowania…

Zresztą, celem umieszczania materiałów na YouTube jest udostępnianie ich publicznie. Szczególnie jeśli nie są ustawione ograniczenia widoczności, czyli materiał jest publiczny. A może znowu chodzi o reklamy i ich omijanie? Bo przecież narzędzie, czyli nóż może służyć do różnych celów. Na przykład do krojenia chleba. W przypadku youtube-dl mogę zrobić kopię własnych materiałów, które umieściłem na YouTube. Albo pobrać na dysk – legalnie w świetle polskiego prawa – materiały do ich odtwarzania bez zużywania transferu przez komórkę.

Sprawa jest głośna i zastanawiam się, jak się skończy ta próba delegalizacji noży. Czy usunięcie miało charakter automatyczny i zostanie wkrótce przywrócone? Całość jest ciekawa tym bardziej, że w grę chodzi GitHub jako miejsce do rozwijania oprogramowania. Jeśli usunięcie repozytorium zostanie utrzymane, to mogą być tu spore ruchy – ludzie mogą zacząć migrować na inne platformy. Smaczku sprawie dodaje fakt, że właścicielem GitHuba jest Microsoft, a YouTube Google.

UPDATE Program nadal można pobrać ze strony projektu, jest też dostępny w repozytoriach dystrybucji Linuksa.

UPDATE 2: O sprawie zdjęcia youtube-dl z GitHuba w kontekście legalnych zastosowań pisało EFF. Jest też artykuł w serwisie Torrentfreaks o odpowiedzi w postaci zamieszczania mp3. Oraz poruszona kwestia przeglądarek. Polecam.

UPDATE 3: Pojawił się ciekawy wpis na blogu pierwotnego autora youtube-dl w którym pisze o genezie projektu i realiach. Zachęcam do lektury.

UPDATE 4: Trwało to dłuższą chwilę, ale wygląda, że repo youtube-dl powróciło. Decyzja do przeczytania tutaj. Dłuższe uzasadnienie stanowiska GitHub. I zamierzają zmienić proces obsługi DMCA na bardziej przyjazny developerom.