W dzisiejszym wydaniu porozmawiamy sobie o problemach asystentów głosowych, nowym narzędziu od twórcy brew oraz dlaczego nikt nie kocha Stable Diffussion 2.0.
1. Asystenci głosowi to nieudany eksperyment? Amazon i Google po cichu wycofują się z rynku
Nie jest sekretem, że rynek nam się obecnie trochę kurczy, zwłaszcza w porównaniu do boomu, jaki przyniósł 2021. Co jednak w praktyce oznacza fakt, że taki Amazon zwalnia 10 000 ludzi? Z jednej strony sporo mówi się o tym, że firmy były po prostu mocno spasione i obecna sytuacja pozwala im w łatwy, szybki sposób pozbyć się niedochodowych działów, projektów i ludzi. Z drugiej – tak głębokie cięcia wiążą się z redukacją inwestycji, zwłaszcza takich, które dalekie są od monetyzacji. Gdy zaś obie te hipotezy zejdą się w pół drogi, pozwolą nam znacznie lepiej zrozumieć to, co dzieje się z rynkiem asystentów głosowych.
Coś, o czym przebąkiwało się przez lata, zostało wreszcie oficjalnie powiedziane – Amazon Alexa to porażka, worek bez dna i przy ostatnich zwolnieniach w Amazonię to właśnie ta dywizja oberwała najbardziej. Tylko w pierwszym kwartale tego roku, ta dywizja Amazonu straciła 3 miliardy dolarów i dlatego, gdy tylko zaczęły się zwolnienia, to ona właśnie oberwała jako pierwsza. Okazuje się, że mimo prawie dekady na rynku, Amazonowi nigdy nie udało się zmonetyzować asystenta głosowego. Zespół Alexa sprzedawała swój – naprawdę fantastyczny – hardware Echo ze stratą, żeby później odrobić sobie go w inny sposób. Trochę jak jest to z drukarkami, konsolami do gier, czy czytnikami Kindle. Niestety, Amazonowi nigdy nie udało znaleźć skutecznego sposobu na zmonetyzowanie swojej przynoszącej raty technologii.
To co, dla konkurencji otwiera się okazja przejęcia sporej ilości rynku od istniejącego lidera? W lepszych czasach pewnie by tak było, ale gracz numer dwa – czyli Google Assistant – nie do końca wydaje się być tym zainteresowany. Już w październiku dochodziły nas bowiem sygnały o tym, że Google zamierza ograniczać wydatki zarówno na własny hardware sygnowany brandem Pixel, jak i Asystenta właśnie. Takowy miał się w końcu stać centrum naszego obcowania z technologią, a tak naprawdę nigdy nie wyszedł z wąziuteńkiej niszy obsługi urządzeń domowych. Po prostu Asystenci głosowi nigdy nie dostali żadnego „Killer Appa”.
Smuteczek. Przyznam, że wizja futurystycznych asystentów i inteligentnej przestrzeni rodem z Jetsonów była dla mnie wybitnie kusząca. Jednak mam wrażenie, że ten czas po prostu jeszcze nie nadszedł, a biorąc pod uwagę ile pieniędzy wpakowano w te ekosystemy przy mizernym zwrocie – może się okazać, że zanim kolejny raz ktokolwiek się za temat weźmie, to już będzie to za czasu moich prawnuków.
Źródła
- Amazon Alexa is a “colossal failure,” on pace to lose $10 billion this year
- Report: Google “doubles down” on Pixel hardware, cuts Google Assistant support
Zainstaluj teraz i czytaj tylko dobre teksty!
2. Tea – (nie)Manager Pakietów jeden, by wszystkimi rządzić
Jak pewnie przebija się przez te przeglądy jestem (przyznam, dość zadowolonym) użytkownikiem systemu macOS. Do wspomnianego zadowolenia z pewnością przyczynia się narzędzie, które nazywa się brew. Dla tych, którzy go nie kojarzą – jest to społecznościowy manager pakietów, który jak do tej pory jest chyba moim ulubionym narzędziem tego typu na jakimkolwiek systemie i zawsze jest pierwszą rzeczą, którą instaluje zaraz po jakiejkolwiek instalacji systemu na świeżo. Dlatego też kiedy usłyszałem o tea, nowym narzędziu od twórców brew, nie mogłem sobie odmówić spróbowania, czym to się je (a raczej pije).
Czym jest tea cli? Jak piszą twórcy, zamiast managera pakietów mamy do czynienia z zunifikowaną infrastrukturą pakietów. Co to oznacza w praktyce? tea został napisany w taki sposób, że potrafi pod spodem używać managerów innych ekosystemu, stanowi więc wspólną abstrakcje nad innymi pakietami. Dodatkowo, wprowadza do wszystkiego koncept wirtualnych środowisk i izolowania pakietów, znany pewnie dobrze choćby wszystkim programistom Pythona.
Kontrowersyjnym w całym projekcie jest to, że twórca próbuje wpisać go w cały ruch dziejący się dookoła Web3 i zaimplementować protokół oparty o blockchainie, umożliwiający wynagradzanie twórców OpenSource poprzez zapisywanie na łańcuchu „redystrybucji wartości”, jakim jest używanie oprogramowania Open-Source przez firmy for-profit. Idea jest szczytna, ale czy im się finalnie uda, czas pokaże. Po spektakularnym updadku FTX, nie jest to chyba dobry czas na promowanie się decentralizacją i distributed ledgerami. Jeśli jednak jesteście ciekawi, jaki twórcy mają pomysł – możecie przeczytać Whitepaper.
Kontynuując temat narzędzi shellowych, tak na szybko chciałem Wam podrzucić inne, które wpadło mi w zeszłym tygodniu w ręce. Cheat.sh to nie jest jakiś nowy projekt, ale przyznam, że wcześniej o nim nie słyszałem, a wydaje się rozwiązywać naprawdę konkretny problem – fakt, że nikt nie jest w stanie spamiętać tych wszystkich flag, często niezbędnych do poprawnego używania programów shellowych. Sam od lat używam tldr.sh, ale cheat.sh wydaje się być dla niego interesującą alternatywą, z masą przydatnych integracji.
Nie każdy jednak lubi używać terminala, więc może istnieją jakieś alternatywy „okienkowe”? W zeszłym tygodniu trafiłem na tekst How I’m a Productive Programmer With a Memory of a Fruit Fly, którym chciałem się z Wami podzielić. Opisuje on program Dash – jedno z pierwszych narzędzi, które kiedykolwiek zainstalowałem na MacOS, żeby potem w zasadzie nigdy się do niego nie przekonać i przestać używać. Dash jest bowiem agregatorem i przeszukiwarką dokumentacji programistycznych. Całość znajdziecie na każdej liście „najlepszego oprogramowania dla programistów”, ale osobiście zawsze czułem się nim przytłoczony i nigdy nie stał się on częścią mojego codziennego workflow. Czytając tekst Hynek Schlawacka mam wrażenie, że wynika to z tego, że nigdy nie włożyłem w niego odpowiedniej ilości serca. Sam artykuł przedstawia taką ilość przydatnych trików i integracji, że chyba spróbuje narzędziu drugą szansę.
Ale powiedzmy sobie szczerze – epoce wszędobylskiego AI, cheat.sh i Dash wydaje się być technologią A.D. 2010. Aby podsumować temat nowych narzędzi konsolowych, to podczas tego tygodniowej konferencji GitHub Next firma pokazała
Github Copilot CLI. Nowa edycja, zamiast pisać za nas kod, podpowiadać ma nam jakiej komendy powinniśmy użyć, żeby wykonać konkretne akcje w terminalu. Nie jest to nowa funkcjonalność, której wcześniej nie znaliśmy – sam używam terminala Warp, który posiada taką wbudowaną możliwość – ale dla tych, którzy nie chcą pozbywać się znanego sobie narzędzia tylko po to, żeby AI podpowiedział im jakie parametry użyć, aby prawidłowo rozpakować archiwum, powinni być zadowoleni.
Źródła
- tea cli
- A Decentralized Protocol for Remunerating – the Open-Source Ecosystem
- How I’m a Productive Programmer With a Memory of a Fruit Fly
- Github Copilot CLI
- Cheat.sh
Zainstaluj teraz i czytaj tylko dobre teksty!
3. Dlaczego wszyscy nienawidzą Stable Diffusion 2.0
Było o Copilocie, to teraz w płynny sposób przejdźmy sobie do modeli grafiki generatywnej, ponieważ… dzieje się.
Moje ukochane MidJourney, bez dużego szumu, opublikował nową wersje swojego modelu (–v 4) i ta jest po prostu niesamowita. To, czym jarałem się pół roku temu, a co jest możliwe dzisiaj powoduje u mnie mały zawrót głowy. Żeby zobrazować Wam, o jakim przeskoku mówimy:
vs
No co Wam powiem, ja mam tylko jedną reakcje na to: 🤯
Od razu też powoduje u mnie zastanowienie nad losem tych wszystkich biednych grafików koncepcyjnych. Ci zresztą też zauważają problem i coraz głośniej przebija się nawoływanie do wejścia na drogę sądową z twórcami algorytmów, które wykorzystują ich dorobek do uczenia się, jak powinna wyglądać grafika.
Twórcy algorytmów, czując nosem problem, postanawiają zrobić ucieczkę do przodu – i nie wszyscy użytkownicy ich produktów są zadowoleni.
W zeszłym tygodniu pojawiło się drugie wydanie modelu Stable Diffusion. Poza dodatkowymi funkcjonalnościami, takimi jak in-painting czy super resolution, największe zmiany zaszły pod maską. Otóż do tej pory w zasadzie wszystkie modele używały pod spodem enkodera CLIP – zbioru cech wyuczonego przez OpenAI. CLIP miał jednak problem z transparentnością – tak naprawdę nie były bowiem znane zbiory danych, na którym był trenowany. Sprawiało to, że wspomnieni wyżej artyści mogli się domyślać, że do nauki wykorzystane były ich prace – co można było zauważyć choćby przez fakt, że podając w promptcie do modelu konkretnego artystę (jak w moim powyższym przypadku z HR Gigerem), uzyskiwaliśmy pracę bardzo zbliżone do jego unikalnego stylu. Stable Diffusion tworząc OpenCLIP – swój nowy enkoder – co prawda nie pozbyło się niby tego typu prac. Po pierwsze jednak – wyrzuciło olabelowanie konkretnych obrazów danymi ich twórców (przez co przestało działać „in style of”), po drugie umożliwiło zgłoszenie konkretnych fragmentów zbioru danych do usunięcia, jeśli twórca czuje, że naruszone zostały jego prawa autorskie. Po trzecie zaś, pozbyto się większości grafik NSFW – Stable Diffusion zostało znacznie „ugrzecznione” w stosunku do oryginału. Więcej detali znajdziecie w moim nowym ulubionym newsletterze – The Algorithmic Bridge.
Najzabawniejsze w całej sytuacji jest to, że ze zmiany nie jest zadowolony tak naprawdę nikt (poza prawnikami Stable Diffusion). Użytkownicy Stable Diffusion narzekają na cenzurę i fakt, że model zamiast być coraz lepszy, z ich perspektywy uległ pogorszeniu. Ruch ten nie do końca zadowoli też pewnie artystów – fakt, że modele kradły ich indywidualny styl z pewnością był problematyczny, ale tak naprawdę dużo większych wyzwaniem jest fakt istnienia generatywnych modeli. Te uczą się szybko i potrzebują coraz mniejszej ilości próbek, aby się ulepszać dalej. Do tej pory można je było oskarżyć o łamanie prawa autorskiego, ale ruch Stable Diffusion i transparencja użycia dodatkowo wybija im argumenty. Bo to, że model dzisiaj jest nieco gorszy od poprzednika? Zobaczycie co się będzie działo za pół roku…