przystajnik

NixNote 2 – kolejna faza zbieractwa

Świat oszalał na punkcie zbieractwa. My gromadzimy pliki, korporacje gromadzą nasze dane, wszyscy zbierają całą resztę. Najnowszym krzykiem mody jest zbieranie naszych notatek. O ile zapiski na boku to nic zdrożnego, o tyle trendy poszły w stronę wysyłania ich na zewnętrzne serwery. Ale jakby nie przeklinać tej całej chmury to niekiedy dobrze jest zalogować się na innej maszynie i mieć dostęp do swojego rozkładu zajęć lub innych informacji. Dlatego takim uznaniem cieszy się klient Evernote, który niestety nie występuje w wersji dla Linuksa. Niemniej twórcy udostępnili API obsługi konta i notatek. Kwestią czasu było kiedy pojawią się niezależne implementacje klienta do obsługi tego. NixNote 2 (poprzednio Nevernote) to właśnie taki reprezentant (z tradycjami) filozofii „zrób to sam”.

NixNote 2

Koncepcja Evernote jest prosta. Robisz notatki, synchronizujesz je ze swoim kontem na ich serwerach, masz do nich dostęp z każdego miejsca i każdej maszyny. Teoretycznie, bo jak wspomniałem ekipa stojąca za Evernote nie czuje się na siłach stworzyć natywnego klienta swojego programu dla Linuksa. Tę lukę uzupełniły osoby stojące za klientem NixNote który pojawił się już 6 lat temu. Od tego czasu przebył burzliwą ścieżkę rozwoju i w najnowszej odsłonie NixNote 2 jest już projektem napisanym w C++ (zamiast poprzedniej implementacji w Javie). Lista jego możliwości również obejmuje wszystko, czego powinniśmy oczekiwać po takim kliencie:

  • synchronizacja z serwerami Evernote (łącznie z zakładaniem nowego konta, itp.),
  • lokalna pamięć podręczna dla naszych notatek,
  • obsługa notatników lokalnych lub synchronizowanych,
  • możliwość zakodowania lokalnej bazy danych,
  • w pełni multiplatformowy projekt (w przeciwieństwie do oryginalnego klienta Evernote).

Wobec powyższego nie pozostaje nam nic innego jak zainstalować ten ciekawy programik. O ile oczywiście odczuwamy potrzebę robienia zapisów, ewentualnego synchronizowania ich oraz otrzymywania powiadomień o terminach (które możemy ustawić dla zdarzeń).

W przypadku Ubuntu 16.04/16.10, Minta 18.xx i pochodnych wykonujemy:

sudo add-apt-repository ppa:nixnote/nixnote2-daily
sudo apt-get update
sudo apt-get install nixnote2

Dla Manjaro i Arch Linuksa posiłkujemy się repozytorium AUR:

yaourt -S nixnote-beta 

Post navigation

16 comments for “NixNote 2 – kolejna faza zbieractwa

  1. MiloszI
    3 stycznia, 2017 at 12:12

    Używam od jakiegoś czasu Googlowego Keep. Klient dla Chrome załatwia sprawę.

  2. ⲼⲶ
    3 stycznia, 2017 at 13:18

    Usługi Google załatwiają sprawę. Do momentu gdy od czasu do czasu nie stwierdzą, że są one zbędne i może jednak je zamkną…

  3. pavbaranov
    3 stycznia, 2017 at 13:37

    Niestety – instalując dzisiaj nixnote-beta w Archu (i każdej jego zaktualizowanej pochodnej) – uruchomienie programu nie będzie możliwe (nixnote-beta to przedbudowana binarka z deb). W wolnej chwili się pobawię – może się uda to skompilować poprawnie.

  4. MiloszI
    3 stycznia, 2017 at 13:48

    To się może stać również z Evernote. Poza tym zawsze można je wyeksportować. Google zazwyczaj ładnie takie tematy załatwiają. Pamiętasz zamknięcie Google Reader? Można było ładnie ściągnąć listę źródeł informacji, Feedly nawet automatycznie potrafił je zassać.

  5. Jarek W
    3 stycznia, 2017 at 15:15

    Korzystam z Evernote w pracy zarówno na windows jak i w telefonie z androidem – spisuje się wyśmienicie. Wreszcie w domu na linuxie będę mógł nadgodzinki porobić 🙂

  6. 3 stycznia, 2017 at 15:54

    Przebudowana binarka z deba? Co się porobiło z tymi ludźmi!?

    Wykonujesz świetną robotę ze swoimi custom-PKBUILDami – może warto je podesłać opiekunom tych pakietów? Bo uruchamiać piątą czy szóstą wersję tego samego programu w repo raczej nie chcemy 🙂

  7. pavbaranov
    3 stycznia, 2017 at 16:37

    Dzięki za dobre słowa.
    Wiesz – w zasadzie to gdyby mi się chciało – to mógłbym je wrzucać na AUR. Mam z tym jednak kilka „kłopotów”/wątpliwości. Wrzucę u siebie na bloga.
    Natomiast – fakt – jakość niektórych PKGBUILDów w AUR woła o pomstę do nieba. Niestety. To, że jakaś paczka jest przebudowana z deb na pkg.tar to nic dziwnego, gdyby nie… istnienie źródeł. Wprawdzie istnieje nixnote2-git, budowane ze źródeł, ale w dość archaicznej wersji (bo na Qt4, co wg mnie mija się obecnie z celem, a nadto bardzo dziwnie ma poustawianą sekcję package; z tego co widziałem gość próbował robić to w katalogu build, ale z te źródła akurat tego „nie lubią” i nie zbudują pakietu, ani nie zainstalują się w „tradycyjny” sposób budowane w build). Tak, czy inaczej – mam nadzieję, że komuś się to przyda.

  8. ⲼⲶ
    3 stycznia, 2017 at 23:26

    gimp-plugin-registry też jest przebudowywane z deba, właśnie zauważyłem. Masakra jakaś. Niewykluczone że z uwagi na KDE neon jeszcze przeproszę się z debianowatymi.

  9. pavbaranov
    4 stycznia, 2017 at 9:01

    Akurat przebudowanie tej paczki jest jak najbardziej „wskazane”; jeśli dobrze widzę nie zawiera ona żadnych binarek do zbudowania.
    Zresztą samo przebudowywanie paczek binarnych nie jest jakimś wielkim grzechem. W „debianowatych”, rpm, czy Slacku masz narzędzie alien, które służy do konwertowania paczek między nimi. Dzięki przebudowaniu paczek masz np. sterowniki do Brothera (te są bowiem praktycznie tylko w deb i rpm). Dzięki temu możesz też oszczędzić czas na budowanie takich kobył jak firefox, czy libreoffice w wersjach, których nie ma w repozytoriach (np. testowych; budowanie takiego LO ze źródeł trwało u mnie kiedyś praktycznie cały dzień, tworząc od czasu do czasu testowe wersje – jak obecną 5.3.0 z rpm – trwa to dosłownie chwilę). W przypadku różnego rodzaju paczek „uniwersalnych” otrzymujesz również gotową binarkę. Nic w tym zdrożnego, o ile przebudowanie jest prawidłowe.
    Akurat brak możliwości uruchomienia nixnote-beta wczoraj był wynikiem innej paczki libcurl-compat w obu dystrybucjach. Wczoraj wieczorem libcurl-compat dostał jakiś upgrade w Archu – być może już uruchamianie nixnote-beta jest możliwe z tego skryptu w AUR; natomiast – ze względu na lokalną budowę ze źródeł z PKGBUILDu zaproponowanego przeze mnie winno ono być zawsze możliwe, co najwyżej po jakichś zmianach (np. libcurl-compat) będzie wymagać przebudowy – to normalne.
    W Neonie możesz spotkać się z podobną sytuacją dotyczącą wszystkich paczek, które nie są dostarczane w repozytorium Neon, a które oparte są o KF5/Qt5. Możesz się bowiem spotkać z tym, że paczka deb, która została zbudowana na komponentach w repozytoriach Ubuntu nie będzie chciała współpracować z tymi komponentami, które są w repozytorium Neon. Wolę sytuację z Archa (bo prościej), ale oczywiście to Twój wybór. Alternatywą dla Archa (nie licząc Gentoo) jest dla mnie obecnie w zasadzie wyłącznie Zuśka w wersji Tumbleweed (chyba, że decydowałbym się na 18 mies. z Plasma 5.8, to wówczas Leap).

  10. Tavin
    5 stycznia, 2017 at 9:38

    Ja używam leanote, aczkolwiek to bardziej aplikacja webowa.

  11. PluszowyMis
    7 stycznia, 2017 at 22:07

    my pliki. firmy dane. a zule zbierają złon choć ostatnio ich niewidać . chyba juz się nieopłąca zbierac

  12. megaziuziek
    7 stycznia, 2017 at 22:38

    złon się nie opłąca.
    złom jeszcze się opłaca..
    No i faktycznie jakoś tak od roku ponad trochę żuli nie widać…

  13. Przemek
    8 stycznia, 2017 at 10:39

    Jeżeli ktoś dba o prywatność, nie dotknie Evernote. Pracownicy firmy mają dostęp do notatek prywatnych.

  14. Jarek W
    16 stycznia, 2017 at 15:34

    Nie rozumiem w jaki sposób? Mógłbyś rozwinąć temat.

  15. megaziuziek
    16 stycznia, 2017 at 22:53

    W normalny.
    Lepiej używać cherrytree.Bardzo dobry,i trzyma pliki lokalnie.Można używać szyfrowania.

  16. pavbaranov
    17 stycznia, 2017 at 8:16

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Translate »