Używa obu. LR ma wsparcie dla kontrolerów H/W, z szopą jest gorzej. Chociaż retusz raw w LR jest ciekawy, to mimo wszystko sporo kończy na korekcji w szopie (no moze poza totalną masówą)
No widzisz. A ciekawe co robisz? Bo ja jako grafik/motion designer mogę sobie pomarzyć póki co o korzystaniu z Linuxa do tych celów a też bym chciał zarobić.
I ponawiam pytanie. Jesteś devem. Jaką platformę wybierzesz i dlaczego?
Rozdrabnianie się na środowiska graficzne, panele sterowania, sklepy, kontenery - nie tędy droga. Ktoś musi mieć na tyle jaj i finansów, żeby swój jeden spójny produkt wprowadzić w szerszy obrót. Może to będzie KDE Neon, może Gnome OS, może Ubuntu. Ale raczej obstawiałbym na te dwa pierwsze, bo ten wybór środowisk, narzędzi itp dla ZU nie jest dobry.
I właśnie mam wrażenie, że w tym kierunku idą Deepin i ElementaryOS - forsują swoje ciekawe rozwiązania. To może się udać. Potrzeba teraz tylko jakości i niezawodności no i jak wspominałem, wygody i intuicyjności - wówczas mają szansę “ustrzelić” ten szerszy obrót. Ubuntu nie bez powodu było naj przez lata. Potem nie bez powodu koronę na lata skradł Mint.
Przykładowo EditShare kupił i wydał Lightworks na trzy platformy i utrzymuje wszystkie do teraz. Przy czym ich biznes nie żyje tylko z NLE, ale głównie ze storage i collaborative work (Flow), gdzie serwerami są jakieś os-y linuksowe. Dlaczego przeportowali NLE na linuksy - nie wiem, ale mogę spytać.
Jako dev wiem, że crossplatform to większe problemy. Ale wiem też, że więcej platform to większy rynek zbytu. Wiem też, że takie linuxy na gruncie NLE to nisza (dopiero ostatnio konkurencja weszła z Resolve) - można powojować o usera, a 1 user to potencjalniei 1 abonament.
I oto właśnie esencja problemu. Siedzę na Deepin 15.6.
Pobrałem Lightworks ze strony producenta. Zainstalował się bezbłędnie.
Odpalam…wisi na ładowaniu jakiegoś pluginu “PortAudio”. Puszczam z konsoli, by (mam nadzieję) zobaczyć jakiś komunikat - nic, program urywa się po ułamku sekundy. I zaczyna się klasyk - szukaj sobie userze rozwiązania twego problemu…
Esencją problemu jest to, że producent nie wspiera Deepin. Debian czy RedHat/CentOS to nie Deepin.
Problem PortAudio jest problemem zależności i dystrybuowania binarek (tu wszelakie FlatPaki pomogą, ale producent musi się do tego przekonać i poświęcić czas).
Rozwiązaniem “na szybko” jest pobranie najnowszej wersji beta 14.5, która dostarczana jest z odpowiednimi bibliotekami w odpowiednich wersjach (portaudio i curl, który też sprawiał kłopoty)
Dzięki, to faktycznie pomogło!
Czyli pozostaje trzymać się tego, co jest wspierane. A jest wspierane bo jest popularne a jest popularne, bo reprezentuje jakość i wartość użytkową.
Przez długi czas Resolve był dostępny tylko dla RHEL. Z resztą - teraz też bodaj RHEL lub CentOS są oficjalnie wspierane. Chyba wszyscy liczymy (jako konsumenci, użytkownicy), że taki flatpak będzie remedium na niekompatybilności cross-systemowe sprowadzając problem producenta do wydania jednej uniwersalnej paczki zamiast wielu na wiele systemów, i że producenci za jakiś czas przekonają się że to ma sens (może czekają na ustabilizowanie się i rozprzestrzenienie tego rozwiązania). Innymi słowy - liczymy, że Flatpak rozwiąże problem faworyzowania najatrakcyjniejszych systemów (co jest przecież subiektywną oceną i producentów, i naszą).
Na Deepin nie działa podgląd zaimportowanych mediów.
Myślę: dobra, nie wspierają, to zobaczę czy działa na Mincie.
Odpalam, tam podgląd działa, ale nie wyświetla się w oknie miniatury, tylko mniejsze i gdzieś w powietrzu obok.
Podobnie z samym odtwarzaniem z timeline - podgląd jest mniejszy i nie na swoim miejscu. Cóż, najwidoczniej HiDPI też LW jeszcze nie wspiera. I zabawne, że takie Adobe na Windzie bierze rozdzielczości UHD pod uwagę - tam nie ma najmniejszych problemów ze skalowaniem interfejsu - nic się nie rozłazi.To jest właśnie jakość…za pieniądze. Z ciekawości sprawdziłem też wersję LW na Windows…i proszę, jaka miła niespodzianka - miniatury wideo na swoich miejscach, na timeline podgląd też tam gdzie powinien być - wow, mogę pracować!
Dla mnie (póki co) linux to kompromis za kompromisem i systematyczne umniejszanie wygody użytkowania programów. Tak to właśnie wygląda. A chciałbym by jakość tych programów dorównywała tym z płatnych systemów.
Ciekawe dlaczego taki FreeOffice Writer, stosunkowo świeży, został napisany tak, by poprawnie się skalować w UHD a LibreOffice, które jest z nami od lat ma z tym problem. Może jego dojrzałość jest właśnie problemem? W sumie gdy go pisano, nikomu się UHD nie śniło…
Tu nie chodzi tylko o pieniądze, ale też o popularność i „ideologię”.
Np. taki Firefox na Windows długo miał opcje, które na GNU/Linux nie było i był wyższej jakości na Windowsie. Po prostu z GNU/Linuksów korzystało za mało osób. Chodzi o pieniądze, gdyż istnieje Mozilla Corporation, ale pewnie też o ideologię, bo wesprę system, z którego korzysta najwięcej naszych użytkowników.
O ideologię też chodzi wydawcą darmowego oprogramowania open-source na GNU/Linux. Nie wszystkie programy są na Windows (wbrew pozorom). Często skrypty basha nie są wydawane na Windows, bo jak? Dawniej programy typu Kadu nie był wydawany na Windows, bo nie chciało się ludziom i nie było rąk do pracy. Ta niechęć to powód ideologiczny trochę, bo program był tworzony również do użytku przez twórców, ale też trochę ekonomiczny, bo mając ograniczone zasoby, trzeba było coś wybrać (czyli nie wydamy wersji na Windows).
flatpak run com.github.unrud.djpdf
Unable to determine KDE dirs
Traceback (most recent call last):
File “/app/lib/python3.5/site-packages/dbus/bus.py”, line 175, in activate_name_owner
return self.get_name_owner(bus_name)
File “/app/lib/python3.5/site-packages/dbus/bus.py”, line 361, in get_name_owner
‘s’, (bus_name,), **keywords)
File “/app/lib/python3.5/site-packages/dbus/connection.py”, line 651, in call_blocking
message, timeout)
dbus.exceptions.DBusException: org.freedesktop.DBus.Error.NameHasNoOwner: Could not get owner of name ‘org.freedesktop.portal.Desktop’: no such name
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File “/app/bin/scans2pdf-gui”, line 9, in
load_entry_point(‘djpdf==0.0.4’, ‘console_scripts’, ‘scans2pdf-gui’)()
File “/app/lib/python3.5/site-packages/djpdf-0.0.4-py3.5.egg/djpdfgui/scans2pdfgui.py”, line 521, in main
File “/app/lib/python3.5/site-packages/djpdf-0.0.4-py3.5.egg/djpdfgui/scans2pdfgui.py”, line 457, in init
File “/app/lib/python3.5/site-packages/dbus/bus.py”, line 241, in get_object
follow_name_owner_changes=follow_name_owner_changes)
File “/app/lib/python3.5/site-packages/dbus/proxies.py”, line 248, in init
self._named_service = conn.activate_name_owner(bus_name)
File “/app/lib/python3.5/site-packages/dbus/bus.py”, line 180, in activate_name_owner
self.start_service_by_name(bus_name)
File “/app/lib/python3.5/site-packages/dbus/bus.py”, line 278, in start_service_by_name
‘su’, (bus_name, flags)))
File “/app/lib/python3.5/site-packages/dbus/connection.py”, line 651, in call_blocking
message, timeout)
dbus.exceptions.DBusException: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.portal.Desktop was not provided by any .service files
Ale nie łącz linuxa z tym, jak działa Lightworks. Problem skalowania da się bodaj skorygować, tylko że ręcznie (z głównego ekranu trzeba w opcjach dobrać skalowanie interfejsu). Tu Lightworks ma swój customowy “toolkit” do GUI, który ma swoje niedoróbk i będą one dotyczyły także innych systemów. Czasem są też problemy z overlays na niektórych GPU, dlatego EditShare rekomenduje wyłącznie Nvidie Quadro na sterownikach własnościowych.
Natomisat program nie jest na pewno dla każdego. Ma zupełnie odmienny UI i UX, nieporównywalny z niczym innym. Oddaje w zamian efektywność i oszczędność czasu podczas montażu. Trzeba poświęcić dużo czasu na naukę.
Jeśli nie zauwazyłeś…ten sam porgram, ta sama wersja, ten sam wydawca, ten sam hardware, tylko system operacyjny inny. Windows znów wygrał z Linuxem. Głupotka, bo głupotka, ale utrudniająca pracę. Tak jest właśnie z wieloma programami pod Linuxa - zawsze jakaś głupota przeszkodzi w bezproblemowym workflow.
Z czym? Z Linuksem? Prosiłem - nie kręćmy się w kółko, bo jestem bliski posądzenia cię o trolling. Twój system (Deepin, tak?) być może rodzi takie problemy. Być może jakiś GPU na Windowsie rodzi te same problemy. Być może beta Lightworksa ma takie problemy.
W bardzo prosty sposób przychodzą ci porówniania nie poparte żadnymi dowodami. Ten program ma specyficzną obsługę UI i GPU, jego toolkit ma pewne problemy, które bardziej zależą od chipu niż samego OS-a.
Nie wiem o jakim problemie dokładnie piszesz w kontekście zwycięstwa windowsa (w ogóle o co chodzi?). Lightworks na moim sprzęcie i moim systemie operacyjnym nie powoduje (lub nie zauważyłem?) takich problemów jakie opisywałeś. Ale coś kojarzę, że były jakieś zgłoszenia z miniaturami właśnie na windowsie, na forum betatesterów.
Analogicznie - na moim macu Lightworks działa gorzej niż na moim Manjaro (zwiechy i działa wolniej) - mam głosić, że (każdy) “Linuks” wygrywa nad (każdym) macOS/mac? Był czas, gdy Lightworks stwarzał problemy na W10 - miałem głosić, że (każdy) “linuks” wygrywa z (każdym) Windowsem?
Podaję Ci dowód, że kolejny raz program pod Linuxa (sprawdzone na dwóch niezależnych distro) robi więcej problemów niż pod Windowsa a Ty piszesz, że nie wiesz o co mi chodzi i że nie rozumiesz. Typowe dla zbetonowanych fanboyów Linuxa. Cieszę się, że Tobie pingwin problemów nie sprawia i że jesteś w siódmym niebie. Ja znów musiałem zapodać workaround:
Linuxa używam od 15 lat a Lightworks staram się używać od wersji 10.X. Ale już mniejsza o to. Ty jesteś zagorzały fan Linuxa a ja jestem fanem, ale widzę, gdzie leży spory problem z Linuxem i brakiem zainteresowania inwestowaniem w niego.
Oto odpowiedź chociażby Adobe, z którą w pełni się zgadzam z punktu widzenia korporacji:
Yes, we have gathered more user data. Nope, it hasn’t changed the market in a measurable way. There still is no significant market for commercial desktop software on Linux. Linux use is growing, but MacOS and Windows are growing much faster.
There is a market on Linux for server software. Just not so much for desktop software (I should have been more specific).
And Photoshop is few orders of magnitude more complex than the apps you first listed. Yes, the lack of standards and problems with APIs on Linux can be overcome – if you have a market that makes it worth the hassle.
There is no one, comprehensive checklist that I know of. But yes, lack of standards and lack of system provisions for things that should be system wide (like fonts and color) are stumbling blocks. They can be overcome, but the OS really should already have standards and handling for things like that. (and “pick the window manager of the month” doesn’t help, either)
Because there is no sign of the facts changing anytime in the forseeable future. If Linux users want to see a change they need to start by making the OS more attractive to porting (ie: stable, standardized APIs), and make the market more attractive (ie: be willing to pay for software).
Again, we’ve done the research. The profits aren’t there – very few Linux users are willing to pay for commercial software. And the cost of entry is still high because of the fragmented Linux landscape.
The Linux world has to change before commercial software will have reason to invest in Linux ports.
And we haven’t seen much real change in the Linux market in several years.