Czy wierzycie w idee Open Source i wolnego oprogramowania?

Na początku rozróżnijmy dwie rzeczy:

• Open Source tak jak robi to Red Hat lub Microsoft nie zawsze musi być darmowy.

• Wolne oprogramowanie jest jak Linux wydawane na licencji GNU.

Zaczynając z IT trafiłem na konferencje związaną z Open Source (Open Source Day) i zastanawiało mnie jak to możliwe że wielkie firmy tworzą oprogramowanie, do które źródła udostępniają za darmo. Dlaczego istnieją systemy komercyjne i darmowe i dlaczego na jednych i drugich się zarabia. Dla osoby w pierwszych latach technikum informatycznego było to zadziwiające.

#luźne przemyślenie
Jak to jest z bezpieczeństwem open source i closed source i czy firma utrzymująca rozwiązanie ma kilku developerów, którzy patrzą na kod lub open source, gdzie znacznie więcej osób przegląda ten sam kod przez co jest większe prawdopodobieństwo wykrycia błędów z uwzględnieniem luk bezpieczeństwa.

Co z architekturą?
Architektura systemów open source jest znacznie inna niż tych tworzonych z jednym budynku lub przez jeden zespół developerów, tam zazwyczaj są testy, system jest podzielony i ma dokumentację

Wierzycie w idee open source i to że nie należy brać pieniędzy za tworzony kod?
Przestałem wierzyć w idee open source gdy projekty open source były zamykane ze względu na łamanie ich licencji oraz jak twórcy nie byli wspierani przez społeczność za zarabiał ktoś inny

Pieniądze
Jak to jest z finansowaniem projektów otwarto źródłowych? OpenJDK, Linux, Pytohn to wszystko open source a jednak pieniądze mają więc firmą opłaca się płacić za rozwój open source jednak jest w tym wiele patologii bo nie ma uzasadnienia jak to rozliczać i zazwyczaj kończy się na wykupieniu wsparcia od firm zewnętrznych. Jakie benefity są z finansowego punktu widzenia z projektu opartego o open source lub closed source? Kiedy warto chronić własność intelektualną?

Oglądałem niedawno live KeySight odnośnie testowania automatycznego, uczestniczył w nim Steave Wozniak - zapytano go czy powinniśmy rozwijać swój projekt jako open source czy jako closed source. Odpowiedzi nie zrozumiałem dlaczego i jak rozwijać projekty open source i jakie są z tego benefity.

Jakie jest wasze zdanie? Wierzycie w open source? Commitujecie do open source?

Jestem wierzący, ale niepraktykujący.

Osobiście uważam, że to jest piękna idea i jedna z niewielu, gdzie ideały komunistyczne mają szansę zadziałać. Ktoś gdzieś pisał, że tylko 1 na 100 czy nawet na 1000 użytkowników daje coś od siebie dla samej idei i chwały, ale też w przypadku dóbr niematerialnych taki odsetek w zupełności wystarczy, żeby cały interes całkiem sprawnie się kręcił.

Otwartość pozwala na szybszy rozwój, korzystanie z i rozwijanie cudzych pomysłów. I przede wszystkim sprzyja tworzeniu spójnych systemów / protokołów, z których korzystają wszyscy i wszyscy zyskują. Całe fundamenty Internetu zbudowano przecież w taki właśnie sposób.

Popatrz na przykład e-maili, które powstały jeszcze w ramach tej właśnie filozofii. Używasz dowolnego klienta łączącego się z dowolnym serwerem, żeby wysłać wiadomość do dowolnego odbiorcy na dowolnym innym serwerze.

A teraz popatrz jaka koszmarna sieczka panuje w świecie komunikatorów, które zaistniały już w epoce komercjalizującego się internetu.

Ludzie są z natury leniwi, było o tym setki badań pewnie i jeszcze będą. To właśnie jest wykorzystywane przy zarabianiu. Ludziowi takiemu się nie chce. Zobaczy VoIP - darmowe rozmowy na swiecie, darmowe centrale w firmie, wystarczy posatwic sobie swoj serwer. Ale netia wziela to darmowe rozwiazanie i sprzedaje. Sprzedaje pakiet ze sprzetem , zserwerem, z dpstepem do serwerów na oabonament. Robią to bo innym sie nie chce. Maja kasa, sa wygodni i wierza ze firma ktora sie tym zajmuje zrobi to lepiej.

Tak jest ze wszystkim ,mozesz miec darmowego linuxa ale zaplacisz mi za skonfigurowanie poczty wychodzacejm wraz z fertyfikatami, baza emaili spamowych z ustawieniem revDNS zeby poczta nie trafiala do spamu bo potrzebujesz to zaplacisz.

Idea Open Source jest fajna bo masz bezpieczne podstawy w kodzie , duzo ludzi to sprawdza wiec lepiej miec armie 1000 osob niz 20 inzynierow w korpo. Na bazie Open Source budujesz produkt i sprzedajesz.

Ja teraz buduje bramke SMS, wszystko jest darmowe, ale siedze i kleje kod i robie z damrowych elementow produkt ktory wypuszcze na rynek. Kazdy moze go zrobic sam ale zapewniam cie ze nikomu sie nie bedzie chcialo

Freja Draco napisał(a):

Osobiście uważam, że to jest piękna idea i jedna z niewielu, gdzie ideały komunistyczne mają szansę zadziałać. Ktoś gdzieś pisał, że tylko 1 na 100 czy nawet na 1000 użytkowników daje coś od siebie dla samej idei i chwały, ale też w przypadku dóbr niematerialnych taki odsetek w zupełności wystarczy, żeby cały interes całkiem sprawnie się kręcił.

Ideały komunistyczne, czyli wielkie korporacje rozwijające lub fundujące oprogramowanie open-source?

Otwartość pozwala na szybszy rozwój, korzystanie z i rozwijanie cudzych pomysłów. I przede wszystkim sprzyja tworzeniu spójnych systemów / protokołów, z których korzystają wszyscy i wszyscy zyskują. Całe fundamenty Internetu zbudowano przecież w taki właśnie sposób.

Zwłaszcza strony działające tylko pod Internet Explorerem w wersji 5.

Popatrz na przykład e-maili, które powstały jeszcze w ramach tej właśnie filozofii. Używasz dowolnego klienta łączącego się z dowolnym serwerem, żeby wysłać wiadomość do dowolnego odbiorcy na dowolnym innym serwerze.

A teraz popatrz jaka koszmarna sieczka panuje w świecie komunikatorów, które zaistniały już w epoce komercjalizującego się internetu.

W emailach to nie ma sieczki? Np: https://en.wikipedia.org/wiki/Email_storm - co jakiś czas mamy taką imprezę w firmie. Same emaile są wysoce nieefektywne (jeśli chodzi o ich format zapisu). Jak jest dyskusja na 30 odpowiedzi to wszystko jest za każdym razem cytowane w mejlu (aczkolwiek można to wyciąć). Tragicznie jest jak ktoś osadzi zrzuty ekranu - taki zrzut ekranu jest potem kopiowany w nieskończoność. Jak odpowiadać na mejla? Niektórzy odpowiadają u góry, inni w środku, a jeszcze inni mieszają swoje odpowiedzi z oryginalnym mejlem. Brak jest jednolitego języka. Daty, etykiety i inne rzeczy są w mejlach wpisywane w różnych językach, co jest łatwo spotkać w międzynarodowym korpo. Strefy czasowe? Domyślcie się co to znaczy, że dostaliście mejla o 05:32, mimo że koleś po drugiej stronie świata siedział po godzinach. Integracja emaili z listami dyskusyjnymi czy np. GitHubem? Pozostawia często sporo do życzenia (problemy z cytowaniem, formatowaniem, załącznikami, diffami itd). Rozpoznawanie ciągu mejli w dyskusji? Loteria. Czasem klient emaila ogarnie RE: RE: ODP: itd https://en.wikipedia.org/wiki/List_of_email_subject_abbreviations#Abbreviations_in_other_languages a czasem nie. Dodatkowo czasami niektóre boty odpowiadające na emaile doklejają końcówki do tematu mejla i wtedy Outlook totalnie głupieje i nic nie jest w stanie powiązać w dyskusję.

Emaile działają jako tako głównie dlatego, że są dość prymitywne i nie ma wobec nich wysokich oczekiwań.

Marcin Marcin napisał(a):

Wierzycie w idee open source i to że nie należy brać pieniędzy za tworzony kod?
Przestałem wierzyć w idee open source gdy projekty open source były zamykane ze względu na łamanie ich licencji oraz jak twórcy nie byli wspierani przez społeczność za zarabiał ktoś inny

Z moich dyskusji z użytkownikiem @GutekSan dowiedziałem się (o ile dobrze zrozumiałem), że idealny komunizm to taki, w którym ludzie pomagają sobie bezinteresownie, tzn. ludzie cieszą się z samego pomagania innym ludziom, nawet jeśli ci inni ludzie nie odwzajemniają pomocy. Przy takim rozumieniu komunizmu, programiści zarzucający projekt, bo ktoś tam się nie odwzajemnił, nie są idealnymi komunistami :)

Wracając na ziemię. Sama chęć pomagania innym nie wystarczy na dłuższą metę, bo autorzy się znużą rozwojem oprogramowania. Każde nietrywialne oprogramowanie wiąże się z:

• różnej maści krytyką, czasem konstruktywną, a czasem nie
• ludźmi, którzy trują tyłki programistom i marnują ich czas
• rozbieżnymi opiniami co do kierunku rozwoju oprogramowania, a to oznacza, że część użytkowników przegrywa z innymi i to może wywołać trochę toksycznych zachowań
• dramatami, jeśli ktoś komuś prześledzi twittera czy facebooka i znajdzie "faszyzm" albo coś tego typu
• brakiem czasu (np. bo autorowi urodziło się dziecko)
• znudzeniem (najciekawsze rzeczy zostały zaimplementowane i zostało naprawianie błędów i dorabianie obsługi N+1 kombinacji ficzerów)
• innymi ciekawszymi projektami
• itp itd

Ludzie rozwijają otwartoźródłowe oprogramowanie bo np:

• korporacje im za to płacą - np. Java, Linux, itp itd
  • ktoś może się dziwić jak np. Oracle zarabia na otwartoźródłowym OpenJDK. Tymczasem na forum wielu ludzi pisało o tym, że nie chce używać OpenJDK tylko OracleJDK, nawet nie podając konkretnego powodu. Być może Oracle zarabia na takich co chcą tylko płatne wersje oprogramowania, bez względu na rozsądek.
• społeczność albo dowolne insytucje im płacą
  • przy dostatecznie dobrze dofinansowanym projekcie ludzie mogą pracować nad nim na cały etat, a wtedy przestaje mieć znaczenie charakter projektu - skoro można w otwartoźródłowym projekcie zarobić na życie to sytuacja jest analogiczna do projektu z zamkniętym źródłem
• bo jest coś otwartoźródłowego i wymaga tylko małej poprawki, żeby komuś przypasowało - wtedy ten ktoś może wrzucić tę poprawkę do publiczne repo i wszyscy na tym zyskują
• ktoś lubi sobie pokodzić - na krótką metę to działa
• ktoś chce pokazać innym, że może coś zrobić lepiej - to też działa na krótką metę
• pracują na uczelni i używają danego oprogramowania w pracach naukowych
• itp itd

Dużo oprogramowania otwartoźródłowego umiera przez porzucenie. Głównie takiego pisane przez pojedynczych autorów. Gdy dane oprogramowanie jest tworzone przez jednego człowieka i tylko ten jeden człowiek jest w stanie efektywnie rozwijać to oprogramowanie, to wtedy jest duże ryzyko, że ten projekt może umrzeć. Wystarczy, że jednemu człowiekowi (autorowi) się odwidzi rozwój projektu, a jednocześnie dotychczasowym użytkownikom łatwiej będzie przenieść się na jakąś alternatywę niż wskrzeszać stary projekt. Z drugiej strony, jeśli mamy np. darmowe zamkniętoźródłowe oprogramowanie tworzone przez jednego człowieka to też jest duże ryzyko, że w ciągu kilku lat zostanie porzucone.

W skrócie: tworzenie, rozwijanie, używanie, etc oprogramowania otwartoźródłowego może się opłacać, ale trzeba zejść na ziemię i zamiast wymyślać ideologie to trzeba zrobić rachunek opłacalności bez niepotrzebnego emocjonowania się.

Nad dużymi poważnymi systemami open source ludzie w większości nie pracują za darmo, bo fundują je firmy. Jedno z wytłumaczeń jest w takim starym artykule: https://www.joelonsoftware.com/2002/06/12/strategy-letter-v/ W skrócie: Smart companies try to commoditize their products’ complements.
Zatem np. firmy sprzętowe mogą dofinansowywać open source, bo jak ktoś mniej wyda na oprogramowanie, to mu więcej zostanie na sprzęt. W ostatnich latach doszły chmury i jest analogiczny efekt - nawet Microsoft pokochał open source, ale tylko tam, gdzie jest to dla nich wygodne.

Marcin Marcin napisał(a):

Zaczynając z IT trafiłem na konferencje związaną z Open Source (Open Source Day) i zastanawiało mnie jak to możliwe że wielkie firmy tworzą oprogramowanie, do które źródła udostępniają za darmo.

Bo nie tracą na tym. np. Facebook nic nie traci na tym, że robi Reacta, bo przecież zarabiają inaczej, nie sprzedają frameworków do JavaScriptu, tylko są reklamodawcą i ich siłą jest to, że docierają do miliardów ludzi, a nie na samym kodzie.

Architektura systemów open source jest znacznie inna niż tych tworzonych z jednym budynku lub przez jeden zespół developerów, tam zazwyczaj są testy, system jest podzielony i ma dokumentację

Tzn. gdzie są testy, system jest podzielony i ma dokumentację? Z moich obserwacji to projekty open source są lepiej otestowane, są lepiej podzielone. W prywatnych/firmowych projektach zwykle to podzielenie jest dość randomowe na zasadzie "ktoś kiedyś zrobił i musimy z tym żyć", w projektach open source niby też jest legacy, ale jednak podejmuje się próby ciągłego ulepszania rozwiązań nawet kosztem "breaking changes" w kolejnych wersjach frameworka. No i dokumentacja w projektach o.s. naprawdę jest na poziomie, a w projektach firmowych zwykle "istnieje", ale jest tak napisana, że do niczego się nie przydaje.

No ale twoje zdanie jest dwuznaczne, więc nie wiem, czy z tobą polemizuję, czy przyznaję ci rację.

Wierzycie w idee open source i to że nie należy brać pieniędzy za tworzony kod?

Należy brać pieniądze za coś. Jeśli ktoś jest w stanie zrobić model biznesowy wokół open source (choćby oparty o donejty), to spoko. Ale często się to kończy tym, że ludzie pracują na etat, a na projekty swoje nie mają już czasu. Albo muszą żebrać o te donejty, bo kończą im się pieniądze.

Czy open source to model wytwarzania oprogramowania w oparciu o komunizm?
W takim razie closed source wzoruje się na kapitalizmie?

Open source jest dobrowolny, tu nikt ci z kałachem nie przychodzi zmuszając do współpracy, także porównanie do komunizmu słabe, daję 2/10.

Jaki komunizm, przecież to wolny rynek - każdy może zacząć własny projekt open source i robić go tak, jak chce. To wolnorynkowe w założeniach. Komunistyczne to mogą być co najwyżej trolle SJW, które łażą po projektach OS i mówią, że słowo black to jest obraza i żeby zmienić na block, a master to kolonializm i żeby zmienić na main.

Stworzyłem kilka projektów open source od zera, które wypełniły pewną niszę i znalazły użytkowników oraz - co mnie najbardziej cieszy - kontrybutorów z różnych stron świata.

Udział w OS na prawdę dużo mnie nauczył (to w zasadzie jak rozwój produktu na wszystkich etapach, od zbierania wymagań, implementacji, testów, marketing i utrzymanie). Sama świadomość, że mój kod jest gdzieś na świecie sprawia, że jednak człowiek stara się bardziej ;) (aczkolwiek wiadomo, że jakikolwiek kod starszy niż tydzień wygląda już na wymagający refaktoryzacji i to odwieczna walka vs nowe ficzery i bug fixy). Tego poświęconego czasu (darmowego w ramach moich wolnych godzin) nie żałuję - i sam zacząłem mocno popierać ideę OS. Ale jednak już nie chciałem tworzyć kolejny pro bono projekt - lubię programować, lubię się dzielić ale lubię też robić wiele innych rzeczy i zwyczajnie brakowało mi doby. Na szczęście udało mi się to niedawno pogodzić i znalazłem nowa prace związana z projektem open source (więc moje 8-16 jest de facto projektem os) i dodatkowo dzięki poprzednim projektom znalazłem fundację gotowa zapłacić mi za wykonanie kolejnych projektów os w wolnym czasie.

Dlatego wracając do pytań z pierwszego postu - można udzielac się w os nie zarabiając (jak ja na pierwszych projektach), można robić to w ramach pracy ale te można znaleźć sponsorów.

Jak to się opłaca firmom ? Jest wiele form możliwych zarobków, po pierwsze to może być po prostu rozwój tooli, które i tka są potrzebne firmie (np nowy język jak golang). Otwarcie na świat sprawia, że inne firmy i indyeodualisci mogą rozwijać produkt za Ciebie - win win sytuacja. Podobnie w sprawach bezpieczeństwa - otwarty kod oczywiście umożliwia znalezienie luk ale też znacznie zwiększa prawdopodobieństwo, że ktoś te kuki odnajdzie i je Tobie zgłosi.

Co do kwestii testów i dokumentacji - do końca nie zrozumiałem tego co sugerujesz, ale projekty open source mają często znacznie lepsze pokrycie testami oraz super dokumentację - bez niej nie przekonasz potencjonalnych użytkowników czy kontrybutorów do Twojego projektu. To jest jedna z zalet OS, którą mocno cenię. Nie zliczę przypadków projektów firmowych bez żadnej dokumentacji i leżących testów "bo to tylko projekt wewnętrzny" czy "nie ma czasu pisać tego, trzeba pchać ficzery" gdzie w OS jest to sytuacja mniej spotykana.

Czy boję się, że mój kod ktoś "ukradnie"? Nie, z chęcią zobaczę jak ktoś go wykorzysta w swoim celu! Dlatego mam otwarta licencję. Pisząc swój kod pisałem go w konkretnym celu - i z umiejętnościami, które od tego czasu rozwinąłem. Posiłkowałem się też pisząc swój kod kodem innych (bardziej konkretne podejście do problemu czy ogólny design niż kopia 1:1) i otwartość kodu innych projektów mocno wzmacnia moja produktywnośc - nie muszę wymyślać koła na nowo.

Mnie zawsze zastanawiało jak to jest, że programiści chcą pisać kod za darmo i robią to po godzinach jednocześnie nie biorą za to pieniędzy mimo tak dużego niedoboru programistów. Mogliby w tym czasie pisać projekty za pieniądze to wolą za darmo pisać kod open source. Programiści to dziwne istoty. yyy chwila ja też jestem programistą

@Marcin Marcin:

jak za darmo? przecież to też ma wartość

Marcin Marcin napisał(a):

Wierzycie w idee open source i to że nie należy brać pieniędzy za tworzony kod?
Przestałem wierzyć w idee open source gdy projekty open source były zamykane ze względu na łamanie ich licencji oraz jak twórcy nie byli wspierani przez społeczność za zarabiał ktoś inny

Co rozumiesz przez "wierzenie w ideę open-source"? Co rozumiesz przez "wierzenie w to, że nie należy brać pieniędzy za tworzony kod"?

Freja Draco napisał(a):

W emailach to nie ma sieczki? Np: https://en.wikipedia.org/wiki/Email_storm - co jakiś czas mamy taką imprezę w firmie. Same emaile są wysoce nieefektywne (jeśli chodzi o ich format zapisu). Jak jest dyskusja na 30 odpowiedzi to wszystko jest za każdym razem cytowane w mejlu (aczkolwiek można to wyciąć). Tragicznie jest jak ktoś osadzi zrzuty ekranu - taki zrzut ekranu jest potem kopiowany w nieskończoność. Jak odpowiadać na mejla? Niektórzy odpowiadają u góry, inni w środku, a jeszcze inni mieszają swoje odpowiedzi z oryginalnym mejlem.

Standard odpisywania w mailach i na grupach dyskusyjnych został wypracowany jeszcze w latach 80-tych. W przechowywanych przez Google archiwach grup można zobaczyć, że już wtedy odpowiedź pisano pod mailem, albo pod tym fragmentem maila, do którego w danym punkcie się odnosimy. Podobnie jak tutaj na forum. I tak właśnie pisano przez jakieś 20 lat.

Kiedy pojawiły się pierwsze dzieci neostrady ludzie pouczali ich jeszcze "Odpowiadaj pod mailem!" i "Tnij cytaty". Później daliśmy sobie z tym spokój, stwierdzając, że dzikich nie da się niestety nauczyć jedzenia widelcem. Teraz pouczam już tylko, jeśli jakiś gieniuś domaga się, żeby mu pisać nad postem.

Z każdego systemu komunikacji można zrobić sieczkę, jeśli każdy będzie używać go w inny sposób.

Brak jest jednolitego języka. Daty, etykiety i inne rzeczy są w mejlach wpisywane w różnych językach, co jest łatwo spotkać w międzynarodowym korpo.

Możesz wyjaśnić?

Strefy czasowe? Domyślcie się co to znaczy, że dostaliście mejla o 05:32, mimo że koleś po drugiej stronie świata siedział po godzinach.

Możesz wyjaśnić?

(problemy z cytowaniem, formatowaniem, załącznikami, diffami itd).

Możesz wyjaśnić?

Rozpoznawanie ciągu mejli w dyskusji? Loteria. Czasem klient emaila ogarnie RE: RE: ODP: itd

No tu się zgodzę. Zwłaszcza klienty MS miały zwykle własne pomysły na wszystko. Niemniej ciągle jeszcze wygodniej jest mieć dyskusję z połamanym wątkowaniem, niż musieć:

• do osoby A - wysyłać e-maila,
• do osoby B - wysyłać iMaila,
• do osoby C - wysyłać messengera,
• do osoby D - wysyłać Telegram,
• do osoby E - wysyłać Zoom-maila.
  Itp.

Freja Draco napisał(a):

W emailach to nie ma sieczki? Np: https://en.wikipedia.org/wiki/Email_storm - co jakiś czas mamy taką imprezę w firmie. Same emaile są wysoce nieefektywne (jeśli chodzi o ich format zapisu). Jak jest dyskusja na 30 odpowiedzi to wszystko jest za każdym razem cytowane w mejlu (aczkolwiek można to wyciąć). Tragicznie jest jak ktoś osadzi zrzuty ekranu - taki zrzut ekranu jest potem kopiowany w nieskończoność. Jak odpowiadać na mejla? Niektórzy odpowiadają u góry, inni w środku, a jeszcze inni mieszają swoje odpowiedzi z oryginalnym mejlem.

Standard odpisywania w mailach i na grupach dyskusyjnych został wypracowany jeszcze w latach 80-tych. W przechowywanych przez Google archiwach grup można zobaczyć, że już wtedy odpowiedź pisano pod mailem, albo pod tym fragmentem maila, do którego w danym punkcie się odnosimy. Podobnie jak tutaj na forum. I tak właśnie pisano przez jakieś 20 lat.

Kiedy pojawiły się pierwsze dzieci neostrady ludzie pouczali ich jeszcze "Odpowiadaj pod mailem!" i "Tnij cytaty". Później daliśmy sobie z tym spokój, stwierdzając, że dzikich nie da się niestety nauczyć jedzenia widelcem. Teraz pouczam już tylko, jeśli jakiś gieniuś domaga się, żeby mu pisać nad postem.

Zarówno Gmail jak i Outlook domyślnie cytują starego mejla pod nowym mejlem, tzn. pole do odpowiadania jest nad starym mejlem, a nie pod.

Email jest prymitywnym protokołem i jedyne co specyfikuje to dozwolone formaty, a więc głównie plaintext lub html. Gdyby to przenieść do komunikatorów to też dawałyby możliwość wstawiania HTMLa i wtedy pewnie byłyby wojny o to, jakich znaczników używać, żeby style użytkownika zadziałały.

Z każdego systemu komunikacji można zrobić sieczkę, jeśli każdy będzie używać go w inny sposób.

Jak widać email nie jest odporny na prawa Murphy'ego i z niego też zrobiono sieczkę.

Brak jest jednolitego języka. Daty, etykiety i inne rzeczy są w mejlach wpisywane w różnych językach, co jest łatwo spotkać w międzynarodowym korpo.

Możesz wyjaśnić?

W sensie nie wiesz, że istnieje wiele języków? W zależności od ustawionego języka klient emaila stosuje różne etykiety i tłumaczy pola.

Przykład tutaj: https://stat.ethz.ch/pipermail/r-help/2010-March/230740.html Nie dość, że klient emaila zastosował odp zamiast re to jeszcze mamy po (chyba) czesku r-help-bounces at r-project.org napsal dne 05.03.2010 14:05:18: (uwaga - na końcu jest znacznik czasowy, o którym napiszę poniżej)

Strefy czasowe? Domyślcie się co to znaczy, że dostaliście mejla o 05:32, mimo że koleś po drugiej stronie świata siedział po godzinach.

Możesz wyjaśnić?

W emailach są znaczniki czasowe, wpisane w dowolnym formacie daty i bez jawnych stref czasowych. Mając zacytowane 15 mejli w dyskusji nie wiem w jakich strefach czasowych są wszystkie podane znaczniki czasowe.

(problemy z cytowaniem, formatowaniem, załącznikami, diffami itd).

Możesz wyjaśnić?

GitHub udostępnia taki bajer jak odpowiadanie w dyskusji o issue z poziomu emaila. Takie rzeczy pojawiają się jako kolejny wpis w dyskusji. Wyglądają jednak kiepsko i co najważniejsze, odbiegają mocno formatowaniem od reszty (przez co trzeba się przestawiać gdy się przelatuje szybko wzrokiem po dyskusji).

Formatowanie może się rozjechać i bez integracji z innymi systemami. W przypadku, gdy używamy postaci plaintext, a nie html, klient emaila może automatycznie łamać linie albo i nie. Oprogramowanie do wyświetlania emaili np. https://en.wikipedia.org/wiki/GNU_Mailman może łamać linie albo i nie, w sensie widziałem przypadki, gdzie mailman pokazywał niełamliwe linie na wiele ekranów wszerz (i to gdy emaile pokazywał w postaci plaintext). W takim przypadku trzeba przewijać ekran nie tylko góra-dół, ale też lewo-prawo.

Rozpoznawanie ciągu mejli w dyskusji? Loteria. Czasem klient emaila ogarnie RE: RE: ODP: itd

No tu się zgodzę. Zwłaszcza klienty MS miały zwykle własne pomysły na wszystko. Niemniej ciągle jeszcze wygodniej jest mieć dyskusję z połamanym wątkowaniem, niż musieć:

• do osoby A - wysyłać e-maila,
• do osoby B - wysyłać iMaila,
• do osoby C - wysyłać messengera,
• do osoby D - wysyłać Telegram,
• do osoby E - wysyłać Zoom-maila.
  Itp.

I wtedy kompensujemy braki protokołu (brak wbudowane wsparcia dla długich dyskusji w emailach, każdy klient robi po swojemu) za pomocą mechanizmu białkowego (tzn. ręcznie ogarniamy bajzel). Zgadza się to co napisałem wcześniej:

Emaile działają jako tako głównie dlatego, że są dość prymitywne i nie ma wobec nich wysokich oczekiwań.

Emaile (w obecnej postaci), a komunikatory to przepaść jeśli chodzi o złożoność problemu. Mimo, że emaile są konstrukcyjnie proste to i tak kompatybilność różnych klientów emaila i integracji zewnętrznych systemów z emailami pozostawia wiele do życzenia.

Teoretycznie standard do komunikatorów już jest https://en.wikipedia.org/wiki/XMPP (Jabber). Jakoś nie zawojował rynku. Skoro w przypadku prymitywnych emaili jest masa problemów z kompatybilnością na poziomie formatu wiadomości, to w przypadku Jabbera tych problemów jest pewnie rzędy wielkości więcej. O ile w przypadku emaili brak kompatybilności w interpretacji wiadomości poskutkuje tym, że mechanizm białkowy będzie musiał przeglądać rozjechany tekst, o tyle w przypadku braku kompatybilności w np. formatach audio/ wideo mechanizm białkowy nie zrobi nic, bo nie będzie w stanie ręcznie przetworzyć danych binarnych czy skomplikowanych XMLi (lub czegoś podobnego).

Ja nie wierzę, bo jak widzę często jak kod Open Source jest pisany to jest to po prostu żałosne... Ciężko ominąć jakość kodu kiedy ktoś dostaje za coś pieniądze, a kiedy robi to "pro bono".

@Wibowit:

Teoretycznie standard do komunikatorów już jest https://en.wikipedia.org/wiki/XMPP (Jabber). Jakoś nie zawojował rynku.

Z większych graczy na rynku używają go Zoom i WhatsUp.

Nie zwojował rynku, bo w modzie teraz jest tworzenie własnych potworków protokołowych, które są zamknięte - łatwiej zbijać hasj. Internet miał łączyć a nie dzielić.

Co ciekawe niektóre zamknięte protokoły wprowadzają rzeczy które są u podstaw XMPP od początku xD Tak przemyślane są te twory ludzi, którzy zamiast wykorzystać coś co istniało, woleli zrobić własnego potworka.

Skoro w przypadku prymitywnych emaili jest masa problemów z kompatybilnością na poziomie formatu wiadomości, to w przypadku Jabbera tych problemów jest pewnie rzędy wielkości więcej

Jeżeli źle zaimplementujesz to jak ma wyglądać sesjia Jingle przy negocjacji wysyłania/odbierania pliku, no to jasne że tak będzie. Tylko to jest wina kogoś kto źle to zaimplementował a nie protokołu. Gdyby tak nie było to np. sens istnienia takiego czegoś jak USB by nie miała miejsca - w końcu USB to taki uniwersalny interfejs.

Ja nie wierzę, bo jak widzę często jak kod Open Source jest pisany to jest to po prostu żałosne... Ciężko ominąć jakość kodu kiedy ktoś dostaje za coś pieniądze, a kiedy robi to "pro bono".

Polecam popatrzeć w kod który piszą firmy xD Tam często są niezłe cyrki.

@.andy

Nie zwojował rynku, bo w modzie teraz jest tworzenie własnych potworków protokołowych

Ciekawe stwierdzenie, aczkolwiek jestem w stanie zaryzykować i napisać że bo teraz w modzie jest tworzenie własnych, działających i atrakcyjnych produktów, a nie protokołów :D

.andy napisał(a):

Co ciekawe niektóre zamknięte protokoły wprowadzają rzeczy które są u podstaw XMPP od początku xD Tak przemyślane są te twory ludzi, którzy zamiast wykorzystać coś co istniało, woleli zrobić własnego potworka.

Może jest odwrotnie? Próby implementacji standardu kończyły się potwornymi problemami, a własnościowe rozszerzenie po prostu działało?

Skoro w przypadku prymitywnych emaili jest masa problemów z kompatybilnością na poziomie formatu wiadomości, to w przypadku Jabbera tych problemów jest pewnie rzędy wielkości więcej

Jeżeli źle zaimplementujesz to jak ma wyglądać sesjia Jingle przy negocjacji wysyłania/odbierania pliku, no to jasne że tak będzie. Tylko to jest wina kogoś kto źle to zaimplementował a nie protokołu.

Im więcej klientów tym więcej ryzyka, że będą błędne. Najgorzej jeśli te najpopularniejsze będą mieć błędy, z którymi inni klienci nie będą sobie radzić. W przypadku mejli podstawowy protokół jest bardzo prymitywny, problemy z formatowaniem wiadomości ogarnia mechanizm białkowy, a jeśli coś nie zadziała to szuka się jakiegoś kulawego obejścia zamiast np. tworzyć nowy protokół albo czekać na poprawną implementację. Dla przykładu, jeśli serwer nie przepuści załącznika to mogę go wrzucić na jakiegoś dropboxa czy fotkę.pl i wrzucić linka do mejla. To jest akceptowalne, bo wobec emaili wymagania są bardzo ograniczone. Najważniejsze jest to, że wiadomość ma dochodzić do adresata. Może dojść z pewnym opóźnieniem, może dojść bez załączników, może być źle sformatowana, ale jak dojdzie to już jest sukces i można powiedzieć, że emaile działają.

Gdyby tak nie było to np. sens istnienia takiego czegoś jak USB by nie miała miejsca - w końcu USB to taki uniwersalny interfejs.

USB to bardzo niskopoziomowy protokół. Bardziej niż nawet TCP/IP. Po USB chodzą protokoły wyższego rzędu, np. komunikacja CPU <-> myszka. Czy tutaj mamy złoty standard? Czy każdy producent myszek tak samo obsługuje zestaw przycisków i innych bajerów w myszce?

XMPP to protokół najwyższego rzędu. Nad nim nic nie ma. Nie dość, że sam XMPP ma być zaimplementowany dobrze to jeszcze wszystkie protokoły poniżej mają działać dobrze.

Jeśli mój komunikator ma problemy z działaniem to w jeden dzień mogę zainstalować i przetestować 15 innych komunikatorów i to nie ruszając się z miejsca. Jeśli mój komputer ma niedziałające USB to problem jest już dużo poważniejszy, bo nie mam 15 sensownych alternatyw pod ręką. Nawet gdybym miał 15 alternatyw pod ręką to jednak posiadanie dziesiątek różnych dongli, przejściówek, itp itd jest znacznie bardziej problematyczne niż posiadanie 15 komunikatorów. Podsumowując, zestawianie ze sobą XMPP i USB ma dość mało sensu.

W przypadku protokołów jak email czy USB niezawodność osiągamy w dużej mierze dzięki ich prostocie. Im prostszy problem, tym łatwiej go rozwiązać.

kevin_sam_w_domu napisał(a):

Ja nie wierzę, bo jak widzę często jak kod Open Source jest pisany to jest to po prostu żałosne... Ciężko ominąć jakość kodu kiedy ktoś dostaje za coś pieniądze, a kiedy robi to "pro bono".

Ciekawe, a jaki język/technologia?
Bo ja raczej więcej WTFów widywałem w zamkniętym kodzie firmowym niż otwartych publicznych bibliotekach. No chyba, że jako open source masz na myśli todo jakiegoś kandydata na juniora, to wówczas faktycznie możesz mieć rację.

WeiXiao napisał(a):

@.andy

Nie zwojował rynku, bo w modzie teraz jest tworzenie własnych potworków protokołowych

Ciekawe stwierdzenie, aczkolwiek jestem w stanie zaryzykować i napisać że bo teraz w modzie jest tworzenie własnych, działających i atrakcyjnych produktów, a nie protokołów :D

I to jest właśnie jednym fundamentalnych elementów omawianego problemu. To trochę tak, jakby każdy producent samochodów budował własne drogi, po których np. tylko mercedesy mogą jeździć.

Freja Draco napisał(a):

I to jest właśnie jednym fundamentalnych elementów omawianego problemu. To trochę tak, jakby każdy producent samochodów budował własne drogi, po których np. tylko mercedesy mogą jeździć.

Kiepski przykład, bo samochód może jeździć nawet i bez drogi. Wystarczy cokolwiek w czym się nie zakopie (np. chodnik ;) ). Z drugiej strony, większość samochodów kiepsko sobie radzi w terenie, tzn. bez drogi, a więc trzeba cokolwiek pod czym samochód się nie zakopie. Dość niewielkie wymagania.

Ciekawszym przykładem byłyby tory kolejowe. Tutaj zgodność podłoża z pojazdem jest znacznie bardziej wymagająca. Polecam sprawdzić jakie są różnice: https://pl.wikipedia.org/wiki/Rozstaw_szyn Przy przekraczaniu granicy trzeba czasem przeładować towar z jednych wagonów na inne, gdy rozstawy szyn są niekompatybilne.

@Wibowit:

Może jest odwrotnie? Próby implementacji standardu kończyły się potwornymi problemami, a własnościowe rozszerzenie po prostu działało?

Jakoś N komunikatorów działa, ma się dobrze. Można? Można. Po prostu wielkie firmy chcą się betonować, bo hajs - no i użytkownicy wpadają w koło. Nie przejdę gdzie indziej bo mam znajomych, gdzie mam konto? Tam gdzie mam znajomych.

Swego czasu był WP Spik, NK Komunikator, FB M (bazował na XMPP i można się było podłączyć dowolnym klientem XMPP). Niestety z czasem firmy się betonują, bo nikt nie chce się łączyć i oddawać wpływów z użytkowników.

Gdyby na podobnej zasadzie działała sieć telekomunikacyjna, to aby porozmawiać z drugą osobą musiałbyś mieć taki sam telefon i być w tej samej sieci. Absurdalne nie?

Im więcej klientów tym więcej ryzyka, że będą błędne.

Jak jakiś klient będzie błędny, to nikt go nie będzie używał - odejdzie. Nie widzę tutaj problemu. Jak ktoś źle napisze klienta pocztowego i ten nie będzie poprawnie obsługiwał POP3 i IMAP, to nikt z niego nie będzie korzystał.

W przypadku mejli podstawowy protokół jest bardzo prymitywny, problemy z formatowaniem wiadomości ogarnia mechanizm białkowy, a jeśli coś nie zadziała to szuka się jakiegoś kulawego obejścia zamiast np. tworzyć nowy protokół albo czekać na poprawną implementację. Dla przykładu, jeśli serwer nie przepuści załącznika to mogę go wrzucić na jakiegoś dropboxa czy fotkę.pl i wrzucić linka do mejla. To jest akceptowalne, bo wobec emaili wymagania są bardzo ograniczone. Najważniejsze jest to, że wiadomość ma dochodzić do adresata. Może dojść z pewnym opóźnieniem, może dojść bez załączników, może być źle sformatowana, ale jak dojdzie to już jest sukces i można powiedzieć, że emaile działają.

Używam Thunderbirda i wiesz co? On sobie autentycznie lepiej radzi z parsowaniem HTMLowych wiadomości w przeciwieństwie do takiego desktopowego Outlooka, który ma z tym do dzisiaj problemy. Tylko to wina protokołu czy MS? No oczywiście MS, bo w przeglądarce działa :D Ba działa nawet w ich kliencie z W10! :D (to taki kolejny przykład na to, że jednak rozwiązania zamknięte czasem mogą być strasznym badziewiem)

USB to bardzo niskopoziomowy protokół. Bardziej niż nawet TCP/IP. Po USB chodzą protokoły wyższego rzędu, np. komunikacja CPU <-> myszka. Czy tutaj mamy złoty standard? Czy każdy producent myszek tak samo obsługuje zestaw przycisków i innych bajerów w myszce?

Nie ma to znaczenia na jakim poziomie. Masz jeden standard i nie ważne czy podłączysz myszkę, klawiaturę, to bez problemu zadziała. O to właśnie chodzi. Jeden standard a ty budujesz na nim swój produkt.

XMPP to protokół najwyższego rzędu. Nad nim nic nie ma. Nie dość, że sam XMPP ma być zaimplementowany dobrze to jeszcze wszystkie protokoły poniżej mają działać dobrze.

Nie ma to znaczenia czy jest czy nie ma. Idąc tym tokiem rozumowania, to HTTP może nie zadziałać jak wszystko pod nim nie działa poprawnie. Co to ma do rzeczy? Jak ktoś sobie napisze swój g**no protokolik, to przecież będzie miał te same problemy.

Jeśli mój komunikator ma problemy z działaniem to w jeden dzień mogę zainstalować i przetestować 15 innych komunikatorów i to nie ruszając się z miejsca. Jeśli mój komputer ma niedziałające USB to problem jest już dużo poważniejszy, bo nie mam 15 sensownych alternatyw pod ręką. Nawet gdybym miał 15 alternatyw pod ręką to jednak posiadanie dziesiątek różnych dongli, przejściówek, itp itd jest znacznie bardziej problematyczne niż posiadanie 15 komunikatorów.

Zaczynasz już filozofować. USB było pokazaniem, że wspólny standard to jest właśnie to coś, bo inaczej do każdego urządzenia miałbyś inny port i protokół komunikacji.

Podsumowując, zestawianie ze sobą XMPP i USB ma dość mało sensu.

Nie rozumiesz kompletnie porównania, więc porównaj sobie HTTP do XMPP. Ta sama idea.

W przypadku protokołów jak email czy USB niezawodność osiągamy w dużej mierze dzięki ich prostocie. Im prostszy problem, tym łatwiej go rozwiązać.

Niezawodność zależy od jakości implementacji i samej architektury rozwiązania. XMPP jest ponad 20 lat na rynku i został sprawdzony w boju na tak wielu frontach, że jak ktoś próbuje wymyślić coś nowego to mnie za każdym razem bierze na śmiech.

@WeiXiao

Ciekawe stwierdzenie, aczkolwiek jestem w stanie zaryzykować i napisać że bo teraz w modzie jest tworzenie własnych, działających i atrakcyjnych produktów, a nie protokołów

A czy komuś ktoś broni zrobić swoje UI na XMPP? No nie. Właśnie po to on jest, abyś nie wymyślał na nowo (i pewnie w 99% błędnie i bez łatwego rozwoju) swojego g**no protokoliku.

XMPP działa, rozmawiam tekstowo, głosowo, wideo, w czatach grupowych i to z ludźmi z innych serwerów. Wystarczy chcieć a nie ciągle pierdzielić, że nie bo nie.

Niestety w modzie jest tworzenie własnych zamkniętych rozwiązań, aby potem ludzie nie mogli z niego uciec. Chodzi tylko i wyłącznie o kasę. Wiele tych rozwiązań albo pod spodem bazuje na XMPP (Zoom, WhatsUp i wiele wiele innych teraz i w przeszłości), albo tworzy swoje, które nie dorastają do pięt czemuś co powstaje od 20 lat, rozwija się (X to extensible czyli rozszerzalny) i ma poszczególne nowe klocki dodawane zgodnie z tym jak wszystko inne działa.

@Freja Draco

I to jest właśnie jednym fundamentalnych elementów omawianego problemu. To trochę tak, jakby każdy producent samochodów budował własne drogi, po których np. tylko mercedesy mogą jeździć.

Albo inny rozmiar baku tak aby pasował tylko do konkretnych (producenta) stacji :D Najlepsze jest jednak porównanie do telefonów komórkowych ;)

@Freja Draco niestety ale na tym forum nie ma co sobie strzępić języka na temat chociażby XMPP, bo tutaj każdy mądrzejszy ;) Standard który ma ponad 20 lat, mega dużo implementacji, sporo różnych zastosowań, bardzo dużo firm która tego używa i na tym zarabia, a tutaj ludzie będą twierdzić, że to g**no..., że się nie sprawdza i w ogóle...
Serio? Niestety ale niektórzy lubią wymyślać koło na nowo, bez względu na wszystko i sobie to na siłę argumentować bo tak.

No ale wracając do OS. Gdyby nie OS nie byłoby Linuksa, lub by był ale pewnie nie w takiej formie, świat by był zdominowany przez zamknięte oprogramowanie - nie byłoby otwartych bibliotek, kompilatorów.
Jest tutaj sporo staruszków i mogą pewnie fajnie opisać, jak kiedyś piraciło się kompilatory ;)

Gdyby nie Open Source, to świat by był o wiele gorszy niż teraz, choć znając życie prędzej czy później i tak by powstał jakiś ruch wolnego oprogramowania.

Dalej. Na OS można zarabiać. Pokazuje to m.in. Red Hat, SUSE, Google, Amazon czy inne firmy które wykorzystują rozwiązania w swoich produktach i jednocześnie mniej lub bardziej wspierają ich twórców, albo sami delegują pracowników aby rozwijali te produkty.

A czy komuś ktoś broni zrobić swoje UI na XMPP? No nie. Właśnie po to on jest, abyś nie wymyślał na nowo (i pewnie w 99% błędnie i bez łatwego rozwoju) swojego g**no protokoliku.

Piszesz jakby to tylko chodziło o UI, a skąd ta pewność że edge który ma np. Discord nad konkurencją nie wynika właśnie z tego, że zdecydowali się nie iść w XMPP?

Standard który ma ponad 20 lat, mega dużo implementacji, sporo różnych zastosowań, bardzo dużo firm która tego używa i na tym zarabia

Jak to jest że taki super rozszerzalny standard, a na rynku nigdy się nie wybił swoimi featuresami?

bo przed Discordem nie słyszałem o żadnym komunikatorze, który łączyłby dobry chat, dobry voice chat, file sharing oraz streaming video, a przecież technologia podobno już była gotowa, wystarczyło klocki poskładać, ale w rzeczywistości trzeba było czekać na Discorda do 2015.

Discord nie wygrał rynku tym że rozreklamowała go duża firma czy coś, a po prostu oferował o wiele więcej niż konkurencja pod względem featuresów i prostego UI.

Architekturę i bezpieczeństwo to można sobię sprawdzić / pogooglać i zależy od konkretnego projektu. Znajdziemy i takie i takie projekty i tu i tu, jeśli chodzi o moje osobiste spostrzeżenia to kupowaty kod to w 80% ten closed - ale moje spostrzeżenia (czy nawet suma spostrzezeń z tego forum) to zbyt mała próba żeby wyciągnać jakieś sensowne wnioski.

Co do wiary w idee - to zupełnie tego tak nie rozpatruję, ja to robię dla siebie i nie miałbym żadnego problemu z tym, żeby ktoś tam na tym zarabiał, nie interesuję mnie to. Ważne że mogę się czegoś za darmo nauczyć i jeszcze ktoś mi ten kod sprawdzi również za darmo - genialny deal.

Finansowanie, w moim przypadku wyglądało tak, że jest sobie klient-bank, który korzysta z rozwiązania open source, np LizardFS (rozproszony system plików w C / C++), nie może sobię pozwolić na sytuację w której coś się spierdzielilło i musi czekać aż ktoś mu tam łaskawie ticketa rozpatrzy na Githubie. Więc wykupuję taką usługę u ludzi zajmujących się tym projektem (commiterów), żeby w takich sytuacjach byli w gotowości. Swoją drogą fajny deal, bo $$ wpada za nic i dosłownie kilka razy w roku coś tam czasami trzeba zrobić, głównie są to problemy konfiguracyjne a nie stricte związane z kodem.

WeiXiao napisał(a):

Jak to jest że taki super rozszerzalny standard, a na rynku nigdy się nie wybił swoimi featuresami?

Istnieje mnóstwo przykładów wojen formatów, które wygrywał jeden z nich i nawet niekoniecznie najlepszy, tylko po prostu taki, który pozwalał komuś najwięcej zarobić.

bo przed Discordem nie słyszałem o żadnym komunikatorze, który łączyłby dobry chat, dobry voice chat, file sharing oraz streaming video, a przecież technologia podobno już była gotowa, wystarczyło klocki poskładać, ale w rzeczywistości trzeba było czekać na Discorda do 2015.

Tlen bazował na XMPP, co prawda poprzerabiał go po swojemu i zamknął, ale oferował połączenia głosowe już jakieś 18 lat temu.

@Freja Draco:

Tlen bazował na XMPP co prawda poprzerabiał go po swojemu i zamknął, ale oferował połączenia głosowe już jakieś 18 lat temu.

Ventrilo w 2002 też oferowało VoIP + prymitywny chat, ale w związku z tym moim pytaniem - gdzie ta cała rozszerzalność, gotowe klocki itp., dlaczego mimo takich ułatwień i tak XMPP przegrało z proprietary?

Nie chce mi się za bardzo debatować lub filozofować na ten temat. Napiszę tylko tyle, że w świecie javy lub pythona obecnie praktycznie nie istnieją żadne projekty, które by nie korzystały z open-source. Oczywiście są różne problemy i rozważania z tym związane, ale obecnie ciężko uruchomić jakikolwiek projekt w ogóle nie korzystając z open-sourca. Można wierzyć lub nie wierzyć w tę ideę, ale gdyby dziś zaorano cały open-source na świecie, to można byłoby też zaorać pewnie 90% (lub więcej) projektów komercyjnych i niekomercyjnych.

dla przypomnienia wrzucę

guru ołpen sors (uwaga: nieco obruszające)

:P