Használsz egy adott szolgáltatást, ha nincs rendes weboldaluk csak Facebook oldal?

Címkék

Igen
26% (98 szavazat)
Nem
66% (253 szavazat)
Egyéb (leírom).
9% (33 szavazat)
Összes szavazat: 384

Hozzászólások

Mivel nincs facebookom eleg nehez lenne....
--
:wq

Félreértelmezed a Facebookot. Igen, vannak olyan emberek, akik mások számára irreleváns tartalmakat posztolnak, de pl. nekem max. 1 vagy 2 ilyen ismerősöm van, az ő posztjaikat el is rejtettem, problem solved. A Facebookot én kapcsolattartásra használom, egyrészt a személyes ismerőseimmel, másrészt a FB-csoportokon keresztül a kollégáimmal, munkahelyemmel, konferenciaszervezőkkel stb.

Az, hogy vannak a FB-on cicás-kutyás-magamutogató bejegyzések, számomra teljesen irreleváns. Néha persze azért meg szoktam nézni, legalább látom, hogy mivel foglalkoznak azok az ismerőseim, akikkel évek óta nem beszéltem (pl. egyetemi csoporttársaim).

A FB az elmúlt néhány évtized legnagyszerűbb kreálmánya, sokkal nehezebb lenne nélküle az élet.

Nezd! Mindenkinek megvan a maga valosaga. En azt mondom, hogy akivel nem tudom tartani a kapcsolatot hetkoznapibb es szemelyesebb formaban, csak ilyen eletstatisztikazos alkalmazasokon keresztul, azzal nem erdemes.
Ebben a hetkoznapibb dologban benne van az is, akivel evente csak egyszer tudok leulni kavezni es/vagy sorozni es jol erzem magam kozben vele, mert tud eloszoban is kommunikalni nem csak kepekben es bevagott cikkekben, idezetekben. Szamomra a testbeszed is kommunikacio.

Az hogy a FB mekkora talalmany? Passz. Az ido majd eldonti. En jelenleg azt latom, hogy az en ismerettsegi koromben a ket veglet van jelen: van aki a WC kalandjait is azon kozvetiti lehetoleg elo stream-ben (WC papir szponzor reklamokkal), es van aki meg keruli. En azt mondom, hogy annak nelkulozhetetlen, aki mar ebben dokumentalja, eli az eletet egy ideje es a kozvetlen ismerosei is igy teszik. Szerintem a vilag kisebb resze van meg ebben a virtualis terben jelen. En semmi hatranyat nem erzem a hianyanak.

A FB az elmúlt néhány évtized legnagyszerűbb kreálmánya, sokkal nehezebb lenne nélküle az élet.

Igen, valoban. Osszehoz ket nagyon osi emberi vagyat: a magamutogatast es a kukkolast.

Egyebkent meg van egy csomo pszichologia trukk benne, hogy hogyan zabalja fel az emberek idejet es figyelmet, de ez mar csak hab a tortan.

Mit dolgozol, hogy ezt megteheted és hol élsz?

Nálunk a munkahelyi kommunikáció egy nagy része Facebook-on zajlik, és nagyon idegesítő, hogy van 1-2 ember, akiknek mindent külön meg kell írni e-mailben, vagy el kell mondani telefonon, mert nem hajlandóak a Facebook-ra regisztrálni.

Na meg a legtöbb ismerősöm nem tudja se az e-mailcímemet, se a telefonszámomat (én se az övékét), egyedül Facebookon tudjuk tartani a kapcsolatot.

Konferenciák? Kivétel nélkül szinte minden szakmai konferencia a Facebook-ot használja informálásra (változás a teremszámban stb.).

Na meg ott vannak az ilyen-olyan cégek, akiknek nincs külön weboldaluk, csak Facebook-oldaluk és a kapcsolatfelvétel is Facebookon keresztül történik.

Amúgy igen, a Facebook gyűjt adatokat, és mi van akkor? A Facebook programkódok sorozata, nem egy személy.

Kicsit szemelyes iranyba kezd elmenni a dolog.
En eddig olyan helyen dolgoztam csak, ahol ezeket a fontoskodo papirokat eleg komolyan vettek es ha barmi erzekeny belsos adatot kitettel egy ilyen helyre elozetes irasbeli engedely nelkul, akkor repultel azonnal es orulhettel, hogy csak kirugtak. A belsos es csak belsos ellenorzott kommunikacio a minimum es a maximum is.

Azt fejtsd ki kerlek, hogy egy belsos, tuzfalmogott levo, teljesen ellenorzott, logolt mail szerver miert esik nalad a FB kategoriaba?

Majd ha a hivatali közjegyző pecsétet nyom a viaszra az emailen, akkor lesz az hivatalos.

Btw. kétszer volt, hogy írtam a BKK-nak FB-n keresztül. Először kiváncsiságképp, hogy vajon hogy kezel egy láthatóan fiatalosabb lendületet megütő szervezet ma egy Facebookot (ez még a Vitézy korszakban volt, mikor az 1V még felújítás alatt volt), másodszor meg azért, mert láttam, hogy működik és kényelmesebb volt, mint az e-mail. Utóbbi már a Dabóczis korszakban volt. Konkrétan iktatószámmal ellátva jött a válasz.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Ha a munkahelyi komm. fészen megy, akkor a céges emailcímmel regisztrálok egy fiókot csak erre, és ezt csak a munkahelyi gépről használom. Egyúttal írásban jelzem a felettesem felé, hogy az így megosztott adatok biztonságáért nem tudok felelősséget vállalni, és ennek átvételéről kinyomtatott, lepecsételt, tanúzott papírt kérek.

Amúgy kiváncsi lennék a munkahelyedre, mert érdekelne hogy hol és hogyan használnak munkahelyi kommunikációra egy arra tökéletesen alkalmatlan eszközt. :)

Ha az email server belső üzemeltetésű (vagy komoly garanciákkal, szerződéssel, akármivel külsős) ami plain pop/imap protokollon keresztül nem érhető el, és a kollegák csak smtpauth-tal, SSL-en küldenek emailt, akkor nagyjából igen.
Persze itt is van 0day, balfasz kollega és korrupt kollega faktor is, de legalább nincs köztünk egy n+1. fél a maga ingyenes szolgáltatásával (ahol ugye te vagy az áru).

kicsit félreérthetően fogalmaztam meg a kérdést: te személy szerint a saját munkahelyeden generált email forgalomban szereplő adatokért vállalsz felelősséget? y/n

én biztos nemmel válaszolnék, tekintve hogy a send gomb megnyomása után "in god we trust" üzemmódba áll a folyamat, és hiába titkosítod agyon a cuccot, ha a túloldalon valaki kimásolja a csatolmányt egy pendrive-ra, amit utána elhagy a villamoson, és az ügyfél egyik konkurense találja meg, aki puszta jófejségből és egy több éves személyes barátságra hivatkozva juttatott vissza anélkül hogy beleolvasott volna (filmünk igaz történeten alapul)

egy normális RMS megoldás persze árnyalja a történetet, de tl;dr nem az smtpauth hiánya vagy az NSA kémlelő tekintete miatt aggódnék, ha 99%-ban úgyis PEBKAC a root cause

Azert eleg nagy kulonbseg van akozott, hogy valaki illegalis uton hozzajut adatokhoz, vagy a ceg dolgozoi egyszeruen a kezebe nyomjak. Lattam mar en is olyan ceget, ahol fontos szemelyes ill. bizalmas adatokat tartalmazo dokumnetumokat WhatsApp nevu baromsagon kuldtek korbe.

Szoval a felvetes igenis jogos, hogy ha arra kenyszeritenenek, hogy olyan csatornan tovabbitsak ceges informaciot, ami koztudottan az adattolvajoke, akkor ezt en is irasban kernem. Az eredeti felvetes nyilvan nem arra vonatkozott, hogy a tobbibol nem lehet adatot lopni vagy szivarogtatni.

Hat ez jo kerdes, hogy meddig terjed a felelosseged. Ha te korultekinto voltal es a megfelelo szemely(ek)nek kuldted, a ceg altal eloirt infrastrukturan es a ceg altal eloirt modon (pl. titkositassal, adaterzekenyseg megjelolessel, stb.), akkor elvileg a tovabbiakert mar nem vgay felelos.

Ja, így nézve persze hogy nem :)
De egy dolog a pebkac, és egy másik dolog egy adatvádelmi szempontból, khm... mérsékelten megbízható szolgáltatás használta által bevitt plusz kockázat.

Ha az általam email-ben küldött infó kikerül, akkor meg tudom nézni hogy milyen címre küldtem, meg tudom nézni hogy mit küldtem, a mailserver logjaiban is ott vannak a bejegyzések, szóval innen kezdve csak a pebkac és szándékos kijuttatás marad (mindkét részről).

Ha ugyanezt fb-on küldöm, akkor ott van köztünk egy tök bizonytalan csatorna, amire a másik fél simán belép 23 másik eszközről is (mert ugye a privát fiókja), amin ki tudja mikre kattintgat, milyen vírust és akármit szed össze, ki tudja ki fér még hozzá a fb account-jához rajta kívül, stb. És akkor arról még nem is beszéltünk, hogy ha üzenet helyett mondjuk a falamra írja ki a balf*sz, hogy "Pisti nagyon elkúrta a NagyÜgyfél érzékeny rendszerét, ha tudsz segíts már helyrekapálni ezt a f*st" (szintén igaz történet alapján)...

C++ programozo http://www.scylladb.com/

En nem lennek hajlando olyan helyen dolgozni ahol olyan munkara teljesen alkalmatlan platformon zajlik a kommunikacio mint a FB. Mi emailt hasznalunk es slack-et es tokeletesen megfelelnek a celnak.

Akivel olyan szemelytelen a kapcsolat, hogy csak facebookon tartanank azzal en nem is tartom.

En meg soha nem ereztem ugy, hogy barmilyen hatranyom szarmazna abbol, hogy nincs FBkom. Mindenhova el tudtam menni ahova akartam. Semmirol se maradtam le. Mindent meg tudok venni amit akarok (es van ra penzem :D).

En nem tartom jo otletnek, hogy barmilyen szemelyes jellegu adat rollam fentlegyen az interneten.
--
:wq

"En nem tartom jo otletnek, hogy barmilyen szemelyes jellegu adat rollam fentlegyen az interneten."

Ezzel érvelt nagymamám is :) Nem akar fent lenni az interneten, mert akkor mindenki fog róla tudni mindent. Mi köze a FB-nak a személyes jellegű adatokhoz? Semmiféle személyes jellegű adatot nem kell megadnod, csak ha úgy tartja kedved.

Ez nem teljesen igaz.
Van úgy, hogy pl. mobilszámot kötelezően bekér a regisztrációnál.
Vagy ha éppen pár troll úgy dönt, hogy ki akar cseszni veled, akkor jelentik néhányan a profild a fészbúk felé, hogy nem valódi nevet használsz, ilyenkor letiltják a profilod és csak akkor használhatod újra, ha tudod igazolni, hogy valóban az a neved, amivel regisztráltál náluk.

És mindez megtámogatva NAIH által, akik szerint teljesen normális dolog, ha a fész fotót kér a személyidről vagy az útleveledről.

A FB mint platform elsosorban a szemelyes adatok megosztasara van kitalalva. Ezert hivjak "social-media"-nak. Ha engem ezen emlitett szemelyes adatok megosztasa (vagy fogyasztasa) egyaltalan nem erdekel, vagy akar tartozkodni kivanok tolle akkor semmi ertelme FBra regisztralnom.

Ha csak kommunkikalni akarok (mielott felhoznad ezt) arra vannak *sokkal* jobb celeszkozok. Pl. Telegram. Akivel en beszelni kivanok mind elerheto Telegramon vagy eloben, tehat 0 motivaciom van arra, hogy barhova mashova regisztraljak.

Amit meg akarok osztani magamrol a vilaggal - mint peldaul szakmai tudas vagy hobbi projektek - azokra szinten vannak *sokkal* jobb celeszkozok, pl. github.

A fogyasztasi igenyeimet is boven kielegiti a tobbi elerheto platform ami sokkal kevesbe invaziv a maganeletre.
--
:wq

En nem erzem a kesztetest akkor sem, ha latom, hogy a lemmingek ugralnak be a tengerbe a szakadekrol, hogy bealljak a sorba, mert ugye mindenki ezt teszi, tehat ez a normalis.
Ez az en valasztasom.
Nagymamad meg eleg bolcs, ha az informacio biztonsagi reszt nezzuk es mondjuk az elsodleges es masodlagos profilozast.

A scylladb a cassandra (tovabbiakban C*) egy reimplementacioja C++ ban ennek minden elonyevel es hatranyaval egyutt.

Az inditek a scylladb szuletesere a C* borzalmas gepkihasznalasa (alacsony throughput) es magas kesleltetese (latency) a JVM korlatai miatt. A scylladb maximalisan kihasznlaja a vasat amit ala teszel, szepen skalazodik felfele az izommal, ugyanakkor megtartotta a remek viszintes skalazodasi kepessegeit is amiket a C* genekbol orokolt. Mivel az implementacio mindenre kiterjed: sajat memory allocator, CPU scheduler, IO scheduler, page-cache, TCP stack (opcionalis) a kesleltetest maximalisan kezben tudjuk tartani, igy le tud menni 1ms ala. Sajat mereseink szerint bizonyos korulmenyek kozott 3 scylla node kivalthat akar 100 C* node-ot, megtartva a kluszter SLA-jat.

Hatranyok: nyilvan rosszat nem fogok mondani egy termeken amin dolgozok, de mivel ez nem egy sales eloadas oszinte leszek:
1) Habar ugy reklamozzuk mint drop-in replacement azert meg nem 100% a feature parity, de ezen folyamatosan dolgozunk es az osszes fontos feature-t tamogatjuk. Azt mondanam a feature-parity 90+%.
2) Tovabba mivel mind a vasat, mind az operacios rendszert es konyvtarakat elegge a hataron jaratjuk neha csunyan be tud borulni az egesz. De ez is javuloban van, kuldtunk a patcheket a glibc-hez, a kernelhez es a gcc-hez, a helyzet folyamatosan javul.

A merleg pozitiv, a klienseink nagyon meg vannak elegedve. Ehhez hozzajarul, hogy nagyon jo a support, olyan emberek dolgoznak nallunk akiknek komoly multjuk van kernelfejlesztesben, virtualizacioban, stb, szoval mindent ki tudnak nyomozni es meg tudnak oldani. Nem kell az OS vendorhoz kuldjuk a klienst ha azt gyanitjuk, hogy a hiba a kernelben vagy valamelyik rendszer-konyvtarban van.

Akit erdekelnek tovabbi reszletek, itt egy kis olvasnivalo:
http://www.scylladb.com/2017/10/05/io-access-methods-scylla/
http://www.scylladb.com/2017/09/21/scylla-heat-weighted-load-balancing/
http://www.scylladb.com/2017/09/18/scylla-2-0-workload-conditioning/
http://www.scylladb.com/2017/07/06/scyllas-approach-improve-performance…
http://www.scylladb.com/2016/04/14/io-scheduler-1/
http://www.scylladb.com/2016/04/29/io-scheduler-2/
--
:wq

Amit én láttam belőle - 6-8 hónapja amikor utoljára próbáltam, hogy tudja a Cassandra 2.x feature set egy részét, a Cassandra 3.x feature set igen kevés részét, a Java kiterjesztések (UDF, Trigger, satöbbi) 0 százalékát; a sebessége általános terheléssel messze nem ad akkora előnyöket, mint a szintetikus benchmark esetén és bármikor megborul az egész teljesen véletlenszerű helyzetben, amiről nem is gondolná az ember, hogy problémát okoz.

Nekem olyan érzésem volt, mintha az ember Oracle DB helyett betenne egy PostgreSQL adatbázist: valóban gyorsabb, Oracle feature set egy részét tudja, nagy részét nem, és persze rettentő sok limitációja van. Amikor pedig megjön az összes hiányzó feature, akkor nem biztos, hogy jobb, stabilabb vagy tényleg gyorsabb lesz.

...ezen túl én nem mernék kitenni egy ScyllaDB-t olyan gépre, amelyiknek van internet kapcsolata, mert teljesen biztos vagyok benne, hogy a sebesség oltárán feláldozták a biztonságot, míg egy Cassandra cluster-t simán ki merek tenni publikus gépekre, úgy, hogy publikus portokon kommunikálnak.

Meglepett, hogy innen valaki probalta is a scylla-t. :)

> Cassandra 2.x feature set egy részét
Inkabb ugy mondanam nagy reszet. Tudtommal nagyon kicsi dolgok hianyoznak innen.

> Cassandra 3.x feature set igen keves részét
* Secondary index tamogatas nemreg lett elesitve.
* Materialized view jelenleg experimental statuszban van.
Ezekkel a feature-ekkel egyaltalan nem siettunk mivel C*-ban is annyira problemasak, hogy nemreg degradaltak (vagy csak akartak) experimental szintre.

> (UDF, Trigger, satöbbi) 0 százalékát;
Ez meg most is csak tervben van.

> a sebessége általános terheléssel messze nem ad akkora előnyöket, mint a szintetikus benchmark esetén
Nem minden workload eseten lesz akkora a sebessegelony mint ami a fooldalon fel van tuntetve. Nyilvan nem teszunk ki olyan benchmarkot az oldalra ami minket rosz szinben tuntetne fel de igyekszunk igazsagosan osszehasonlatani az adatbazisokat (pl a C* is beallitjuk, hogy gyors legyen amennyire lehet).

> és bármikor megborul az egész teljesen véletlenszerű helyzetben, amiről nem is gondolná az ember, hogy problémát okoz.
A stabilitassal valoban voltak gondok de ez rengeteget fejlodott az elmult felevben. Ezt emlitettem a hatranyok kozott is.

> Amikor pedig megjön az összes hiányzó feature, akkor nem biztos, hogy jobb, stabilabb vagy tényleg gyorsabb lesz.
Biztosnak valoban nem biztos de kemenyen dolgozunk rajta. :) Gyorsabbnak maris gyorsabb.

> ...ezen túl én nem mernék kitenni egy ScyllaDB-t olyan gépre, amelyiknek van internet kapcsolata, mert teljesen biztos vagyok benne, hogy a sebesség oltárán feláldozták a biztonságot, míg egy Cassandra cluster-t simán ki merek tenni publikus gépekre, úgy, hogy publikus portokon kommunikálnak.
Ezt nem ertem mire alapozod. Mondanal egy peldat amit szerinted felaldoztunk a sebesseg oltaran?

Meg egy elony amit elfelejtettem emliteni az a management overhead, vagyis a hianya. A scyllanal nincs 1000 tunable amihez fel kene berelni egy konzultans ceget, hogy beallitsa, hogy megfelelo legyen a sebessege.
Nyilvan akinek nem kell a sebesseg, csak a HA annak nemigen fontos ez meg a tobbi felsorolt elony. Hozzank olyan cegek jonnek akik a fejuk tejere allva se tudtak a C*-t ugy beallitani, hogy eleg gyors legyen nekik, es ezert az o sajat SLA-juket se tudtak teljesiteni. Nekik maris megfelelo valasztas vagyunk, es hajlandok lenyelni a hianyzo featuroket, vagy kivarni amig meglesznek.
--
:wq

"Inkabb ugy mondanam nagy reszet. Tudtommal nagyon kicsi dolgok hianyoznak innen."

UDF? Java trigger? Persze, kinek mi a kicsi, aki ezeket nem használja, annak nem is hiányzik. :)

"Nem minden workload eseten lesz akkora a sebessegelony mint ami a fooldalon fel van tuntetve. Nyilvan nem teszunk ki olyan benchmarkot az oldalra ami minket rosz szinben tuntetne fel de igyekszunk igazsagosan osszehasonlatani az adatbazisokat (pl a C* is beallitjuk, hogy gyors legyen amennyire lehet)."

Hát na, ettől szoktam agyfaszt kapni, amikor kinn van egy specializált workload, amivel tud százszoros teljesítményt rövid távon, mielőtt megborulna, aztán amikor heteket kellene futnia változatos workload esetén, akkor meg kapok egy degradált teljesítményt és ugyanúgy ott vagyok, hogy kell egy szakértő, aki elmagyarázza, hogy a termék alapvetően jó ("nézze csak, itt van a benchmark"), csak nem jól fogom.

"Biztosnak valoban nem biztos de kemenyen dolgozunk rajta. :) Gyorsabbnak maris gyorsabb."

Igen, amíg el nem ér a falig. A jellemző probléma az, hogy Cassandra esetén látok a futásban trendeket, hogy lassul-lassul, de dolgozik, ScyllaDB esetén pedig azt láttam, hogy megy-megy-megy-összeomlott és azért ez nem igazán üzemeltetés barát dolog. Értem én, hogy gyorsabb, de a gyorsaságnak ára van.

"Ezt nem ertem mire alapozod. Mondanal egy peldat amit szerinted felaldoztunk a sebesseg oltaran?"

A mindenféle vizsgálatot, ami Java esetén out-of-the-box benne van a JVM-ben, viszont natív C/C++ esetén nagyvonalúan el lehet hagyni, aztán pedig lehet csodálkozni, hogy rommá törik, amint elterjed.

A JVM azért eléggé gyors, megfelelően megírt Java kód eléggé gyorsan és hatékonyan tud futni a C/C++ kódhoz képest (adott esetben akár gyorsabban is), viszont amitől nem lehet a JVM esetén megszabadulni, az a folyamatos ellenőrzés és finomra hangolható policy, ami a homokozóban tartja a futtatott kódot és csak bizonyos helyekre engedi ki.

Általában addig gyorsabb jelentősen a C/C++ kód, amíg ezeket a folyamatos ellenőrzéseket elhanyagolják, hogy úgy se lesz belőle baj, minek nézzem meg minden egyes hívásnál, hogy tömbön belül vagyok-e még, hoppá, egy remote buffer overflow exploit, hogy került ez ide?!

> Hát na, ettől szoktam agyfaszt kapni, amikor kinn van egy specializált workload, amivel tud százszoros teljesítményt rövid távon, mielőtt megborulna, aztán amikor heteket kellene futnia változatos workload esetén, akkor meg kapok egy degradált teljesítményt és ugyanúgy ott vagyok, hogy kell egy szakértő, aki elmagyarázza, hogy a termék alapvetően jó ("nézze csak, itt van a benchmark"), csak nem jól fogom.

En nem azt mondtam, hogy csak egy specializalt workload eseten gyorsabb hanem, hogy a gyorsulas nem egyenlo merteku minden workload eseten. Altalanossagban veve minden workload eseten jelentosen gyorsabb a scylla, ha nem azt bug-nak vesszuk es kijavitjuk. En peldaul jelenleg is egy ilyen bug kijavitasan dolgozok.
Mi nem egy szep benchmarkkal adjuk el az adadbazisunkat, mindenki tud olyan benchmarkot kesziteni amiben az o sajat termeke jobb mint tetszoleges X masik termek. Az ilyen bullshitek kibuknak a PoC elso napjan. A klienseink mind egy szalig egy alapos PoC utan dontottek ugy, hogy valtanak, nem egy bullshit marketing-maszlag alapjan.

> Igen, amíg el nem ér a falig. A jellemző probléma az, hogy Cassandra esetén látok a futásban trendeket, hogy lassul-lassul, de dolgozik, ScyllaDB esetén pedig azt láttam, hogy megy-megy-megy-összeomlott és azért ez nem igazán üzemeltetés barát dolog. Értem én, hogy gyorsabb, de a gyorsaságnak ára van.

Ezek mind bugok amiknek nagyreszet kijavitottuk es a maradekon dolgozunk.

Hogy miert hangsulyozom annyira a bugokat? Mert a bugokokat ki lehet javitani es ki is javitjuk de ami architekturas limitacio azzal nincs mit kezdeni.


> A mindenféle vizsgálatot, ami Java esetén out-of-the-box benne van a JVM-ben, viszont natív C/C++ esetén nagyvonalúan el lehet hagyni, aztán pedig lehet csodálkozni, hogy rommá törik, amint elterjed.
>
> A JVM azért eléggé gyors, megfelelően megírt Java kód eléggé gyorsan és hatékonyan tud futni a C/C++ kódhoz képest (adott esetben akár gyorsabban is), viszont amitől nem lehet a JVM esetén megszabadulni, az a folyamatos ellenőrzés és finomra hangolható policy, ami a homokozóban > tartja a futtatott kódot és csak bizonyos helyekre engedi ki.
>
> Általában addig gyorsabb jelentősen a C/C++ kód, amíg ezeket a folyamatos ellenőrzéseket elhanyagolják, hogy úgy se lesz belőle baj, minek nézzem meg minden egyes hívásnál, hogy tömbön belül vagyok-e még, hoppá, egy remote buffer overflow exploit, hogy került ez ide?!

Hat eppen ez az, hogy a JVM es a Java sulyosan korlatolt a sebesseg teren. Ha nem igy lenne akkor a scyllanak nem lenne letjogosultsaga, mert mar valaki reg optimalizalta volna a C* kodbazist. Ellenben azt latjuk, hogy komoly igeny van a piacon egy gyorsabb C*-ra.
A scylladb (a ceg, akkor meg cloudius-systems) is ugy kezdte anno, hogy a C*-ot (es ugy altalaban a JVM-et) probaltak gyorsabba tenni de nem sikerult akkora gyorsulast alerni ami piackepes lett volna. A C*-nal a Java-ban valo optimalizalasal elertek a falig es nincs tovabb (sot, a C*-nal is kiserleteznek C++-ban irt storage-engine hasznalatara).
Es hidd el a teljesitmeny kulonbsegek *messze* tulmennek azon, hogy leellenorzom-e a tomb hatarait vagy nem, ez egy massziv lebutitasa a problemanak.

Igen lehet ugy is lehet programozni C++ ban ahogy te mondod. De a C++ rengeteget fejlodott a C++98 ota es mi mar a C++17-et hasznaljuk. A C++11 ota nagyon mas vilag a C++.
--
:wq

"Hat eppen ez az, hogy a JVM es a Java sulyosan korlatolt a sebesseg teren."

Hát ebben igen nagyot tévedsz... :)

"Ha nem igy lenne akkor a scyllanak nem lenne letjogosultsaga, mert mar valaki reg optimalizalta volna a C* kodbazist."

A Cassandra kódbázisban elég sok olyan rész van, hogy sun.misc.Unsafe metódust hív, ami pont azt csinálja, amit a pure C/C++ kód: kikapcsolja a homokozó védelmeit, mert
a, tudod, hogy nem okoz a biztonsági szint csökkenése problémát,
b, tudod, hogy problémát okoz, de nem érdekel.

A teljes kódbázist nyilván nem lehet Unsafe hívásokra alapozni, viszont nem is kell minden egyes sornál azzal törődni, hogy nyitsz-e kiskaput ezzel a külvilág számára vagy sem.

Alapvetően az Unsafe szintről indulsz C/C++ esetén, csak fel kell rá készülni, hogy ki fogják használni, ha eléri a kritikus tömeget a felhasználóbázis vagy van olyan értékes adat, aminek a megszerzése megéri a befektetést.

Ezen túl végtelen sok példa van arra, hogy mennyire közel vannak egymáshoz teljesítményben a Java és a C++ implementációk, lásd például a https://www.techempower.com/benchmarks/ méréseket.

"Es hidd el a teljesitmeny kulonbsegek *messze* tulmennek azon, hogy leellenorzom-e a tomb hatarait vagy nem, ez egy massziv lebutitasa a problemanak."

Nyilván nem csak tömb határértéket vizsgál a JVM, ez egy példa volt, ezen túl is van nagyon sok olyan vizsgálat, amit nehéz vagy egyenesen lehetetlen megkerülni, viszont hostile környezetben kénytelen vagy használni, különben azon veszed észre magad, hogy hónapok óta egy új feature se került bele a szoftverbe, csak támadási vektorokat szüntetsz meg és ezzel komplexitást viszel bele a rendszerbe, a komplexitással pedig újabb kockázatokat és teljesítményproblémákat.

Csodák nincsenek, ha elég mélyen ismered a JVM működését, akkor tudod, hogy a C/C++ kód nem azért _lehet_ gyorsabb, mert a JVM annyi felesleges dolgot csinál, hanem azért _lehet _gyorsabb, mert a saját döntésed, hogy mennyi kockázatot viszel a szoftverbe: ha ugyanannyit teszel azért, hogy a C/C++ kódból se lehessen egyszerűen kijönni, mint amit a JVM tesz, akkor sebességben is ugyanott leszel.

JVM esetén például teljes természetességgel meg lehet oldani - gyakorlatilag 0 hozzáadott kóddal - hogy egy tetszőleges UDF class ne tudjon hozzáférni olyan memóriaterülethez, amihez nem kellene vagy nem lenne szabad. C/C++ dinamikusan hozzáadott bináris esetén ehhez gyakorlatilag vért kell hugyozz hónapokon át, mire meg tudod oldani és akkor is lesznek olyan rések, amire esetleg nem gondoltál.

"Igen lehet ugy is lehet programozni C++ ban ahogy te mondod. De a C++ rengeteget fejlodott a C++98 ota es mi mar a C++17-et hasznaljuk. A C++11 ota nagyon mas vilag a C++."

Lehet, hogy meglepő dolgot mondok, de a Java is fejlődött... :D

Az ellenőrizgetésben még van is igazság, de szerintem nem az a kulcsmomentum. Manapság a legtöbb program memória sávszélesség korlátos. Egy adatbázis pláne az - tippem szerint.

Namost Java-ban ha objektumokban tárolod az adatot, akkor semmilyen ráhatásod nincs, hogy mi hova kerül fizikailag, plusz eleve van egy pár százalékos overheaded az objektumok keretei miatt (ha nem optimalizálsz direkt erre, akkor akár többszáz százalék veszteség is lehet), plusz nem tudod még az objektumon belüli dolgokat sem együtt tartani. Egy löketben cache-be kerülés helyett egy rakás memóriaművelettel (pointerek mentén ugrálva) kell végigolvasni ugyanazt az adatmennyiséget.

Ha ez nem elfogadható, akkor jön hogy tegyünk mindent tömbökbe, vagya akár ByteBuffer-ekbe. ByteBufferhez saját allokátort is írhatunk végülis, yeah! Működik, egész gyors is lesz, csak éppen absztrakció szintjén ott tartasz mintha assembly-ben akarnál adatszerkezeteket tervezni. Kicsit sajtreszelős. Ha csak pár egyszerű adatszerkezetet kell optimalizálni (pl tömböt), akkor tökéletes, a programod többi részén nyersz annyit (fejlesztési időben), amit itt vesztesz. De ha a teljes programod összes adatát ilyenekben kell tárolnod, akkor már nem akkora hawaii.

Arról nem is beszélve, hogy ha valamit csinálsz is az adatokkal (és ehhez nem írod át a programodat trükkök százaival C-szerűre), akkor minden műveletre ömleni fog a szemét a programból, aminek összeszedése elakadással jár. Egy kicsi heap-pel sem lehet a GC pause-t párszáz milliszek alá szorítani, pláne garantáltan. Tehát az időnkénti jitter a válaszidőben garantáltan ott lesz.

Felveszi a C++ vedo kesztyut

Eloszor is (habar ezzel magamat is labon lovom) a JVM is C++-ban van irva es pont azert szortak ki a bongeszokbol mert tarva nyitott sebezhetosegek tatongtak rajta. Ennyit a JVM altal garantalt biztonsagrol.

Ironikus, hogy egy benchmarkkal akarsz meggyozni amikor megbeszeltuk, hogy barki tud szamara kedvezo szintetikus benchmarkot kesziteni. :D

Elorebocsatom, hogy nem vagyok Java es JVM szaki tehat fenntartom a tevedes jogat, tovabba az osszehasonlitast a scylla vs. C* kodbazisra kivanom leszukiteni. Vannak nagyon szar C++ kodbazisok amiket nem kivanok vedeni (volt egy parhoz szerencsem karrierem soran).

En a kovetkezokre gondoltam amikor at mondtam, hogy a JVM sulyosan korlatolt sebesseg teren:
* virtualis hivasok
* cache pollution
* GC
* inlining hianya
* altalanossagban veve a vashoz valo hozzaferes teljes hianya
* memoria es tomb ellenorzesek

Tehat sokkal tobbrol van itt szo mint arrol, hogy menyi kockazatot viszel be a rendszerbe. Egyszeruen a Java kod annyival a valos HW felett fut, hogy keptelenseg azt a foku optimalizalast elerni amit egy jol megirt C++ kod tud, *ugyanakkora* biztonsag mellet is akar!
Persze tudom, vannak nagyon fejlett JIT forditok amik devirtualizaljak a hivasokat, sot akar inline-oljak oket. Vannak nagyon gyors GC-k is, sot vert izzadva ki lehet kerulni a GC-t bizonyos helyzetekben (off-heap), de teljsen nem.
De mindent osszerakva a C++ meg mindig gyorsabb lesz ugyanakkora biztonsag mellet.
Espedig azert mert a C++-ban kozvetlen hozzaferesed van a vashoz. A kod nagy resze nallunk is magas absztrakcios szinten van megirva. De amikor kell akkor le tudunk menni alacsonyra es tudunk figyelni olyan reszletekre, hogy valami beferjen az L1 cacheline-ra es ne szoritson ki mast. Vagy hogy forro cache-el futtassunk bizonyos fuggvenyeket. Vagy agressziv inlining-al a fuggvenyhivasok nagyresze eltunik (forditaskor). A GC-pause-ok teljes mertekben el vannak kerulve (pedig mi is hasznalunk menedzselt memoriat).

Es erre adodik ra a shared-nothing design, ahol minden core-on egy dedikalt thread fut, a sajat kornyezeteben. A teljesen aszinkron kodbazis (direct IO, DMA-val), sajat coroutine implementacival => nem kell 10000 thread, mindegyik egy IO requesten blockolodva. A sajat CPU es IO scheduler ahol az alkalmazas intelligens donteseket tud hozni (pl. compaction, repair hatterben fut, a query-k nagyobb prioritast kapnak).

Lehet, hogy feluletes energiabefektetessel legalabb olyan gyors vagy gyorsabb kodot lehet irni Javaban mint C++ ban de ha nem sajnalod az idot es energiat, tovabba megvan a szakertelem akkor szerintem a C++ verhetetlen egyelore (ki tudja a JIT forditok fejlodese mit hoz, valamikor az ASM volt verhetetlen de ma mar az optimalizalo forditok jobbak).
Tovabba nem tagadom, hogy hibazni C++ tovabba is *sokkal* konnyebb mint Javaban. De odafigyelessel es a megfelelo eszkozok hasznalataval a kockazatokat minimalis szintre le lehet vinni.
--
:wq

"Persze tudom, vannak nagyon fejlett JIT forditok amik devirtualizaljak a hivasokat, sot akar inline-oljak oket."

Így van, pont azt csinálják meg a JVM-ek automatikusan az adott architektúrán a futás első pár másodpercében, amit kézzel végzel C/C++ esetén hónapokig. Lásd például az említett Assembly vs. C/C++ fordítók esete.

"De mindent osszerakva a C++ meg mindig gyorsabb lesz ugyanakkora biztonsag mellet."

Ez az, ami általában nem igaz... :)

"Espedig azert mert a C++-ban kozvetlen hozzaferesed van a vashoz. A kod nagy resze nallunk is magas absztrakcios szinten van megirva. De amikor kell akkor le tudunk menni alacsonyra es tudunk figyelni olyan reszletekre, hogy valami beferjen az L1 cacheline-ra es ne szoritson ki mast. Vagy hogy forro cache-el futtassunk bizonyos fuggvenyeket. Vagy agressziv inlining-al a fuggvenyhivasok nagyresze eltunik (forditaskor)."

...ugyanis ezeket a JVM elintézi.

"Vannak nagyon gyors GC-k is, sot vert izzadva ki lehet kerulni a GC-t bizonyos helyzetekben (off-heap), de teljsen nem."

Lehet low GC programot írni, ha nagyon muszáj, oda kell figyelni kicsit jobban. Pluszban a GC lényege az, hogy a takarítást későbbre tudod időzíteni, ezzel kiszolgálási időben időt nyersz. Ez szintetikus tesztekkel tökig terhelt gép esetén hátrány, mert felgyűlik a szemét, de valós workload esetén előny, mert akkor takarítasz, amikor már nagyon muszáj vagy akkor, amikor amúgy sincs más dolgod.

"Tovabba nem tagadom, hogy hibazni C++ tovabba is *sokkal* konnyebb mint Javaban. De odafigyelessel es a megfelelo eszkozok hasznalataval a kockazatokat minimalis szintre le lehet vinni."

Na, erre az odafigyelésre leszek kíváncsi, mert ezen az odafigyelésen szokott bukni a "lassú ez a Java projekt, megírom C++ nyelven és szárnyalni fog" projektek igen nagy többsége... egyszerűen azért, mert a "gyorsabb", "azonos feature set" és a "biztonságos" hármasból nagyjából kettőt tudsz választani...

Szerintem egy kicsit tul sokat gondolsz a JVM es a JIT-forditok kepessegirol.
Azt allitod, hogy a JVM minden trukkot masodpercek alatt elintez amit mi honapok alatt vert izzadva irunk meg, a GC okosan es villamgyorsan fut pont akkor amikor szukseg van ra, raadasul mindezt biztonsagosabban.
Ezzel szemben a valosag az, hogy a C* clustereket majd harmadaval tul kell meretezni, hogy valahogy megbirkozzon a rettenet hosszu GC szunetekkel es mindenki kicsi es olcso gepeken futtatja mert a nagy gepeket egyszeruen keptelen kihasznalni, mert csak 10-20% os loadon jaratja oket. Ha a JVM tenyleg olyan jo lenne ahogy mondod akkor ez nem igy lenne.
Habar ez mar inkabb hatakonysag kategoria es itt szerintem meg jobban szenved a Java. Egy olyan nyelv ahol meg az integer is objektum ha tombben akarod tarolni.

Lehet, hogy ehhez hozzajarulnak az architekturas kulonbsegek is de jelenleg az a helyzet, hogy C++-ban joval gyorsabb programot lehet irni mint barmilyen JVM-alapu nyelvben ha mindket neylvben minden trukkot bevetsz is.
--
:wq

"Szerintem egy kicsit tul sokat gondolsz a JVM es a JIT-forditok kepessegirol."

Mintha egy Assembly programozót hallanék, amikor a C++ fordító tudásáról lenne szó... :)

"Ezzel szemben a valosag az, hogy a C* clustereket majd harmadaval tul kell meretezni, hogy valahogy megbirkozzon a rettenet hosszu GC szunetekkel es mindenki kicsi es olcso gepeken futtatja mert a nagy gepeket egyszeruen keptelen kihasznalni, mert csak 10-20% os loadon jaratja oket."

Azt azért sejted, hogy ezek nem azért vannak, mert a Scylla inline beleteszi az L1 cache-be az optimalizált metódusokat... :)

Ezek azért vannak, mert lehet ugyan low GC programot fejleszteni, de a Java runtime tudhatna azért még GC takarékosabb lenni, illetve lehet ezen JVM paraméterekkel jelentősen javítani, csak nem feltétlen szoktak, mert kevés a hozzáértő, aki tudja, hogy mi történik, miért történik és hogy lehet rajta javítani. Ötletszerűen csavargatni JVM paramétereket pedig nem mindig célravezető.

Ezen túl vannak a Java nyelvre jellemző runtime idejű ellenőrzések, ami miatt _leginkább_ kialakul ez teljesítmény különbség.

Röviden (és nem kizárólagosan) ez azt jelenti, hogy Java esetén se fordítási időben, se futási időben nem tudod megtenni azt, hogy:

int[] x = new int[10];
float y = 0.0f;
x[15] = y;

Mert a környezet nem engedi, ez például le se fordul így ebben a formában, de ha le is fordul, akkor a tömb túlcímzésének a vizsgálatához nyilván kell néhány plusz CPU utasítás, hogy ezt ne tudd megcsinálni. Nem tudod megkerülni, nem tudod rábeszélni a fordítót és a futtatót, hogy te teljesen biztos vagy benne, hogy nem fogod túlcímezni. Ezen túl az a szép, hogy ha teljesen biztos a helyzet, hogy nem lehet a tömböt túlcímezni, akkor a fordító és a futtató és kihagyja ezeket az ellenőrzéseket.

C/C++ esetén pedig ez lefordul és a környezet vígan végrehajtja a programot:
int x[10];
float y = 0.0f;
x[15] = y;

Csak vagy `Segmentation fault` lesz belőle vagy pedig egy csinos támadási vektor, amely során mondjuk egy preparált blob-on keresztül futtatási jogot tudnak kapni a gépen a támadók...

"Egy olyan nyelv ahol meg az integer is objektum ha tombben akarod tarolni."

Azt ugye tudod, hogy ez kétszeresen is hülyeség? Egyrészt a tömbben tárolt int az bizony primitív int lesz, egy 1000 elemű int[] tömb mérete a memóriában 4016 bájt. Másrészt a tömbben tárolt Integer objektum a tömbben primitív int lesz és konvertálódik a használat során (Autoboxing), egy 1000 elemű Integer[] tömb mérete a memóriában meglepő módon 4016 bájt...

Ez az ahol nem ertunk egyet, es a vita itt porog hasztalanul egy ideje.

Szerinted a Java hatranya a tomb-hatarok ellenorzeseben es a GC-szunetben ki is merul, ezen tul a JVM teljesen kepes a mernokok es fordito altal optimalizalt C++ koddal egyenlo teljesitmenyt nyujtani.
Szerintem meg ez nem igy van, es messzemenoen tobb a kulonbseg. Szerintem meg a JVM altal optimalizalt Java kod meg nem tart ott ahol egy mernokok es fordito altal optimalizalt C++ kod.

Felhozhatnam megint a Java C* vs C++ Scylla peldat de itt szerintem az architekturalis kulonbsegek sokkal jobban dominalnak, semmint hogy a ket nyelvet erdemben ossze lehetne hasonlitani e ket projekt alapjan.
Azert kivancsi lennek, hogy mi lenne a helyzet, hogy ha a C*-ot is atirnak shard-per-core es teljesen aszinkron arhitekturara, sajat user-space schedulerekkel, stb. Az egy nagyon erdekes osszehasonlitas lenne.

Mivel ez a vita annyira nem fontos nekem, hogy irjak egy nem-trivialis (vagyis egy bullshit benchmarkon tullepo) projektet C++ ban es Javaban csak azert, hogy az igazamat bizonyitsam ezert en itt engedelmeddel leallok. Meg azert a Javahoz nem is ertek annyira jol. :)
Szoval megegyezhetunk, hogy nem ertunk egyet.

Szerk: oszinten orulok, hogy egy uriemberrel vitatkozhattam, ervek alapjan es nem sullyedt az egesz szemelyeskedes szintre.
--
:wq

"Szerinted a Java hatranya a tomb-hatarok ellenorzeseben es a GC-szunetben ki is merul, ezen tul a JVM teljesen kepes a mernokok es fordito altal optimalizalt C++ koddal egyenlo teljesitmenyt nyujtani."

Nem, nem csak a tömb határokról van szó, annál lényegesen több ellenőrzés van és az optimalizációkból is lényegesen több van. Érdemes OpenJDK forrást olvasni a témában, meglepően sok ilyen dolog van és sokat lehet tanulni is belőle, akár a C/C++, akár a Java részből.

Talán két éve mélyedtem el ebben, tényleg ezek adják a lassabb futás okát:
a, a runtime ellenőrzések, amely szinte lehetetlenné teszi, hogy véletlenül más memóriaterületre írj vagy olvass onnan;
b, a class és method szintű policy, amivel akár egy homokozón belüli homokozóban tudsz tartani egy hostile class-t;
c, a különféle GC algoritmusok és azok paraméterezése, amelyekkel különféle workload esetén különféle GC időket lehet mérni;

Minden más elhanyagolható ezekhez képest. A tömb túlcímzéssel azért szoktam példálózni, mert az a legegyszerűbben megérthető példa és általában erre se szoktak figyelni a fejlesztők... ha megnézel egy tetszőleges C/C++ programot, elvétve találsz benne tömb-túlcímzés ellenőrzést és natív kódban egy tömb írás egy memória írás helyett rögtön öt utasítássá válik... ennél egy fokkal veszélyesebb az, hogy sokszor típusellenőrzés sincs és sokszor a process-memória bármelyik részére írhat bárki.

Ezek a dolgok nem azért kerültek bele by-design a Java platformba, mert hátulgombolósok tervezték hátulgombolósoknak, hanem azért, mert az átlagnál jobb C/C++ fejlesztők is hajmeresztő hibákat ejtettek rendszeresen, amelyeket ezek a védelmi mechanizmusok teljes egészében ki tudnak védeni. Ennek nyilván ára van, de annak is, hogy kikerülöd ezeket, csak amíg a teljesítménycsökkenés egzaktul mérhető, addig a potenciálisan kihasználható hibák számára nincs egzakt mérés...

...az ügyfeled pedig nem biztos, hogy ennek ismeretében is ugyanúgy választana, hogy 3000 vagy 1000 dollárt költ havonta az adatbázis infrastruktúrára, amikor mondjuk egy 10 millió dolláros adathalmazon ül, mert kijöhet az ügyletből úgy, hogy megtakarított 5 év alatt 120 ezer dollárt és úgy is, hogy elbukott 10 millió dollárt, mert el tudták lopni az adatait.

Ezért például az UDF-et meg tudod majd oldani úgy, hogy nagyjából funkcionálisan azonosan működjön, mint Cassandra esetén, de ugyanazt a biztonsági szintet nem tudod elérni, amit Cassandra esetén a JVM ad. Ekkor a három lehetőségedből reálisan két lehetőséged lesz:
a, apró betűvel feltünteted, hogy az UDF egy komoly támadási vektor lehet;
b, körbetákolod mindenféle védelemmel, hogy ezen keresztül ne lehessen támadni a szoftvert;
c, beleteszed mindazt, amit a JVM-be tettek több száz emberév munkájával, de erre nem lesz egy individuális program esetén erőforrásod.

És ez általában igaz minden funkciójára a szoftvernek, szóval ezért szoktam erősen szkeptikus lenni menedzselt nyelveken írt szoftverek C/C++ re-implementációjában, mert vagy valami hiányozni fog a sebesség-feature-biztonság hármasból, vagy nem fog adni akkora előnyöket, ami először látszott, mert csodák nincsenek. De azért hajrá... :)

Nem ertem, hogy az UDF miert akkora biztonsagi kockazat? Ha egy tamado tudott kapcsolodni az adatbazishoz, es be is tudott jelentkezni (ez ugye kell ahhoz, hogy vegrehajtsa a fuggvenyt) akkor amugy is van hozzaferese az adatokhoz, nem? Ezt mondjuk a role-based auth arnyalja egy kicsit de nagyjabol igy van. Ez nem bongeszo ahol tetszoleges scriptek futnak az UDF altal nyujtott runtime-on.
Ez ugyanugy szukseges ahhoz, hogy kihasznalj egy esetleges buffer-overflow hibat a rendszerben. Ehhez ugyanis egy preparalt CQL lekerdezest kene kuldeni ami az ANTLR parsert tamadja (ezt meg csak nem is mi irjuk, hanem generalva van). Vagy az internode-rpc kommunikacioba kene beekelodni (ezeket is generalt serializerek dolgozzak fel). Mindket esetben a tamado mar tulajdonkeppen hozzafer az adatokhoz, szoval miert kene valami remote-code-execution-nel szivjon?
Egy adatbazis nem egy webserver amihez barmilyen kliens csatlakozhat es barmilyen kerest fell kell dolgoznia.

BTW a JVM csak akkor ad vedelmet az UDF-nek ha valami JVM-alapu nyelvrol van szo (nem tudom a C* mit hasznal). Ha pl, Lua UDF tamogatasd adsz a rendszeredhez akkor a JVM semmi vedelmet nem nyujt, nemde?
--
:wq

"Nem ertem, hogy az UDF miert akkora biztonsagi kockazat?"

Ez sok mindent megmagyaráz... :)

"Ez ugyanugy szukseges ahhoz, hogy kihasznalj egy esetleges buffer-overflow hibat a rendszerben."

Aha... külvilág felé nyitott portokkal azért nem lennék ebben annyira biztos... egy DoS támadás simán esélyes, ha `Segmentation fault` jön ki a másik végén, illetve kijöhet jogosultság nélküli adatszivárgás, ha szofisztikáltabb a támadás. Ugye van azért a csapatban valaki, aki ezeket a problémákat jobban átlátja?

"Egy adatbazis nem egy webserver amihez barmilyen kliens csatlakozhat es barmilyen kerest fell kell dolgoznia."

Aham... mit is írtam? Megvan: "ezen túl én nem mernék kitenni egy ScyllaDB-t olyan gépre, amelyiknek van internet kapcsolata". Ebben a meggyőződésemben azért most eléggé megerősítettél. :/

"BTW a JVM csak akkor ad vedelmet az UDF-nek ha valami JVM-alapu nyelvrol van szo (nem tudom a C* mit hasznal). Ha pl, Lua UDF tamogatasd adsz a rendszeredhez akkor a JVM semmi vedelmet nem nyujt, nemde?"

A Cassandra csak JVM alapú UDF-et használ, vagyis vagy Java vagy JSR-223 based egyéb JVM-en futó nyelv jöhet szóba.

A bongeszos Java-appletek remekul bemutattak a JVM biztonsagat, szoval en egy cseppet se bizok jobban semmilyen JVM alapu szoftverben min egy C++-ban irtban. Torheto mind az osszes. Legfeljebb nem ugyanolyan konnyen. Sot, a hardver is torheto... egyes esetekben kikapcsolt allapotban is. Ennek fenyeben viccesnek erzem ezt a "én nem mernék kitenni egy ScyllaDB-t olyan gépre, amelyiknek van internet kapcsolata" hozzaallast, plane, hogy az egeszet arra alapozod, hogy C++-ban van irva tehat torheto.

Szerintem a biztonsag nagyon fontos, es folyamatos odafigyelest igenyel, mind fejlesztoi, mind uzemeltotoi reszrol, legyen szo barmilyen nyelvrol, platformrol vagy technologiarol. Sohase lehet hatradolni.
A biztonsag nagyon nem a C/C++ == rosz, JVM == jo alapon mukodik, mit mondjak en nem biznam a szerveremet valakire aki ezen elvek menten szervezi a biztonsagot.
--
:wq

"A bongeszos Java-appletek remekul bemutattak a JVM biztonsagat, szoval en egy cseppet se bizok jobban semmilyen JVM alapu szoftverben min egy C++-ban irtban."

Nézd, böngésző esetén az Appleteket nem a Java kódbázison keresztül támadták, tehát nem a Java nyelven megírt Applet volt sebezhető, hanem a futtató környezet. Hasonlóan a sok Flash vagy Javascript sebezhetőséghez, amelyek alapja nagyon nagy százalékban nem a Flash vagy a Javascript homokozóban futó Flash vagy Javascript kódbázis hibája volt, hanem a futtató környezet hibája. Találd ki, milyen nyelven írták a futtató környezetet ezekhez a virtuális gépekhez... :)

"Sot, a hardver is torheto..."

Igen, mint például a Meltdown és Spectre... de relativizálásnak így nincs sok értelme. :)

"az egeszet arra alapozod, hogy C++-ban van irva tehat torheto"

Nem, én nem erre alapozom. Azt állítom, hogy a C/C++ kódbázis esetén nagyon sok ellenőrzést ki szoktak hagyni a fejlesztők és csak akkor teszik bele, ha ebből baj van vagy előre láthatólag baj lenne belőle. A széleskörűen használt több éves vagy évtizedes kódbázisok esetén a legtöbb szükséges ellenőrzést már beletették emberévek tucatjainak munkájával, mert baj volt belőle, de még mindig derülnek ki olyan dolgok, amire nem gondoltak és baj lett belőle.

Én mindössze azt állítom, hogy ha egy C/C++ kódot és egy Java vagy C# kódot egymás mellé teszel és a C/C++ kódban elvégzel annyi biztonsági ellenőrzést, mint amennyit a Java vagy C# kódban elvégeznek, akkor szignifikánsan nem lesz gyorsabb a C/C++. Akkor lesz szignifikánsan gyorsabb, ha ezeket elhagyod... vagy azért, mert tényleg _bizonyítod_ az algoritmussal, hogy nem lesz belőle baj vagy azért, mert _szerinted_ nem lesz belőle baj.

Ha viszont beleteszed ezeket az ellenőrzéseket akkor abból vagy a szükségesnél komplexebb kód lesz, ami exponenciálisan növeli a kód karbantartásának költségét vagy pedig a közvetlenül pénzt hozó kódbázis mellé fejlesztesz egy belső keretrendszert is, amelyik csak viszi a pénzt. Mindegyikre van bőven példa, ha körülnézel régebbi nyílt forrású szoftverek körül, szinte mindegyiknek van egy *-toolkit projektje, amelyik néha nagyobb és néha kuszább életet él, mint az a projekt, amelyiket elvileg kiszolgál, illetve kevés olyan van, amelyik nincs telenyomva #ifdef blokkokkal és egyéb pre-processing direktívákkal.

", hanem a futtató környezet."
Tehat a JVM-alapu UDF ugyanugy sebezheto, mint pl. a Lua, vagy JS, stb.

"Én mindössze azt állítom, hogy ha egy C/C++ kódot és egy Java vagy C# kódot egymás mellé teszel és a C/C++ kódban elvégzel annyi biztonsági ellenőrzést, mint amennyit a Java vagy C# kódban elvégeznek, akkor szignifikánsan nem lesz gyorsabb a C/C++."
Szerintem meg ez nem igaz, de fujhatja itt mindegyikunk az igazat reggeltol-estig, kene egy projekt ami ugyanugy implementalva van mindegyik nyelvben es azt osszehasonlitani, de ez ugye nem all rendelkezesre, tehat folosleges ezt folytatni.

"Ha viszont beleteszed ezeket az ellenőrzéseket akkor abból vagy a szükségesnél komplexebb kód lesz,"
Megsugom, hogy C++-ban az osszes linearis storage-el rendelkezo kontener alapbol rendelkezik hatar ellenorzesekkel, lasd pl std::vector::at, mondjuk van ellenorzes nelkuli verzio is, ha biztos vagy a dolgodban. A tobbi kontener pedig minden alkalommal vegez hatar ellenorzeseket. Nem kell semmit elkomplikalni. Memoriat se kell ma mar kezzel foglalni/felszabaditani. Nyers tombokkhoz se kell nyulni. Lehet de nem muszaj.

De ez is csak ilyen altalanositas, "szoktak", "szinte mindegyiknek", stb... Igy nem lehet vitazni mert soha nem lesz vege.

Altalanossagban vitazni a teljesitmenyrol meg ugyanazon nyelvben irt kodreszletek kozt *sincs* ertelme. Meg kell kell merni alaposan, csakis igy lehet megallapitani, hogy valami gyorsabb vagy nem. Szoval ennek a vitanak mar duplan nincs ertelme.
--
:wq

Én is Java fan vagyok, szeretem is, meg sokat foglalkozok is vele, hogy pontosan hogyan működik. De az eszköz ismerete együtt kell hogy járjon a korlátainak ismeretével is. Anélkül olyan, mintha csak a marketinganyagot adnád vissza.

Az való igaz, hogy átlagos throughput szempontjából sokszor ezek a tényezők - ellenőrzések - a legfontosabbak. És egyetértek, hogy az esetek 95%-ában jó trade-off a biztonság érdekében az a kis szorzó. És ne is beszéljünk arról, mennyivel egyszerűbb egy out of bound exception-t debuggolni annál, mint amikor "véletlenszerűen" felülíródnak változóid a program másik felében egy túlcímzés miatt...

Amit viszont nem látsz, vagy nem ismersz be az az, hogy a GC miatti kiszámíthatatlan válaszidő egy csomó projektben bizony probléma. És ezt JVM-en belül egyszerűen nem lehet megoldani. Kis heapre is 50 ms körül lehetsz (régen mértem elismerem), nagy heapre meg óriási laggok vannak. Nekem egyszer kellett ilyen programot írnom, és a vége az lett, hogy a protokoll bonyolult és hibaesélyes részét Java kezelte, az egyszerű de időzítéskritikus részét pedig C küön processzben. Mert másképp nem működött, viszont Java fan vagyok és nem akartam az előnyeit teljesen elveszíteni.

Egy másik programban a sokszor futó loop-on belül cache-elni kellett az objektumokat, így sikerült elérni, hogy egyáltalán ne keletkezzen szemét. De ez már olyan erőfeszítés, hogy akár eleve lehetett volna C stacken foglalt objektumokkal, nem lett volna bonyolultabb. Persze megintcsak a program többi részén lehetett nyerni a Java-val, összességében még pozitív volt a mérleg.

A másik pedig az objektumok memória layoutja, aminek a fontosságát lekicsínyled. Szerintem is denesb rosszul mondta, valóban az int tömb "tömör" ahogy mondod is. De ha mondjuk egy generikus fát szeretnél intekkel, vagy longokkal kulcsolni, ott bizony már külön objektumban tárolódnak a kulcsok. Tehát 4 vagy 8 bájt helyett 8(4)+16(12?)+4 bájton (64 vagy 32 bites JVM függő) ami ráadásul nem is egymás mellett van. Ez már nagyon nem mindegy. Persze írhatsz, vagy használhatsz tömbbel implementált fát, de akkor meg a collection FW előnyeit nem tudod kihasználni végül, mert az összes API-t is primitív típusokra át kell írnod. De ha valami bonyolultabb struktúrát kell tárolnod hatékonyan, akkor marad hogy "kézzel" számolgatsz indexeket a tömbödhöz. Ilyet is csináltam már, működik, de megintcsak sajtreszelős.

A cache használata meg nem vicc. Mivel a programok általában RAM sávszélesség korlátosak, a limitellenőrzés minimális overhead. A tömb limitje tipikusan cache-ben lesz, vagy akár regiszterben, ha a JVM oda tudja tenni. Az ellenőrzés olcsó lesz. De ha egy loop sokszor fut, akkor nagyon nem mindegy, hogy minden adata is cache-ben van-e, vagy minden iterációban ki-be kell rángatni. Ezért mondom, hogy téves azt gondolni, hogy az ellenőrizgetés a sok. Kiélezett helyzetekben sokkal inkább ez lesz a limit. És a JVM memóriaszervezésével könnyen az utóbbiba futhatunk ott, ami C-ben simán benntartható lenne. Ezen sokszoros sebességek múlhatnak. Nem triviális rájönni sem, hogy ez az ok, és szintetikus benchmarkok csak akkor hozzák ki, ha a C tábor tervezi őket :-). Az is igaz, hogy ez már komoly minőségi szint egy C projekt esetén is amikor ezzel számolni kezdenek, de ott legalább meg lehet tenni, JVM esetén meg minimális eszközünk van rá.

Az ideális talán az volna, ha a protokoll ellenőrzés és belső parancsokra fordítás Java volna, a motor meg C-ben lenne megírva. Aminek gyors válaszidő kell, előre compilált lekérdezésekkel fordulhatna a C backendhez, így kikerülné a Javaból adódó esetleges jittert, de mégis nehéz volna támadni.

"Én is Java fan vagyok, szeretem is, meg sokat foglalkozok is vele, hogy pontosan hogyan működik. De az eszköz ismerete együtt kell hogy járjon a korlátainak ismeretével is. Anélkül olyan, mintha csak a marketinganyagot adnád vissza."

Ismerem a korlátait, le is írtam, hogy mik a korlátai, éppen a következő üzenetben:
alán két éve mélyedtem el ebben, tényleg ezek adják a lassabb futás okát:
a, a runtime ellenőrzések, amely szinte lehetetlenné teszi, hogy véletlenül más memóriaterületre írj vagy olvass onnan;
b, a class és method szintű policy, amivel akár egy homokozón belüli homokozóban tudsz tartani egy hostile class-t;
c, a különféle GC algoritmusok és azok paraméterezése, amelyekkel különféle workload esetén különféle GC időket lehet mérni;

Én nem akarok mindenre mindenáron Java-t használni és nem is használok mindenre mindenáron Java-t.

"Egy másik programban a sokszor futó loop-on belül cache-elni kellett az objektumokat, így sikerült elérni, hogy egyáltalán ne keletkezzen szemét. De ez már olyan erőfeszítés, hogy akár eleve lehetett volna C stacken foglalt objektumokkal, nem lett volna bonyolultabb. Persze megintcsak a program többi részén lehetett nyerni a Java-val, összességében még pozitív volt a mérleg."

Ebben az a furcsa, hogy a Java alapvetően a blokk szintjén élő változókat, objektumokat és mindenféle adatot szintén a stack-re tesz és a GC cikluson kívül dobja el, amint kilép az adott blokkból, ezért célszerű mindig az adott blokkban deklarálni, illetve elé tenni egy `final` módosítót, hogy csak a legvégső esetben módosítsd, mert akkor kikerül a heap-re... Ez alól az a kivétel, ha nem dönthető el egyértelműen az adott változó életciklusa, sok olyan helyzet van, amikor neked egyértelműnek _tűnik_, hogy az adott változót csak a blokkon belül használod, aztán kiderül, hogy tényleg nem, csak nem gondoltál rá, mert nem néztél még annyira a motorháztető alá.

"Persze írhatsz, vagy használhatsz tömbbel implementált fát, de akkor meg a collection FW előnyeit nem tudod kihasználni végül, mert az összes API-t is primitív típusokra át kell írnod. De ha valami bonyolultabb struktúrát kell tárolnod hatékonyan, akkor marad hogy "kézzel" számolgatsz indexeket a tömbödhöz. Ilyet is csináltam már, működik, de megintcsak sajtreszelős."

Általában pont annyira sajtreszelős, mint C/C++ nyelven leprogramozni ugyanezt, csak C/C++ esetén az ember hozzá van szokva a sajtreszelőhöz, Java esetén pedig fájdalmas dolog, mert az ember elszokott ettől. :)

"Az is igaz, hogy ez már komoly minőségi szint egy C projekt esetén is amikor ezzel számolni kezdenek, de ott legalább meg lehet tenni, JVM esetén meg minimális eszközünk van rá."

Nyilván. Csak valahogy sokan még valahol a Java 1.1 és 1.2 közötti JVM-re gondolnak, amikor a JVM működését próbálják magukban elrendezni, pedig nagyon sok emberév van abban, hogy ez sokkalta jobb legyen... és jobb is.

"Az ideális talán az volna, ha a protokoll ellenőrzés és belső parancsokra fordítás Java volna, a motor meg C-ben lenne megírva. Aminek gyors válaszidő kell, előre compilált lekérdezésekkel fordulhatna a C backendhez, így kikerülné a Javaból adódó esetleges jittert, de mégis nehéz volna támadni."

A C backend-et ugyanúgy tudod támadni, annyi a nehezítés, hogy át kell mennie a támadásnak a Java burkon...

Ez volt a marketing rész, többé kevésbe.
Arra lennék kíváncsi, hogy
1) kb mikor éritek el a 100%-os C* 2.x-et,
2) mi a roadmap a C* 3.x tudás elérésével kapcsolatban,
3) az Apache vagy a DataStax az igazodási irány (ez ugye a jövőben lesz releváns),
4) kap e valamilyen mgmt eszközkészletet az opensource változat,
5) magyar mikrovállalkozásnak érdemes e (financiálisan) az Enterprise változatban gondolkodnia?
thx

Elonyoket-hatranyokat kerdeztel ugyhogy azokat irtam. :)

1) Az UDF es LWT tudtommal idenre van beutemezve. Azt nem tudom megmondani, hogy az osszes apro kulonbseg es hiba mikor lesz kisimitva.
Amugy itt meg lehet tekinteni az osszes kapcsolodo issue-t: https://github.com/scylladb/scylla/labels/cassandra%202.2%20compatibili…
Ezek prioritizalasaban szerepet jatszik az is, hogy mire mekkora igeny van es nem csak a fizetos ugyfelek igenyeit vesszuk figyelembe.

2) A MV-n aktivan dolgozunk, mar elerheto experimental-modban. A 3.x file-formaton is elkezdunk dolgozni.
A lista itt: https://github.com/scylladb/scylla/labels/cassandra%203.x%20compatibili…
Az igeny-alapu prioritizalas itt is ervenyes.

3) Tudtommal az kompatibilitast az Apache Cassandrahoz, nem a DSE-hez merjuk.
Jovobeli tervekkel kapcsolatban nem tudok nyilatkozni, egy nyilvanos roadmap megtalalhato itt: http://www.scylladb.com/product/technology/scylla-roadmap/

4) A management eszkoz enterprise-only, lasd a roadmap-ot fentebb.

5) Ehhez en nem tudok hozzaszolni, mivel meg az arakat se tudom. :D

En mint egyszeru halando fejleszto csak olyan informaciokkal tudok szolgalni amik megtalalhatoak a nyilvanos weboldalon, illetve a nyilvanos github repokon.
Tehat tudok beszelni az arhitekturarol, a mukodesi elvekrol meg nyilvanos tervekrol, stb., de ha ennel tobb vagy konkretabb erdekel akkor egy ertekesitohoz (sales) kell tovabbitsalak.
--
:wq

#define munakhelyi kommunikáció. Nem Facebook, FB messenger*

Nálunk is van.. "Figyi már nézd meg ezt, nézd meg azt, menj ide, oda." ezzel mi a baj ? :)

Megkapja menet "közbe" a kollega és más fele fordul...

De félünk az FBtől! :) Használjunk inkább Vibert cégesre!!!! ....

ps: nyilván nem a "titkokat" posztojuk, hanem csak koordinálunk, arra pedig tökéletes az FB messenger.

az emberek nagy részét baromira nem érdekli a webes megjelenés mondjuk egy fodrász vagy étterem esetén, valaki meg amúgy is nyafogni fog. ha csak facebook van akkor ti, ha csinál egy egyszerű weboldalt akkor a javascript/reszponzív/buzzword fanok, ha telerakja javascript eyecandy-vel akkor meg én.

A facebooknak van rendes weboldala, vagy csak facebook oldal? :)

Jó, nem csak én tudok ilyen kérdést feltenni. :)
Ha webáruház, ami csak fészen működik(van ilyen?), azt nem, mert nincs mivel.
Ha az ELMÜ-nek nem lenne más online megjelenése, csak a fb, áramot akkor is használnék.

Szerintem nem az. Elég sok olyan kis business van, amiknek már csak facebook oldala van. Amit lehet ugyan jól csinálni, de nem egyszerű. Pl rendszeresen sikerül valami faszom albumba kitenni az étlapot, amit aztán túrhatsz, hogy hol a francban van.

Meg egyébként is, attól, hogy el lehet menni egy boltba személyesen is, még nem biztos, hogy ezt meg akarod tenni. Kissé nagyobb (lehet) a gap az online/offline mint a facebook/weblap között.

Pedig őszintén szólva most már előbb nézem meg Google Maps helyinformációkban azt, hogy adott üzlet nyitva van-e, mit mondanak róla, hol van (értelemszerűen), minthogy megkeressem a weboldalát, vagy a FB oldalát.

Idővel egyre kevesebb szüksége lesz az egyébként offline szolgáltatásoknak (mint pl egy kávézó) jelen lenni a weben saját weboldallal, mert kézenfekvőbb helyeken várja az ember az infót.

Persze.
Szerintem ez tök valid, és százszor inkább egy rosszul karbantott facebook, mint egy rosszul karbantartott saját weboldal.

És egy csomó kisebb dolognak tök fölös is. Pl a csaj, aki a gyerek szobáját festette faceen van, tök jól meg lehet nézni, miket csinál, lehetett vele kommunikálni. Amikor mi csináltuk, akkor néhány hónapra előre tudott időpontot adni, kb fél éve jutott el odáig, hogy bocs, de most senkinek, mert 1+ évre tele vagyok. Biztos nagyon sír, hogy kimaradtak az üzletéből azok, akik szerint a facebookon csak komolytalan cuccok vannak.

Ezen a hídon akkor kellene átmennem, ha odaértem!
Szerencsére sokkal több híd van itt mint Königsbergben. :)
--
Tertilla; Tisztelem a botladozó embert és nem rokonszenvezem a tökéletessel! Hagyd már abba!; DropBox

Ez erősen relatív... van olyan étterem, ahol csak Facebook oldala van, viszont aktívak, minden lényeges információ ott van, ami egy étteremnek kell és szinte azonnal válaszolnak az üzenetekre is. És van olyan étterem, ahol csak saját weboldal van, de az annyira szar, hogy sírok, miközben használom...

A másik oldala az, hogy a Facebook egyszerűbben hozza az ügyfeleket, mint egy weboldal. Vagy például egy projektem, amihez van sok felület, mert kíváncsi voltam, hogy mi hozza a legtöbb ügyfelet:
- Facebook csoport, van 100 tag, ebből van 50 aktív, akik rendszeresen olvasnak és 15-20, akik akár napi szinten rendszeresen írnak is
- Facebook oldal, van 1000 követő, a többségük passzív, 15-20 olvas rendszeresen, írni szinte senki nem ír
- Twitter oldal, van 200 követő, a többségük passzív, 1-5 olvas rendszeresen, néha van egy-egy retweet
- Weboldal, napi 50 session, többségük passzív, írni havonta egy-egy user ír

Az étterem szolgáltatása tipikusan nem csomag/egyébküldés, hanem hogy IRL odamész enni.

Szerintem a kérdésfeltevő a shady, egy fb-oldal törlésével megszűnő (értsd: totálisan elérhetetlenné váló) entitásokra gondolt.
Te Franko vagy, nem a "Fasza GSM Cuccok Olcsón" rajongói fb oldal, aminél üzenetben lehet rendelni féláron iPhone X-et, és ha megszűnik, akkor csak a 1984axaxax@yahoo.com emailcím marad utánuk, meg egy komáromi eredetű postázás, ahova a szomszédból autóznak át feladni egy marék ólomsörétet utánvéttel/előreutalással.

Igen van ilyen étterem, és utálom is érte, mert:
- a heti menüt percekig tart megtalálni ha nem hétfőn nézed, mert eltűnik a többi üzenet között
- a facebook fél képernyőt letakaró, bezárhatatlan üzenettel próbál rávenni, hogy regisztráljak már

A vállalkozásoknak észre kéne venni, hogy nem mindenkinek van facebookja, vagy nem mindig van belépve.

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee." -- Ted Ts'o

Nézd, az a helyzet, hogy te ülsz fordítva ülsz a lovon... :)

Olyan dolog ez, hogy csináltam Google és Facebook belépést egy weboldalhoz, erre jött a pampogás, hogy milyen dolog ez már, hogy nincs egyszerű regisztráció. Na, csináltam regisztrációt, ezek után pontosan 0,05 százalék lépett be regisztrációval, a többi meg jött Google és Facebook integráción át. Anyagilag nem érte meg, hogy foglalkozzak azzal a 0,05 százalékkal, meg is szüntettem a lehetőséget. Aki meg továbbra is pampogott, hogy miért nincs, az vihette a pénzét máshova.

Ezek egyszerű üzleti döntések, nem kell _mindenáron_ kiszolgáljalak, csak mert különlegesnek érzed magad attól, hogy bizonyos dolgokat nem vagy bizonyos dolgokat használsz.

mondjuk a példádban azt meg tudod állapítani, mielőtt nekikezdenél, hogy ezer regisztrációra jut öt olyan aki pampog, érdemes-e vele foglalkozni.

abban ncc1701-gyel értek egyet, hogy a szolgáltatónak ki kell énekelni a pénzt az ügyféltől, ehhez viszont be kell áldoznia valamit. azt meg ő dönti el, hogy mennyit és milyen módon teszi. a mindenki kapja be, majd mi megmondjuk hogyan akarjátok engem emlékeztet egy korábbi bp linux vitára.

"I'd rather be hated for who I am, than loved for who I am not."

"mondjuk a példádban azt meg tudod állapítani, mielőtt nekikezdenél, hogy ezer regisztrációra jut öt olyan aki pampog, érdemes-e vele foglalkozni."

Nagyszerű, és mi van akkor, ha már rég megállapították, hogy minden egyes lepattanó 'ncc1701' felhasználóra jut 2000 másik, aki otthagyja a pénzét?

"abban ncc1701-gyel értek egyet, hogy a szolgáltatónak ki kell énekelni a pénzt az ügyféltől, ehhez viszont be kell áldoznia valamit."

Abból a hamis képből indulsz ki, hogy a szolgáltatónak ki kell énekelni a pénzt, ha három hónappal korábban kell asztalt foglalnod az étterembe, akkor mondjuk pont leszarják, hogy valaki kizárólag faxon vagy távirattal szeretne asztalt foglalni, ha állandóan csörög a telefon.

Az üzlet kétoldalú dolog, nem biztos, hogy nekem megéri az, ha nálam akarod hagyni a pénzed. Nem kell mindenkit kiszolgálnom, elég azokat az ügyfeleket kiszolgálnom, amelyek a legtöbb pénzt hozzák a legkevesebb kiadással. Ha 'ncc1701' nem ilyen, akkor teljesen racionális üzleti döntés az, hogy keressen olyan szolgáltatót, aki elfogadja a különcségeit.

"Nagyszerű, és mi van akkor, ha már rég megállapították, hogy minden egyes lepattanó 'ncc1701' felhasználóra jut 2000 másik, aki otthagyja a pénzét?"
ezt nem fogom teljesen, de amit leveszek belőle, lehet rosszul, akkor ha tudják, hogy egy pampogóra van 2000 másik aki nem pampog és fizet, mint a katonatiszt, akkor szarok a pampogókra. ha egy fizetőre van 2000 pampogó, akkor meg kell valósítani. de azt írtam, ezt a fejlesztés előtt le lehet venni. és persze azt is lehet nem hozza be a hozzá fűzött reményeket.

"Abból a hamis képből indulsz ki, hogy a szolgáltatónak ki kell énekelni a pénzt"
hát a helyzet az, hogy a pénz az ügyfélnél van és neki, bizonyos keretek között, tökmindegy kinek a zsebébe teszi, csak az igényeit szolgálja ki. viszont neked, mint szolgáltató, érdeked, hogy ne máshogy vigye. biztos lehet finomítani amit írtam, de alapvetően így megy. persze ha a svájci nagynéni tolja a pénzt a cégbe, és neked csak arra kell, hogy legyen mibe tolnia, akkor értem, korrekt hozzáállás, kevesebb munkával kapod ugyanazt. dolgoztam már ilyen cégnél, ott is amúgy svájci a tulaj.

"ha három hónappal korábban k..."
általánosan mondta, én is, de biztos vannak konkrét példák, amikre nem (teljesen) igaz.

"Az üzlet kétoldalú dolog, nem biztos, hogy nekem megéri az, ha nálam akarod hagyni a pénzed."
pont erről beszéltem: "a szolgáltatónak ki kell énekelni a pénzt az ügyféltől, ehhez viszont be kell áldoznia valamit. azt meg ő dönti el, hogy mennyit és milyen módon teszi.". ennyi.

"I'd rather be hated for who I am, than loved for who I am not."

" viszont neked, mint szolgáltató, érdeked, hogy ne máshogy vigye."

Itt van a nagyfokú tévedés: egy szolgáltatónak az az célja, hogy profitot termeljen. Ehhez meg az az érdeke, hogy egy vevőre kevesebbet kelljen külteni, mint amennyi pénzt hoz.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

nem írom külön-külön. valahol nagyon félrement, én nem azt mondtam, hogy kerüljön többe, mint a bevétel. nem tönkremenni akarok, azért ennyire evidens dolgokat nem írnék le. de több ügyfél több bevételt és vele együtt több profitot hoz, nem? ha csökken a minőség a szolgáltatást igénybevevők mennyisége miatt, fejleszteni kell, hogy azonos, vagy akár jobb minőséget adjál és ezt remélhetőleg a korábbi profitodból meg tudod oldani. ha nem tudod vagy akarod megoldani, bármi ok folytán, persze ott van az ingyenes facebook (cégnek ingyenes amúgy?) meg freemail. ez számomra jelent valamit, ami nem feltétlen pozitív a cég felé. de ha más ezt szereti, hajrá.

a svájci jótevőről. ami cégről beszéltem, sikerült náluk csinálni egy olyat, hogy a marketinges kisebb árat talált ki egy akcióban, mint a beszerzési ár és azon imádkoztak, hogy minél kevesebbet adjanak el. hm. a marketinges maradt és a svájci nagybácsi küldött egy kis plusz pénzt, hogy ne legyen olyan csúnya a dolog.

ha már étterem. nálunk az céges étterem napi menüje fent van a facebook-on, alapból ott szoktam megnézni, pedig heti szinten kirakják hétfőn, vagy előző pénteken.

"I'd rather be hated for who I am, than loved for who I am not."

> több ügyfél több bevételt és vele együtt több profitot hoz, nem?

nem feltétlenül, változhat a költség
maradva az éttermes példánál, ha egy nap 10 embert tudsz kiszolgálni, de te 20-at akarsz, akkor nő a költség is: nagyobb terület, több szakács, több alapanyag, stb.

" de több ügyfél több bevételt és vele együtt több profitot hoz, nem?"

Nem. Több ügyféllel a költségek is nőnek, aztán egy méret után jön a felskálázás problémája. Kiváló plda az étterem. Nő mondjuk 10%-al a vendégeid száma, és máris lehet, hogy kell egy harmadik pincér meg még egy szakács.

Vagy mondjuk gyártasz szezonális terméket, vagy gyorsan kifutó terméket: egy széria pont sikeres lett belőle, keresik az emberek és hiány van belőle. Dönthetsz, hogy nyitsz még egy gyárat (sok pénz, lassú megtérülés), vagy inkább azt mondod, hogy ennyit tudsz kiszolgálni (és árat emelsz).

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

"ha tudják, hogy egy pampogóra van 2000 másik aki nem pampog és fizet, mint a katonatiszt, akkor szarok a pampogókra"

Így van. Pont ez van, amikor ugyanezek a pampogók cirkulálnak körbe-körbe a három mobilszolgáltató között és mindegyik úgy érzi, hogy a lehető legjobban döntött, függetlenül attól, hogy az egyik például az A szolgáltatótól ment B szolgáltatóhoz, a másik meg a B szolgáltatótól az A szolgáltatóhoz ment.

"hát a helyzet az, hogy a pénz az ügyfélnél van és neki, bizonyos keretek között, tökmindegy kinek a zsebébe teszi, csak az igényeit szolgálja ki"

Értem, de ugyanez igaz a szolgáltatóra is: nála van a szolgáltatás és bizonyos keretek között tökmindegy, hogy kit szolgál ki. A kereteken túl viszont ugyanúgy megtagadhatja az ügyféltől a szolgáltatást, ahogy az ügyfél se köteles igénybe venni azt. Kereslet-kínálat.

Innen indultunk: "Nálam van a pénz, ő akar szolgáltatni."

Pedig ez nem ilyen egyszerű:
1, ha sokkal több az ügyfél, mint amennyit tudnék szolgáltatni, akkor tetszőleges módszerekkel megválogathatom az ügyfeleket.
2, ha kevesebb az ügyfél, mint amennyit tudnék szolgáltatni, akkor nem válogatok, hanem nyalom az ügyfelek seggét.

"viszont neked, mint szolgáltató, érdeked, hogy ne máshogy vigye."

Nem, ez hibás gondolkodás. Nekem, mint szolgáltatónak az az érdekem, hogy a lehető legnagyobb legyen a nyereségem. Ezt viszont a legjobb úgy elérnem, hogy nem szolgálok ki mindenkit, elég azokat az ügyfeleket kiszolgálnom, amelyek a legtöbb pénzt hozzák a legkevesebb kiadással. Ha keveset keresek egy ügyfélen vagy akár veszteségem van, akkor inkább máshol vegyen igénybe szolgáltatást, mást fárasszon az igényeivel és a különcségével.

> persze ha a svájci nagynéni tolja a pénzt a cégbe, és neked csak arra kell, hogy legyen mibe tolnia

hát vagy ha így sem lehet asztalfoglalás nélkül bemenni az éttermedbe úgy ki van tömve a pipeline, akkor mégtöbb embert odavonzani X > 0 pénzért elég kontraproduktív lenne

Persze. Például az autószerelőmnek sincs, mégis viszem hozzá a kocsit. De a kőművesnek sincs, mégis vakoltatok vele. Még vannak akiket meg lehet találni ismerősökön keresztül.

Hát most meglepődtem. Eszembe nem jutott a tárhelyszolgáltatómat facebook-on keresni, meglepett, hogy ennyien nézik meg, vagy nem jól értem? Megnézitek külön, hogy van-e facebook oldala, ha mondjuk szóban ajánlotta valaki, hogy próbáld ezt a CRM-et ki?

Szerk.: sikerült félreolvasnom, tárgytalan.

Attól függ, mennyire kell az adott szolgáltatás. Nekem a fészbúkos tartalom egyfajta hozzáférést nehezítő fal mögött van. A fene sem megy a hosszabb útvonalon, ha nem muszáj. A fészre havi egy-kétszer jó ha felnézek, mindig nyugtázom, hogy nincs itt semmi látnivaló, és kész.
Olyan tartalmat meg dafke sem nézek meg, amihez be is kell jelentkezni. Majd én eldöntöm mikor akarom, hogy lopják az adataimat, ne kényszerítsen senki.

A kérdés másként: használsz egy szolgáltatást, ha még Facebook oldala sincs, csak egy idejétmúlt hagyományos weboldala?

Ha csak Facebook oldala van, akkor nem hasznalom sehogy, mert nem talalom meg.
Ha az idejetmult hagyomanyos weboldalan az informaciok meg mindig aktualisak akkor nincs vele problemam. (Foleg, hogy a modern weboldal mostanaban azt jelenti, hogy televan mindenfele JS-es elektromos csellentyucskevel ami megneheziti a hasznalatat. Szoval akar ez meg plusz is lehet.)

--
http://blog.htmm.hu/

Ez most milyen szolgáltatásra vonatkozik? :)

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

szolgáltatástól függ, ez így értelmezhetetlen. csak azért nem fogok egy céget kihagyni a lehetőségek közül, mert csak fb oldala van, ahogy csak azért nem fogok használni valamit, mert nincs fb oldala.

ugyanakkor tény, hogy például komolynak vehetőek lennének olyanok, akik holnapja olyasmi lenne, hogy fb.com/microsoft vagy fb.com/apple? (most tegyük félre azt, hogy valakinek a jelenlegi állapot szerint is komolytalanok :-)

"I'd rather be hated for who I am, than loved for who I am not."

+1

Étteremnél, kis szolgáltatónál jobb a FB oldal mint a rendes honlap, komolyabb cégnél, webshopnál értelemszerűen jobb a saját oldal.

Anti-FB oldtimereknek: a saját weboldalnak költsége is van, pláne, ha tisztességesen néz ki, pláne ha naprakész tartalom van rajta. Azt a költséget ki is kell termelni. Ha nem hoz annyival több ügyfelet, mint amennyibe belekerül, akkor ma már elég a FB. Annak a napra készen tartása töredék akkora költség.

--
Csaba

Igazából a FB a köcsög, hogy szopatja aki nem tag. Pedig egy étterem étlapját vagy hasonlót miért nem érhetnék el teljesértékűen anonim módon? Mert a FB köcsög, azért. Nem lenne kötelező fél képernyőt kitakaró "kérést" kitennie, hogy ne lássam a tartalamat bejelentkezés nélkül.

A szavazás jelenlegi állása szerint a szavazók 2/3-a nem használja azt a szolgáltatást, amelyhez az FB-n keresztül vezet az út. Magam is így vagyok vele. Ami csak így elérhető, az számomra nem létezik. Éttermet, szállást találok FB nélkül is. Nem sajnálom a dolgot, nem sírok miatta. Mit veszítek azzal, ha úgy tekintem, az a cég, szolgáltató nem létezik? Van helyette másik.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Az FB reklámozza magát, hogy regisztrálj. A fél képernyőt kitakaró kérésnél ott az opció, hogy most nem kívánsz regisztrálni, onnantól az oldal beállításának a kérdése, hogy a kirakott tartalomból mit látsz.

Olyat konkrétan bejelentkezve se látok, hogy egy adott étterem étlapja elérhető volna FB-n keresztül. Értsd: Nincs dedikált étlap opció. Ha az adott oldal karbantartója feltölti képként, bemutatkozó leírásként, bejegyzésként az más tészta, és kijelentkezve is látszik, ha úgy van beállítva. Forrás: Megnéztem párat.

Egyéb: facebook-on még nem volt dolgom olyan szolgáltatással, ami számomra releváns.

-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.
/usr/lib/libasound.so --gágágágá --lilaliba

[Egyéb: facebook-on még nem volt dolgom olyan szolgáltatással, ami számomra releváns.] detto.
Amúgy azt a mentalitást látva ami sok szakmabeliről lerí azt vizionálom, ha a facebook majd kijön egy webshop service-el, akkor a web jelentős része halálra lesz ítélve, és kénytelen leszek azt a szutyok faszbúkot használni... brrrr kiráz a hideg.

csak megjegyeztem, hogy ez meg nem az az allomas, amikor random boltnak facebookon van a webshopja.

De el fog az is jonni, egy percig se ketelkedtem...:-\

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

pfff, anti-facebook-osok gyulekezete...

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Eléggé cheap-kategória egy ilyen cég. Megspékelve valami free-email szolgáltatóval, mint "hivatalos" e-mailcím-kontakttal: nyami-nyami.

Egyéb, leírom:

1. vannak pl. olyan éttermek, kifőzdék amiknek nincs honlapja, de fb-on fent vannak, ott van a menü, az étlap, a telefonszám, stb.Az ilyesmi ellen nincs kifogásom, már ha regisztráció/belépés/stb. nélkül is elérhető az oldal. Ha nem, akkor hello.

2. fodrász Manci/hentes Sanyi, akiknek rendszeresen igénybe veszem a szolgáltatlását, de offline találtam meg. Eszembe se jutna online keresni, az ő online jelenléte nem érdekel.

3. alapvetően az online térben én nem érzem azt, hogy pénzt kellene költenem egy olyan cégnél ami csak fb-on érhető el, mert nem én vagyok a célcsoport. Ettől függetlenül ha máshol azt hallom, hogy egyébként ettől függetlenül jó a cég/hely/szolgáltatás, akkor nem zárkózom el.

Define service...

Ha a sarki reggelizősvállakozásnak ahol egyetlen alkalmazott van, nincs külön honlapja, hanem csak egy facebook oldalon találom meg, de ott up to date infok hozzáférhetőek regisztráció nélkül, akkor OK bár marha zavaró a face tolakodása a regisztáljálmár félképernyős "reklám".

Egy értelmiségitől aki akár egyemberes vállalkozást üzemeltet attól viszont elvárnám, hogy tartson fenn egy informatív honlapot. Ha nem teszi, akkor szerintem valami nem stimmel. (nem halad a korral - internet neki nem szempont, vagy túl bugyuta, hogy nincs honlapja csak facebook oldala, amin nem lehet tartalmat kulturáltan elhelyezni, akárki akármit is mond. Egyszerűen igénytelen.)

Kedvencem, hogy edesanyam felhaborodva felhiv, hogy egy hete nem valaszolok a fb uzenetere messengeren. pfff. Ha fontos, hivjon fel.

Nem tudok olyan szolgáltatást komolyan venni aminek csak facebook oldala van.
Ez kb olyan mint céges emailnek a "freemailt" használni.

Egyéb/leírom:

#define szolgáltatás..

Nálunk van itt Kecskeméten egy bográcsos emberke, aki szokott főzni 2-3 helyszínen. Majdnem minden nap máshol (2-3 fix pont van ahol főz), esetleg mást.
Ő neki FB oldala van és azon "kommunikál". Én erről tájékozódom és ez alapján döntöm el, hogy "megveszem/eszem-e" a szolgáltatásait vagy sem :)

Nem hinném hogy neki egy weblapot kellene fenntartania, ahogy sztem nem is tart fenn ilyet, főzzön jót, ez a lényeg számomra. És jót főz :)

Feltehető a kérdés, egy weblappal "több ügyfele" lenne ? Válasz.. NEM. Mivel ez a "szolgáltatás" kb. "szájról szájra terjedő" kategória, hallottad, igen, itt főz - nem most ott, nagyon finom stb. Erre az FB tökéletes számára, mert sokkal többet hoz mint egy weblap.

Ennyi.

vajon az elkepzelheto, hogy viber/telegram egyszer atvegye a facebook szerepet?

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Háát, egyrészt az ilyen jellegel érdekes dolgok egy részét a face is a messenger irányába tolja: chatbotok ugye. És bár elsőre ez "mekkorahülyeségmárt" triggerel az emberből, az van, hogy tulajdonképp egy webshopos checkout folyamatot ott se nagy ügy lemodellezni. Másrészt a telegram ezen túl a channelekkel vagy miknek hívják eléggé tolja a "follow me" szerű cuccot, ami kb a "belikeolom a facen, hogy lássam, ha van valami" (illteve részben a twitter) alternatívája, és úgy tudom, van, ahol eléggé megy. Sőt, emlékszem valami hadoválásra arról is, hogy pl fényképeket is berendez, meg ilyesmi. És ha belegondolok, egy csomóan leginkább a messengert és környékét használják, meg végigpörgetik a feedet fényképekért. Esetleg tényleg belikeolnak ezt azt following jelleggel.

Szóval semmi se lehetetlen, bár kétségtelen, hogy a mindenkinek van facebookja (kivéve persze azt a pár embert, aki ezt mindig el is mondja, lásd itt) reachabilityjével nehéz versenyezni.

Ezek a "közösségi" (inkább vegyél még több szart) dolgok nagyon nem hiányoznak nekem egy IM alkalmazásból, se az, hogy lájkolgathassak, se az, hogy ha megemlítem, hogy mosógép, már el akarjanak adni egyet nekem. Szóval ha valami kiváltaná az FB-t, akkor az ugyanolyan szar lenne a végén.

Nem tudom mi "kell" én arra reagáltam, hogy a telegram ugyan jelenleg valóban a messenger vetélytársa, nem a facebooké, de a face elég sok érdekes fejlesztése is a messenger platform irányába mutat, uh kérdéses, hogy a "A Messengerét, legfeljebb." megjegyzésből a legfejebb valóban annyira degradáló-e. Az, hogy nektek fixa ideátok mindenhol elmondani, hogy de fujjfacebook, az továbbra se tudom, hogy jön ide.

Legalább annyit össze lehet hozni, hogy van valami webes jelenlétük egy GitHub/GitLab Pages oldalon, aztán bedobni egy Cloudflare mögé. Azért az nem egy nagy kihívás.

Cloudflare? Az valami csillagszórós habcsók a sarki cukrászdában? A github az valami egzotikus állat? Ezeket a szavakat egy nem szakmabeli nem érti. Nem is ismeri. Szóval nem nagy kihívás, de kell hozzá egy szakmabeli. Ezzel szemben egy facebook pagehez pontosan nulla darab ilyen kell.

(Arról nem beszélve, hogy szerintem egy gitlab pagesen hostolt weboldal pont annyira jó, mint egy facebook page. Vagy még annyira se. )