Discussie over de toekomst van ZFSguru

donderdag 2 januari 2014 15:48

Acties:

0 Henk 'm!

Anoniem: 15758

Topicstarter

Even een afsplitsing van de lopende discussie in het ZFS topic over ZFSguru.

En dan ook gelijk de aftrap: leeg je hart over ZFSguru. Vertel alles wat je dwarszit, gooi het er maar uit.

Ik kan er namelijk wel wat mee, en misschien gebeuren er mooie dingen door. Als jullie mij kunnen overtuigen, kan ik Jason wel overtuigen.

De tot nu toe genoemde kritiekpunten op ZFSguru, zijn:

Punt 1: de voortgang van de Web-interface gaat te traag.
Punt 2: in beta8 zitten bugs zoals het niet kunnen toevoegen van slog.
Punt 3: de communicatie verloopt stroef en de website is verouderd.
Punt 4: de richting van ontwikkeling is onduidelijk, verkeerd of roept vragen op.
Punt 5: de ontwikkeling wordt gedomineerd door Jason en anderen hebben geen inbreng.
Punt 6: hulp wordt niet gewaardeerd.

Mijn voorlopige antwoord op deze punten:

Punt 1: de voortgang van de Web-interface gaat te traag

ZFSguru bestaat uit drie onderdelen:

Systeemarchitectuur
Services
Web-interface

Aan alle drie wordt (afwisselend) gewerkt. De web-interface is dus niet het enige onderdeel waar aan wordt ontwikkeld. Uiteraard wel een belangrijk onderdeel. Het klopt ook dat de interface nog niet af is; pas 0.2 zou de eerste stable release zijn. Maar in de tussentijd is er wel veel tussenwerk en andere verbeteringen toegevoegd, terwijl de featurelijst van 0.2 nog niet is behaald, namelijk Samba rewrite en Migration Manager. De eerstgenoemde komt in beta9, de migration manager is de laatste grote feature voordat 0.2 kan uitkomen. De features van 0.3 wordt ook al aan gewerkt en zijn al goed op weg met aardige voortgang. Daarna gaat het snel opwaard, elke major feature betekent een een jump van 0.3->0.4 bijvoorbeeld. Uiteindelijk belanden we bij 1.0 en dan kan een streep worden getrokken dat het project duidelijk een bepaalde mature status heeft bereikt. Tot die tijd, is het een project in wording.

Maar denk aan Firefox, Firebird, Phoenix destijds... dat was ook al bruikbaar voor de eerste 0.1 release en ik gebruikte dat destijds ook. Een project heeft tijd nodig om zijn ambities te kunnen vervullen. Wine is een uitstekend voorbeeld; pas na vele jaren een product wat goed bruikbaar is voor de eindgebruiker. Maar uiteindelijk wel een belangrijk en voor velen onmisbaar project. Het werk heeft zijn vruchten wel afgeworpen. Zo ook dient de basis voor de ambities voor ZFSguru gelegd te worden, en dat kan ten koste gaan van belangen op korte termijn. De lange termijn is waar de prioriteit ligt. Met tussenstops zodat het huidige ook goed bruikbaar blijft. Maar het einddoel is belangrijker dan het verbeteren van het huidige.

Conclusie: voortgang van ZFSguru fluctueert sterk. Nu er in 2013 veel aandacht is geweest voor services en systeemarchitectuur, zal er in 2014 weer meer focus liggen voor de web-interface.

Punt 2: in beta8 zitten bugs zoals het niet kunnen toevoegen van slog.

Mee eens. De meeste bugs in beta8 zijn klein en onschadelijk. Maar de sLOG-bug belemmert functionaliteit die in beta7 wel werkte, en dergelijke regressions horen niet. Niet in een stabiele release anyway. Maar het plan was om pas stable releases te doen vanaf 0.2 final. Dan was een 0.2.1 bugfix release mogelijk terwijl de 0.3-beta als experimental branch beschikbaar is. Nu zijn er een hoop dingen in ZFSguru gebeurd die niet in de originele 0.2 feature list zaten, waardoor het lang duurt voordat 0.2 wordt bereikt. Voor de gebruikers zeker niet optimaal, maar dat is een prijs van prioriteiten voor het behalen van het voorlopige tussendoel, 0.2 final. Nu met beta9 blijft er nog maar één feature over totdat er een 0.2 rc en final kan komen. Dan wordt het een stuk leuker en kan de ontwikkeling van de web-interface zeker sneller gaan. Maar bedenk ook: de snellere voortgang van de web-interface betekent dat wel echter dat systeemversies of nieuwe services minder prioriteit zullen krijgen. Kortom, er is onevenwichtig aandacht voor bepaalde elementen. Dat kan ook niet anders met twee mensen waarvan in elk geval ik zeker niet fulltime eraan werk.

Conclusie: de resources zijn beperkt. Dus we werken aan de grote dingen, zodat we ook zo snel mogelijk een stabiele basis voor de gebruikers hebben. Dat betekent wel dat gedurende die tijd ZFSguru nog geen stabiel product is. Maar dat is ook zo gecommuniceerd; pas vanaf 0.2 zou ZFSguru een stable release hebben.

Punt 3: de communicatie verloopt stroef en de website is verouderd.

Mee eens. Dit is wel een duidelijk punt van verbetering. Maar laten we een streep trekken met de nieuwe website. Dan wordt het ook leuker om de interactie met gebruikers aan te gaan. Nu is Jason veel tijd kwijt om de passwords te resetten van gebruikers. Ook het forum kent veel gebreken. Als dit soort issues zijn opgelost is het wellicht ook leuker om actiever te zijn. Zo merk ik ook dat ik liever op t.net reageer dan op het ZFSguru forum.

Conclusie: verbeteringen in de communicatie zijn zeer wenselijk en noodzakelijk om gebruikers een goed gevoel te geven over het project en zijn toekomst. Ook de nieuwe website die we in 2014 willen lanceren zal bijdragen aan betere communicatie, bijvoorbeeld door een beter forum en meer mogelijkheden.

Punt 4: de richting van ontwikkeling is onduidelijk, verkeerd of roept vragen op.

Misschien begrijpen jullie de richting nog niet goed, misschien denken jullie wel veel te beperkt, alles is mogelijk! Maar duidelijk mag zijn dat alle mooie plannen niet in een maandje te realiseren zijn.

Wat ik hiermee bedoel te zeggen is dat mensen ook de kans moeten krijgen om iets te ontwerpen waar zij zelf tevreden over zijn. Vaak lukt dat niet één twee drie. Zo heeft Gene Roddenberry - de geestelijk vader van Star Trek - vele flops op zijn naam staan en Star Trek was in het begin ook nog niet zo zeker van zijn toekomst. Maar achteraf is men alle flops vergeten en is Gene Roddenberry tot Star Trek zoals Steve Jobs tot Apple kan worden gerelateerd.

Zo geldt ook de toekomst van ZFSguru. Als het project erin slaagt zijn ambities in elk geval gedeeltelijk te verwezenlijken, dan zijn de huidige problemen niet zo belangrijk in verhouding tot het eindresultaat. Het alternatief is alle ambitie opgeven en een iets betere ZFSguru maken en dan na een jaar je motivatie verliezen en dan drijft ZFSguru over anderhalve jaar als een dode vis in de rivier. Dat is niet wat wij willen.

Conclusie: de ambities reiken ver om van ZFSguru een succesvol project te maken. Om al die ideeën te verwezenlijken is wel tijd nodig en dat gaat ten koste van belangen op korte termijn.

Punt 5: de ontwikkeling wordt gedomineerd door Jason en anderen hebben geen inbreng.

Nou ik heb zeker inbreng, maar het zijn geen 2e Kamerverkiezingen nee. Als ontwerper van een creatief werk moet je de vrijheid hebben om iets op jouw manier vorm te geven. Vaak kost het tijd om iets te krijgen zoals je bedoeld had, waar je zelf tevreden over bent. Als anderen gaan eisen dat het anders moet, is dat niet altijd leuk wanneer iemand nog helemaal niet klaar is met hoe het bedoeld was. Al die kritiek is wellicht meer van toepassing op het eindresultaat, dan aan een voorlopige versie die nu beschikbaar is.

Dat gezegd, is het ook zo dat er veel waardevolle feedback wordt gegeven waar wij wel wat mee kunnen. Goede positieve kritekpunten die mij danwel Jason van gedachte doen veranderen, zijn zeker welkom en zeer waardevol.

Conclusie: feedback over de richting van ontwikkeling is zeker welkom, maar de keuze blijft natuurlijk aan de ontwikkelaar.

Punt 6: hulp wordt niet gewaardeerd.

Dit is ook een punt wat regelmatig ter sprake komt, maar weinig concrete voorbeelden kent. Als je een mooie toevoeging kunt maken aan ZFSguru is die hulp zeker welkom. Maar wie gaat er uren vrije tijd spenderen aan ZFSguru? Wie van jullie is bereid dat te doen? Tot nu toe niemand.

Wel zijn er veel mensen die zouden willen helpen, maar dat niet kunnen omdat ze niet kunnen programmeren of omdat de documentatie ontbreekt om een effectieve bijdrage te kunnen doen. Beide zijn niet makkelijk op te lossen; ook dat kost weer tijd.

In de toekomst hopen we een basis te leggen dat anderen op een laagdrempelige manier kunnen bijdragen aan het project. Dat moet lekker eenvoudig worden, net zoals het eenvoudig is om bij te dragen aan WikiPedia. In de toekomst zou je:

... ondersteuning kunnen vragen en bieden via custom forum integratie.
... zelf services ontwikkelen en opsturen.
... documentatie en vertalingen aanpassen.
... zelf grafische themes kunnen ontwikkelen.
... maintainer worden van een bepaalde service en die werkende houden en updaten naar nieuwe versies.

Voordat bovenstaande mogelijk is, moet er eerst werk worden verricht om een dergelijke infrastructuur mogelijk te maken. De prioriteit ligt nu bij het releasen van 0.2, dus het opbouwen van de community infrastructuur duurt nog wel even. Tot die tijd kun je via DM of email ideeën of code submitten.

Conclusie: meehelpen aan ZFSguru is niet zo eenvoudig als het lijkt. Hoewel het bieden van documentatie e.d. kan helpen, kost ook dat weer veel moeite en tijd. Het alternatief is om tools te ontwikkelen zodat meehelpen een stuk laagdrempeliger wordt.

Tot slot:
Mocht je meer punten willen toevoegen aan dit overzicht, laat het mij weten!

Verder verzoek ik eenieder om openhartig te zijn met kritiek en aanmerkingen, maar probeer het wel constructief en nuttig te houden. Afkraken zit ik niet op te wachten; het is een gratis product van twee belangenloze mensen die er hun tijd aan besteden. In dat perspectief moet je je adviezen en opmerkingen dan ook kunnen plaatsen; en niet als een klant die eisen stelt bij een gekocht product. Heel soms komt kritiek op die manier wel over, en dan merk ik dat ik het lastig vind om objectief te blijven en de kritiek serieus te nemen.

Het doel van het topic is om over en weer tot nieuwe inzichten te komen. Dit is hét moment om mij te overtuigen!

donderdag 2 januari 2014 15:49

Acties:

0 Henk 'm!

Anoniem: 15758

Topicstarter

*** Reactie van Jason op 3 januari @ 20:21

Dear and valued ZFSguru users,

I have been told by CiPHER that a discussion on the Dutch Tweakers.net forum is going on regarding the ZFSguru project. I have tried to read some stuff with google translate and heard things from CiPHER, but it's still quite unclear to me what issues are being addressed.

Most of the issues I hear revolve around the community not having enough say about the direction of the project, if I understand correctly. But it is unclear to me what direction they would like ZFSguru to take. The other issue is that I'm not being very communicative and you're absolutely right about that. I must apologise to you for that. My presence on the forums was sporadic at best. Thing is, when I'm under pressure I just want to finish what I'm working on. That's why my cell phone is off when I'm coding. It's just the way I work. But I'll try to do better in the future. :-)

Regarding the future of the project, I've said some things about that in my State of the Project 2013. In that document I've conveyed my views on the future of the project. I've also tried to answer the question about what ZFSguru really is. Some people were confused and even unhappy about ZFSguru not being what they thought it was or would become. But it appears to me that they've misunderstood. ZFSguru is about choice. It doesn't want to force anything upon you. Therefore, new functionality which also adds bloat should be optional, integrated in a modular service addon framework, instead of being forced upon all users. I don't own a Mac so I don't want ZFSguru to run AppleShare on my server. That simple! I can imagine the same other users have the same feelings. However to Mac users the AppleShare functionality is important. So to make both users happy, the answer was a true modular design in addon functionality.

The result is that ZFSguru can be whatever you want it to be. You want a light ZFS platform with NAS functionality, then don't install any services! You want it to download torrents or fiddle with newsgroups, go install the respective services. Want it to be a HTPC, go install the graphics server and XBMC. You want it to be your own ZFSguru web-interface + FreeBSD OS box where you want to fiddle with FreeBSD whilst having access to the ZFSguru web-interface? Also possible! I'm simply trying to make all my users happy, avoiding conflicts of interest. Now if some users don't agree with others being able to use said functionality, then I pity them. Because there is no reason to deny other people's desires, especially when they do not conflict with your own. And I do think the service addon framework addresses the issue of conflicts of interest pretty well, indeed!

Last issue I want to address is some things I hear about me being very 'bossy' about ZFSguru and its development goals. It's also been said that I would not allow code contributions, which is totally untrue. I have also read something about me having hypnotised CiPHER into my way of thinking. Seriously, I don't know what makes them think that way. I think I'm a pretty easy going guy and I think CiPHER is as well. We're both quite passionate about our opinions and affections, but I respect other people's opionions just as easily. I think CiPHER is a good match to the ZFSguru project, and I'm happy he's participating. And he can work on whatever he wants. I do not recall anything that I disallowed him to do, but some separation of duty is just common sense. What exactly are we talking about here?

Please do realise I am far from perfect, and I do make mistakes. And there are plenty of small and somewhat bigger mistakes I've made during the course of the ZFSguru project. But despite these mistakes, I do feel I've kept my promise by staying comitted to the project. I am trying to make something cool out of ZFSguru. Right now it is useful but not really sleek. And I do want it to be sleek! Give it some time... in 2014 we may yet surprise you with something really good!

If there's anything you would like to be changed, please convey your suggestions and feedback to me using your forum. I will hear the outcome from CiPHER. Right now, I really really really... want to finish this beta9!

Happy newyear!

Kind regards,
Jason Edwards
Developer of ZFSguru

[ Voor 99% gewijzigd door Anoniem: 15758 op 03-01-2014 20:34 ]

donderdag 2 januari 2014 15:49

Acties:

0 Henk 'm!

Anoniem: 15758

Topicstarter

De conclusie (2 februari 2014)

Het Oude Testament

Anoniem: 15758 in "Discussie over de toekomst van ZFSguru"

Het Nieuwe Testament

Anoniem: 15758 in "Discussie over de toekomst van ZFSguru"

Link naar Wiki

*nog niet operationeel*

Link naar Bugtracker

*nog niet operationeel*

Link naar Repository

*nog niet operationeel*

[ Voor 129% gewijzigd door Anoniem: 15758 op 16-07-2014 23:57 ]

donderdag 2 januari 2014 16:05

Acties:

0 Henk 'm!

FireDrunk

Zfs
ZFSguru
Opslag

Punt 7: Er wordt niet volgens de standaarden in de rest van de wereld geprogrammeerd.
Punt 8: Er wordt voor alles een custom oplossing gemaakt ipv reeds bewezen technieken (Website, Forum, Bugtracker, Javascript / JQuery)
Punt 9: Er wordt veel te weinig aandacht besteed aan security.
Punt 10: Er worden verkeerde prioriteiten gesteld (FreeBSD 10.0 image maken voor een webinterface bug oplossen...)
Punt 11: De source code is niet inzichtelijk.
Punt 12: Er is niet inzichtelijk op welke manier er aan BSD gesleuteld is (er is niet veel gesleuteld, maar dat is alleen maar 'van-horen-zeggen'. De scripts welke een ZFSguru ISO produceren zijn niet duidelijk traceerbaar...

En hernoem het topic aub... Ga niet de zieligerd uithangen... (

)

[ Voor 4% gewijzigd door FireDrunk op 02-01-2014 16:12 ]

Even niets...

donderdag 2 januari 2014 16:36

Acties:

0 Henk 'm!

roy.jacobs

Een uiteenzetting van het verschil tussen 'coder' en 'developer' zou ik ook niet verkeerd vinden

donderdag 2 januari 2014 16:47

Acties:

0 Henk 'm!

Afwezig

Inderdaad, topic hernoemen zou een goed idee zijn. Het lijkt me dat het uitgangspunt constructieve feedback moet zijn, de topictitel vraagt om wat anders

Maar begin met een bugtracker, b.v. redmine. Niet alleen maakt dat voor je gebruikers inzichtelijk wat de bugs zijn, maar je kan ook op een gestructureerde wijze je gebruikers laten meedenken over oplossingen. Kan alleen maar goed zijn.

Bij afwezigheid van documentatie is het maken van een wiki wel het makkelijkste wat je kunt doen, zodat gebruikers die dat zouden willen, documentatie kunnen bijdragen. Als dan je custom oplossing af is, kan je die data direct inpassen in je nieuwe systeem. Alleen maar winnaars tegen bijna geen moeite.

Maar wie gaat er uren vrije tijd spenderen aan ZFSguru? Wie van jullie is bereid dat te doen? Tot nu toe niemand.

Ik ben iemand met veel vrije tijd en mogelijkheden. Stel nu dat ik bijvoorbeeld iets in de richting van documentatie zou willen doen? Hoe? Ik weet niet of ik bereid ben om het te doen als ik niet weet hoe ik het moet doen en of dat een manier is die voor mij werkt.

donderdag 2 januari 2014 16:47

Acties:

0 Henk 'm!

Midas.e

Is handig met dinges

Het enige wat ik graag wil opgeven is dat hoewel de BSD licentie vrij open is ZFSguru hier wel mee breekt. De software die jullie gebruiken is opensource en daarvoor dient de source ook open inzichtelijk te zijn.

Hacktheplanet / PVOutput

donderdag 2 januari 2014 16:50

Acties:

0 Henk 'm!

Afwezig

Midas.e schreef op donderdag 02 januari 2014 @ 16:47:
Het enige wat ik graag wil opgeven is dat hoewel de BSD licentie vrij open is ZFSguru hier wel mee breekt. De software die jullie gebruiken is opensource en daarvoor dient de source ook open inzichtelijk te zijn.

Volgens mij mag je BSD code opnemen in je eigen product zonder zelf de source code openbaar te maken. Zie bijvoorbeeld Playstation 4. Het is geen GPL.

donderdag 2 januari 2014 16:52

Acties:

0 Henk 'm!

Midas.e

Is handig met dinges

Afwezig schreef op donderdag 02 januari 2014 @ 16:50:
[...]

Volgens mij mag je BSD code opnemen in je eigen product zonder zelf de source code openbaar te maken. Zie bijvoorbeeld Playstation 4. Het is geen GPL.

Klopt, je dient alleen wel code van andere aan te geven. Het mooiste zou zijn als ZFSguru op github zou verschijnen zodat iedereen hier een fork van zou kunnen maken en/of helpen met de ontwikkeling.

Hacktheplanet / PVOutput

donderdag 2 januari 2014 17:05

Acties:

0 Henk 'm!

roy.jacobs

CiPHER schreef op donderdag 02 januari 2014 @ 17:04:
Bijna alles is sourcecode, dus de .php scripts, de service scripts (Bourne shell) en run control scripts. De web-interface is los downloadbaar, de services ook maar alleen via de web-interface.

Dat snap ik, ik bedoel meer: Is er ergens een repository te vinden?

donderdag 2 januari 2014 17:07

Acties:

0 Henk 'm!

Anoniem: 15758

Topicstarter

En hernoem het topic aub... Ga niet de zieligerd uithangen... ()

Ik vond het wel grappig, mijn eigen bashing topic.

Het feit dat er zoveel over wordt gesproken is in elk geval een compliment, want als het project door niemand serieus genomen zou worden, zou er ook geen haan naar kraaien.

roy.jacobs schreef op woensdag 01 januari 2014 @ 20:37:
Is er uberhaupt ergens source code te vinden?

Bijna alles is sourcecode, dus de .php scripts, de service scripts (Bourne shell) en run control scripts. De web-interface is los downloadbaar, de services ook maar alleen via de web-interface.

syl765 schreef op woensdag 01 januari 2014 @ 20:39:
Dat vraag ik mij ook af?

Word er ook aan FreeBSD zelf gesleuteld of is het gewoon een standaard FreeBSD met de zfsGuru GUI on top.

Gesleuteld in de zin van workarounds in services en systeemversies, en default configfiles en custom scripts. Ook de kernel krijgt extra functionaliteit mee die niet in GENERIC zit, zoals InfiniBand networking en device polling support. Dat laatste zorgt voor lager CPU-usage bij netwerkactiviteit. Maar het zit heel dicht tegen vanilla FreeBSD aan. Dat is ook de bedoeling. In de toekomst zou ZFSguru als port/package op BSD geinstalleerd kunnen worden.

Maar ZFSguru is vandaag de dag al veel meer dan alleen een web-interface wat op BSD werkt. Met alle inspanningen voor systeemarchitectuur en services is het onderhand een eigen OS / distributie geworden. Heel anders dan napp-it wat inderdaad een losse interface is wat je zelf op een plain OS (OpenIndiana of SmartOS) installeert. Gevolg is wel dat napp-it completer is. Echter niet zo laagdrempelig als ZFSguru en ook weinig unieke features zoals ZFSguru wel heeft. Denk aan de partition map editor en de advanced disk benchmark. Kwaliteitsfeatures die 100% in-house zijn ontwikkeld. Daar komt nu de Samba, NFS en user drag en drop-interface bij; ook vrij uniek denk ik. Alles om ervoor te zorgen dat belangrijke functionaliteit gemakkelijk, veilig en goed werkt.

Wouter.S schreef op woensdag 01 januari 2014 @ 20:33:
No offence CiPHER, maar (..) sinds je betrokken bent geraakt is het precies of Jason je gebrainwashed heeft.

Misschien zijn de afwijkende opvattingen ook wel deels te relateren aan mijzelf. Wij zijn beide geen doorsnee developers, maar hebben een boel opvattingen over dingen.

Jullie willen een compleet pakket neerzetten dat in één klap perfect is...met twee man...met beperkte kennis en ervaring...ambitie is één ding maar je kan ook gewoon te hoog grijpen.

Niet in één klap, maar met tussenfasen. 0.2 is een belangrijke tussenfase. Dus er zijn korte en lange termijndoelen. Je hebt wel een punt als je zegt dat de ambitie te hoog is met wat gezien de beschikbare resources redelijk en haalbaar is. Maar dat ligt denk ik in het karakter van ons beiden om hoog te grijpen. Dat zit nu eenmaal in de aard van het beestje.

Een community bouw je op door vertrouwen en wederzijds respect, van geen van beide is hier sprake en dit zal er ook niet komen door een 'super-speciale-mega-release' die al het voorgaande moet doen vergeten.

Misschien is er wel te weinig respect voor de grote plannen en mooie ideeën. Misschien moeten jullie gebruikers gewoon geduldig zijn en tevreden met wat je nu al hebt. Als je over wederzijds respect spreekt, betekent dat ook respect voor de inspanningen die iemand zonder tegenprestatie levert. Dat het dan niet volgens jouw opgegeven specificaties wordt uitgevoerd kun je ons niet kwalijk nemen. Misschien zeg je over één à twee jaar wel dat we misschien toch een punt hadden en dat er wel degelijk veel bereikt is met alle inspanningen die nu worden bekritiseerd. Alles is mogelijk!

Maar ik krijg soms het gevoel dat het niet 'mag' wat wij doen. Dat vind ik wel vreemd. Ik kan begrijpen dat je van mening bent dat de ontwikkeling anders zou moeten. Maar een (chef)kok die de opdrachten moet uitvoeren van een ander werkt over het algemeen minder goed dan wanneer iemand zijn eigen creativiteit kan ontplooien. Dus als we over respect praten betekent dit ook respect voor de gekozen optie, ook al sta je daar zelf niet achter.

Wat wel helpt is constructieve feedback. Alternatieven die nog niet bekend waren of voldoende verkend, onduidelijkheid in de web-interface over een bepaald iets, suggesties voor een concrete verbetering; dat zijn dingen waar heel concreet gevolg aan kan worden gegeven. En dat is ook volop gebeurd. De Apple-functionaliteit is door pdonovan op het forum gestuurd door als bèta-tester feedback te geven. Kennis die Jason noch ikzelf over beschikten omdat wij geen Mac hebben. Uiteindelijk is er een werkende service uit gekomen en staan er plannen voor om de nieuwe versie 3 van netatalk van een panel interface te voorzien.

Q schreef op woensdag 01 januari 2014 @ 20:59:
@CiPHER: ik schaar mij achter de tekst van Wouter.S hierboven. Dat is precies de essentie die ik lees.

Ik vind dat je met zo'n uitspraak (wat jij belangrijk vind, vinnen wij triviaal) eigenlijk alleen maar je vingers in je oren steekt en mensen met wat 'opmerkingen' gewoon overschreeuwt. Maar je laat eigenlijk niet eens zien dat je de kritiek fundamenteel begrijpt.

Het gaat mij niet om de defecte feature zelf. Het gaat om de mentaliteit die er uit spreekt.

Welke mentaliteit doel je op dan? Dat de gebruikers niet belangrijk zijn ofzo? Misschien dat dat bij jou zo overkomt, maar het belang van tienduizenden gebruikers in de toekomst met een waardevol product is natuurlijk groter dan het belang van honderden tot duizenden nu met een 'geinig' product wat nog niet helemaal serieus te nemen valt. We moeten werken aan de dag van morgen. Alles nu op orde krijgen kost veel energie en 'drive' die je hebt bij nieuwe ideeën. Uiteindelijk gaat dat ten koste van het eindresultaat.

Het klinkt een beetje alsof we een jaar lang onze gebruikers in de kou hebben laten staan met een defect product. Dat is niet zo! De sLOG bug kun je noemen, maar zoveel werd deze feature niet gebruikt en de workaround is voorhanden. Het prodoct bleef werkend en ondertussen zijn we hard bezig met de fundering van het product van morgen. Mooi toch?

Ja precies 'jouw shit'. ZFSguru lijkt wel een ego-document van jou en Jason.

Wat ik ermee bedoel is dat als in de toekomst ZFSguru inderdaad uitgroeit tot iets groters en veelzijdigers, de mensen die nu kritiek hebben wellicht evengoed gebruikers kunnen worden. Gebruikers van een product wat als het aan hen had gelegen nooit had (mogen) bestaan.

donderdag 2 januari 2014 17:31

Acties:

0 Henk 'm!

Anoniem: 15758

Topicstarter

Afwezig schreef op donderdag 02 januari 2014 @ 16:47:
Maar begin met een bugtracker, b.v. redmine. Niet alleen maakt dat voor je gebruikers inzichtelijk wat de bugs zijn, maar je kan ook op een gestructureerde wijze je gebruikers laten meedenken over oplossingen. Kan alleen maar goed zijn.

Maar als gebruikers ook moeten inloggen, moet dat dan met nieuwe accounts of wordt het wachtwoord gedeeld? Bij dat laatste is ook weer de overweging of het wel veilig is.

Daarnaast had ik een tijd terug alle open source bugtrackers eens bekeken qua screenshots en demo's. Er zaten wat kandidaten tussen, maar heel positief was ik niet echt. Een lekker duidelijke no-nonsense interface was er niet echt, velen erg nerdy. Anderen weer met tig opties.

Sowieso vertrouw ik (en jason ook) de security niet van dit soort pakketten. Servers worden vaak gehackt doordat een bepaald softwarepakket vulnerabilities heeft en niet wordt gepatched of er is nog geen patch. Dus als we dit soort pakketten gebruiken - al is het tijdelijk - dan moet dat in een jail. Dan zit je weer met IPs want je kunt geen drie jails dezelfde poort 80 laten gebruiken.

Conclusie was dat een eigen server ipv VPS toch wel fijn zo zijn. Met meerdere IPs zodat we veilig kunnen uitbreiden en security is ook veel fijner als je een eigen dedicated server hebt ipv VPS'en. In elk geval de master server (alpha) zou daar baat bij hebben.

Kortom, iets wat een klein iets lijkt, kost uiteindelijk toch weer veel tijd en moeite, als je het goed wilt doen in elk geval. Maar een bugtracker gaat er zeker komen!

Bij afwezigheid van documentatie is het maken van een wiki wel het makkelijkste wat je kunt doen, zodat gebruikers die dat zouden willen, documentatie kunnen bijdragen. Als dan je custom oplossing af is, kan je die data direct inpassen in je nieuwe systeem. Alleen maar winnaars tegen bijna geen moeite.

Helemaal mee eens. Tijdelijk iets anders gebruiken is het probleem niet zo. Maar ook bij een wiki geldt dat er security issues mogelijk zijn. Dat is niet fijn om op dezelfde server te draaien als waar jullie gebruikers je checksums e.d. vandaan haalt. Dus ook hier weer is een eigen server wenselijk met goede privilege-separation middels BSD Jails.

Ik ben iemand met veel vrije tijd en mogelijkheden. Stel nu dat ik bijvoorbeeld iets in de richting van documentatie zou willen doen? Hoe? Ik weet niet of ik bereid ben om het te doen als ik niet weet hoe ik het moet doen en of dat een manier is die voor mij werkt.

Guides schrijven hoe je dingen werkend hebt gekregen. Of zoals Kriss heeft gedaan een installer schrijven voor BSD en andere OS (de LaSi installer). Dat vereist wel coding-ervaring. Maar stel je bent een webdeveloper en je kunt een heel mooi web-ontwerp maken en als ZFSguru theme implementeren. Dat laatste kan met wat hulp van ons, als de ander een mooi ontwerp in HTML+CSS heeft gemaakt.

Dus er zijn wel degelijk gebieden waar je prima kunt meewerken. Andere gebieden zijn veel lastiger en minder laagdrempelig.

donderdag 2 januari 2014 18:02

Acties:

0 Henk 'm!

Anoniem: 15758

Topicstarter

roy.jacobs schreef op donderdag 02 januari 2014 @ 16:36:
Een uiteenzetting van het verschil tussen 'coder' en 'developer' zou ik ook niet verkeerd vinden

Een coder is een programmeur. Het stereotype is dat van een 'nerd' die als wiskundig briljant iemand goede structuren kan maken en herkennen in programmeercode. Deze vaardigheden komen van pas bij het moeilijkere en abstracte programmeerwerk, waarbij bugs op de loer liggen en de code vaak heel 'dense' is en veel voorkennis vereist om goed te kunnen begrijpen. Terwijl dergelijke personen briljant in het ene kunnen zijn, kunnen ze benedengemiddeld presteren op andere gebieden. Sociale vaardigheden zijn vaak een stuk minder goed, het kunnen verplaatsen in andere mensen ook minder goed. Daarnaast is de denkwijze verschillend dan van veel andere mensen. Dat zie je terug bij interface-ontwerp, waarbij nerdy interfaces met veel knopjes een onrustige en onduidelijke indruk geven bij de massa. Een mooi voorbeeld zijn de nerdy interfaces die Apple heeft opgedoekt, en navigatie en human interaction een heel stuk menselijker heeft gemaakt. Minder autistisch, zou ik zeggen.

Kenmerkend aan een coder is dat van iemand die de code als doel ziet. De code dient aan de hoogst mogelijke eisen te voldoen.

Een developer of ontwikkelaar, is iemand die iets ontwikkelt. Die streeft naar een eindresultaat wat in zijn hoofd zit. Net zoals een beeldhouwer al weet wat er uit de steen gaat komen. In contrast met de coder is de ontwikkelaar minder kritisch over code. De code is een stuk gereedschap om het doel te bereiken, geen doel opzich. Waar de coder voldoening haalt bij het optimaliseren en opschonen van code, haalt de ontwikkelaar voldoening bij bereikte mijlpalen en de progressie richting het einddoel.

Een goede ontwikkelaar kan iemand zijn die slecht programmeercode kan schrijven, een goede coder daarentegen kan wel goed programmeercode schrijven, dat is pretty much self-explanatory.
Een ontwikkelaar kan iemand zijn met veel radicale ideeën waarvan uiteindelijk slechts enkele succesvol blijken. Een coder is iemand die doorgaans veel conservatiever te werk gaat met kleine stapjes; meer rechtlijnig denken en doen. De coder geeft om het behouden en verbeteren van het huidige, terwijl de ontwikkelaar meer energie steekt in nieuwe ideeën.

Dit is ongeveer mijn idee van het verschil tussen developer en coder. De developer ontwerpt software, de coder programmeert deze. Oftewel de developer bedenkt het en de coder voert het uit. Vaak is er wel een overlap, net zoals de VVD niet 100% rechts is en de PVDA niet 100% links. Het zijn ook maar hypothetische stereotypen. De praktijk is altijd complexer.

donderdag 2 januari 2014 18:43

Acties:

0 Henk 'm!

EnerQi

• Punt 1: de voortgang van de Web-interface gaat te traag.
• Punt 2: in beta8 zitten bugs zoals het niet kunnen toevoegen van slog.
• Punt 3: de communicatie verloopt stroef en de website is verouderd.
• Punt 4: de richting van ontwikkeling is onduidelijk, verkeerd of roept vragen op.
• Punt 5: de ontwikkeling wordt gedomineerd door Jason en anderen hebben geen inbreng.
• Punt 6: hulp wordt niet gewaardeerd.

Punt 1 + 2 + 3:

Het klinkt een beetje alsof we een jaar lang onze gebruikers in de kou hebben laten staan met een defect product.

Mijn vrees slaat weer terug op het communiceren, ik denk meer aan een dood product ipv defect product.
Ga iedere maand een update geven van dingen waaraan je gewerkt hebt (of welke interval dan ook

) en zet er een mooi screenshot bij. Het laat zien dat het project niet dood is en dat de verwachtingen van mensen ook beter gemanaged wordt.

Punt 4 en 5
Terecht dat nu een het feestje van Jasen en CiPHER is, maar wanneer verwacht je van je community input welke richting/features ze graag willen zien? Er is ooit een topic geweest die dat vroeg maar daar is nog niet veel mee gedaan (logisch, het project heeft een lange doorlooptijd). Ook de roadmap is out-dated en dat schept weer verwachtingen van potentiele users / huidige gebruikers.

Punt 7: Er wordt niet volgens de standaarden in de rest van de wereld geprogrammeerd.
Punt 8: Er wordt voor alles een custom oplossing gemaakt ipv reeds bewezen technieken (Website, Forum, Bugtracker, Javascript / JQuery)

Punt 7 + 8
Dat boeit een normale gebruiker niet

. Het maakt het project wel moeilijker om hulp te krijgen wat dus een risico is op doodbloeden als Jason en CiPHER stoppen.

De overige puntjes kan ik weinig over zeggen, zover reikt mijn kennis niet.

donderdag 2 januari 2014 18:59

Acties:

0 Henk 'm!

roy.jacobs

Het wekt, voor mij dan, niet zo veel vertrouwen dat jullie met een miniem team niet alleen NAS software bouwen maar ook meteen maar even niks willen hergebruiken qua forum software, niks hergebruiken qua web toolkits, niks hergebruiken van bestaande software methodologie, etc.

Sowieso vertrouw ik (en jason ook) de security niet van dit soort pakketten. Servers worden vaak gehackt doordat een bepaald softwarepakket vulnerabilities heeft en niet wordt gepatched of er is nog geen patch.

Dus alles wat jullie zelf schrijven zal geen vulnerabilities hebben?

Er is nogal wat sprake van NIH.

donderdag 2 januari 2014 19:05

Acties:

0 Henk 'm!

Anoniem: 15758

Topicstarter

Eigen features wordt inderdaad verkozen boven pakketten van derden. Zeker op lange termijn heeft dat grote voordelen.

Maar alle services hergebruiken natuurlijk wel de creatie van anderen. Inclusief web-interfaces en grafische frontends. Voor sommige services heeft ZFSguru een eigen web-interface geschreven. Dus het is ook niet zo dat alles in-house moet. Maar in de kern allerlei dependencies hebben is iets wat we willen voorkomen. Het principe is dat bloat als addon moet, niet default in het standaardpakket. Zo kun je lekker met een vrij kale basis beginnen en andere dingen toevoegen - die kunnen falen - naar wens.

donderdag 2 januari 2014 20:48

Acties:

0 Henk 'm!

Dadona

Maar waarom niet simpelweg iets gebruiken als overbrugging. Bijvoorbeeld een standaard forum (phpBB), standaard wiki (mediawiki), ... Vanaf het moment dat de wereld verbeterende oplossing van jullie hand daar is dan zal het toch wel mogelijk zijn om een set conversie-queries te schrijven.

De CSL/OT kroeg !

donderdag 2 januari 2014 20:59

Acties:

0 Henk 'm!

Anoniem: 15758

Topicstarter

Omdat ik het ook ergens moet kunnen hosten. En aparte user-registratie is ook weer wat. En mails vanaf mijn eigen hosts komen niet altijd aan, door de strenge spamregels van Google enzovoorts. Er zijn allemaal belemmeringen om dit 'eventjes snel' te doen.

Dus het is niet dat een tussenoplossing niet gewenst is, maar meer dat het op heel korte termijn toch lastig is. Misschien dan beter om nu door te werken aan ZFSguru zelf en pas bij de nieuwe server met jails en eigen IPs een geisoleerde service op te zetten, waaronder zeker een wiki dat vind ik een heel goed idee en mis ik zelf ook heel erg. Ook leuk dat ieder kan meeschrijven, dat kan het begin van de participatie zijn van de community rond ZFSguru.

Maar alles kan niet tegelijk. Dus logisch dat een boel zaken blijven liggen omdat het releasen van beta9 bijvoorbeeld toch echt prioriteit heeft. Zelfs nu is Jason er nog niet klaar mee. Misschien wel jullie schuld, jullie hebben mij weg gehouden van Jason en kijk het resultaat!

Nee serieus, ik vind het leuk om de suggesties en aanmerkingen door te nemen, en een gedeelte ervan is goed bruikbaar. Er zijn ook suggesties waar ik niet zoveel mee kan, of toch echt moeilijker zijn in de praktijk dan het klinkt. En moeilijker betekent gewoon tijd; dan schuift al het andere weer weken op. Dat is de prijs die je dan betaalt. Je kunt geld wel twee keer uitgeven - dat doen de banken immers ook, daar komen ook alle problemen vandaan - maar je tijd kun je maar één keer uitgeven.

donderdag 2 januari 2014 21:02

Acties:

0 Henk 'm!

Dadona

Serieus, als hosting nu echt het punt is (nog los van dat de site nu ergens staat) dan heb je daar zo een mouw aan vast. Als er al niet iemand is die toch in de hosting zit (gezien het type product niet geheel onwaarschijnlijk) dan heb je dat met de meest minimale donatie al wel zo ergens geregeld.

De CSL/OT kroeg !

donderdag 2 januari 2014 21:10

Acties:

0 Henk 'm!

Hakker

a.k.a The Dude

Ik wil niet lullig doen maar nu maak je een simpel probleem onnodig moeilijk. 1x registreren voor meerdere plekken is al heel lang mogelijk en ook op meerdere servers. Dat is zowat nog sneller in te voeren dan het installeren van de pakketten an sich.

Artificial Intelligence is no match for natural stupidity | Mijn DVD's | Mijn Games | D2X account: Hakker9

donderdag 2 januari 2014 21:14

Acties:

0 Henk 'm!

Anoniem: 15758

Topicstarter

@Dadona
Maar als er toch al plannen zijn voor een nieuwe master server - dedicated ipv de VPS die we nu hebben - dan is het misschien niet erg om daar nog op te wachten. Dat hoeft geen jarenplan te worden. Ik heb voor nieuwjaar al naar wat hardware gezocht en misschien over een paar maanden draait ie. Dan kunnen we allerlei dingen draaien op hun eigen IP en volledig afgeschermd van elkaar.

Blijft dan over de loginprocedure, ook afgeschermd is het natuurlijk een risico als je hetzelfde wachtwoord gebruikt voor alle logins. Zeker aangezien ZFSguru in de toekomst de login best belangrijk wilt maken omdat deze toegang geeft tot allerlei persoonlijke dingen; zoals priveverichten met andere gebruikers.

Dus voor de veiligheid is een aparte loginprocedure met het verzoek om verschillende wachtwoorden gebruiken dan wel beter. Het allemaal nèt niet even van 'dit ga ik nu eventjes fixen'. Met een dedicated server kan dat wel op de goede manier gebeuren.

Er is dan ook geen reden meer om geen wiki e.d. te draaien; het kost toch maar één IP dus ongeveer een euro per maand extra. Dat is het probleem niet; Jason heeft bij elkaar al meer dan 2000 dollar betaald aan hosting en andere zaken zoals de build server. Zou leuk zijn als er in de toekomst donaties gebeuren, maar dat we allebei onze tijd, energie en geld erin steken is niet zo'n groot punt. Dat hebben we er beide voor over, en de tijd en energie zijn daarbij ook veel meer waard dan die paar centen.

donderdag 2 januari 2014 21:46

Acties:

0 Henk 'm!

Wouter.S

e^(i*pi ) +1 = 0

Anoniem: 15758 schreef op donderdag 02 januari 2014 @ 17:07:
Misschien is er wel te weinig respect voor de grote plannen en mooie ideeën. Misschien moeten jullie gebruikers gewoon geduldig zijn en tevreden met wat je nu al hebt. Als je over wederzijds respect spreekt, betekent dat ook respect voor de inspanningen die iemand zonder tegenprestatie levert. Dat het dan niet volgens jouw opgegeven specificaties wordt uitgevoerd kun je ons niet kwalijk nemen. Misschien zeg je over één à twee jaar wel dat we misschien toch een punt hadden en dat er wel degelijk veel bereikt is met alle inspanningen die nu worden bekritiseerd. Alles is mogelijk!

Maar ik krijg soms het gevoel dat het niet 'mag' wat wij doen. Dat vind ik wel vreemd. Ik kan begrijpen dat je van mening bent dat de ontwikkeling anders zou moeten. Maar een (chef)kok die de opdrachten moet uitvoeren van een ander werkt over het algemeen minder goed dan wanneer iemand zijn eigen creativiteit kan ontplooien. Dus als we over respect praten betekent dit ook respect voor de gekozen optie, ook al sta je daar zelf niet achter.

Het is waar dat ik als gebruiker geen eisen kan opleggen en dat was zeker ook niet mijn bedoeling, alles is veeleer te lezen als mijn wensen.

Ik denk dat het probleem is, dat ik ervan uit ging dat ZFSGuru opensource was. Dit is het dus niet, en misschien is kunnen jullie dit beter duidelijk vermelden op de site.

Het is eerder een OS/toepassing die gratis te gebruiken is en in de toekomst is het de bedoeling dat gebruikers (in mijn ogen) zeer beperkt kunnen bijdragen aan het geheel in de vorm van services schrijven of theme packs voor de webinterface. Om het met een voorbeeld uit te drukken zou ik zeggen dat ZFSGuru een volledige auto is. Van de motor, aandrijftrein, ophanging en dergelijke blijf je af, deze worden onderhouden in de garage (=Jason en CiPHeR). Maar je mag wel zelf je muziek kiezen die je luistert, en je kan een hoes kopen om over de zetels te doen als je het kleur van de bekleding beu bent

Anoniem: 15758 schreef op donderdag 02 januari 2014 @ 17:07:
Wat wel helpt is constructieve feedback. Alternatieven die nog niet bekend waren of voldoende verkend, onduidelijkheid in de web-interface over een bepaald iets, suggesties voor een concrete verbetering; dat zijn dingen waar heel concreet gevolg aan kan worden gegeven. En dat is ook volop gebeurd.

Ik denk dat iedereen wel constructief wil zijn, met het nodige wederzijdse respect. Maar kan je met enkele concrete voorbeelden tonen waar er al ergens rekening is gehouden met voorstellen/tips?

Anoniem: 15758 schreef op donderdag 02 januari 2014 @ 17:07:
Dit is ook een punt wat regelmatig ter sprake komt, maar weinig concrete voorbeelden kent. Als je een mooie toevoeging kunt maken aan ZFSguru is die hulp zeker welkom. Maar wie gaat er uren vrije tijd spenderen aan ZFSguru? Wie van jullie is bereid dat te doen? Tot nu toe niemand.

HOE moet een welwillend persoon met de juiste vaardigheden dan helpen ? Er is geen documentatie, onderliggende code en scripts zijn niet openbaar... waar staat de vacature op de site waar mensen kunnen appliceren.

Ik heb eerder de indruk dat jullie af en toe wel laten uitschijnen hulp te zoeken maar eigenlijk wordt er liever met twee verder gedaan. Het is een beetje het kip/ei verhaal. Men wil documentatie...teveel werk om tijdelijk te doen, past niet in het lange termijn concept. Men wil helpen met communicatie...onmogelijk want het warm water moet eerst opnieuw worden uitgevonden om een website te kunnen draaien?

Er wordt als het ware gewerkt aan een prototype van een apparaat, maar om het bedrijf op te richten dat dit apparaat op de markt moet brengen is het business-plan nog niet geschreven, sterker nog de manier waarop het business-plan gemaakt moet worden moet eerst nog heruitgevonden worden door dit onbestaande bedrijf

Maar, ondertussen blijf ik wel trouw ZFSGuru draaien op mijn NAS, want stabiel is het in ieder geval $_/-\o_$
Ik blijf dus gewoon geduldig afwachten als tevreden gebruiker.

Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction.

donderdag 2 januari 2014 21:55

Acties:

0 Henk 'm!

Aganim

I have a cunning plan..

Hmm, even een snelle post tussendoor.

Allereerst een korte achtergrond: momenteel ben ik thuis ZFS aan het testen, het doel is (naast een persoonlijk tekort aan opslagruimte voor de komende jaren oplossen

) te bepalen of we ZFS in gebruik kunnen gaan nemen in een zakelijke hostingomgeving. Het gaat dan om machines die backups van het serverpark gaan opslaan. Let wel, het gaat nog niet om concrete plannen, voorlopig eerst eens bepalen of ZFS stabiel en betrouwbaar genoeg is.

De installatie van mijn server is alweer een week of twee geleden, wellicht heb ik zaken over het hoofd gezien, maar wat me zo snel bij staat:

De installer toonde standaard het IP adres van de Infinibandkaart als adres voor de webconfig van de server, maar niet van de netwerkkaart. Laat mijn Infinibandkabel nu net 10 CM te kort zijn (de uiteindelijke was nog in bestelling), dus verdere configuratie via de webinterface was nodig via LAN. Nu wist ik toevallig het IP adres uit FreeNAS nog, dus dat viel mee. Maar voor een gebruiker is het natuurlijk prettiger als je een overzicht te zien krijgt van gevonden netwerkkaarten + bijbehorende IP adressen. (De standaard gebruiker zal natuurlijk niet zo snel inloggen en even ifconfig draaien.)

Wat ik daarnaast mis (voor zover ik heb gezien) zijn rapportage/alarm meldingen per mail. Bijvoorbeeld bij een uitgevallen L2ARC/SLOG/HDD) of na een (al dan niet succesvolle) scrub of resilver.
Dit vind ik voor thuisgebruik eigenlijk al een must, maar voor zakelijk gebruik is het uiteraard onontbeerlijk.

Dit zijn slechts de punten die me zo snel te binnen schieten en nog niet genoemd zijn hierboven, ik hoop wat meer inhoudelijkere punten op te brengen als ik daadwerkelijk aan de slag kan met de bak.

donderdag 2 januari 2014 22:09

Acties:

0 Henk 'm!

Anoniem: 15758

Topicstarter

Wouter.S schreef op donderdag 02 januari 2014 @ 21:46:
Het is waar dat ik als gebruiker geen eisen kan opleggen en dat was zeker ook niet mijn bedoeling

Het punt is ook dat een gebruiker van te voren niet kan weten wat een ontwerper precies van plan is. Soms betekent dit dat je als gebruiker moet afwachten wat er uit de koker komt van een bepaald project of team.

Ik denk dat het probleem is, dat ik ervan uit ging dat ZFSGuru een opensource was. Dit is het dus niet, en misschien is kunnen jullie dit beter duidelijk vermelden op de site.

Je bedoelt dat het geen community-project is. Nee dat klopt, maar nergens wordt ook elders beweerd. Open source is het per definitie, omdat de (.php) broncode gewoon plaintext beschikbaar is, evenals de scripts.

Het is eerder een OS/toepassing die gratis te gebruiken is en in de toekomst is het de bedoeling dat gebruikers (in mijn ogen) zeer beperkt kunnen bijdragen aan het geheel in de vorm van services schrijven of theme packs voor de webinterface. Om het met een voorbeeld uit te drukken zou ik zeggen dat ZFSGuru een volledige auto is. Van de motor, aandrijftrein, ophanging en dergelijke blijf je af, deze worden onderhouden in de garage (=Jason en CiPHeR). Maar je mag wel zelf je muziek kiezen die je luistert, en je kan een hoes kopen om over de zetels te doen als je het kleur van de bekleding beu bent

Wel een grappige analogie! Maar is het bij Ubuntu anders, om maar wat te noemen? Of Mac OSX? Het onderliggende OS is ook gewoon open source code, maar daar komt niet iedereen aan. Linux torvalds is als een dictator de baas wat er in Linux komt en wat niet. Dat is ook goed voor een project van die klasse, een strenge portier die de knoop doorhakt wat erin komt en wat niet.

Echter wil ik wel bestrijden dat de manier om mee te helpen in de toekomst beperkt zou zijn. Het haalt juist het beste van mensen naarvoren. Anderstaligen kunnen vertalingen opsturen; dat gaat mijzelf en Jason niet lukken. Grafisch ontwerpers kunnen themes maken en de visuele looks verbeteren van ZFSguru. Maintainers van een bepaalde service kunnen updates doen en via een web-interface kun je je eigen service ontwikkelen. En last but not least: het helpen van elkaar bij problemen. Hoe doe je X in virtualbox, hoe werkt Y in Transmission, wat doe ik met probleem Z in SABnzbd+ service... allemaal vragen waar de community elkaar kan helpen. De ideeën hiervoor zorgen ervoor dat helpen ook leuk en laagdrempelig is.

Dat zijn toch best wat dingen die je als community kunt toevoegen? Natuurlijk is er tegen die tijd ook een bugtracker en kun je eventueel meeontwikkelen aan de web-interface zelf. Maar afgezien van wat bruikbare patches verwacht ik er niet zo heel veel van. Niet in dit stadium van het project. Wellicht later dat ontwikkeling van de kern ook door derden gebeurt. Voor nu is het niet zo'n probleem dat dit in handen blijft van één of twee ontwikkelaars.

Ik denk dat iedereen wel constructief wil zijn, met het nodige wederzijdse respect. Maar kan je met enkele concrete voorbeelden tonen waar er al ergens rekening is gehouden met voorstellen/tips?

Nouja om te beginnen heb ik dit topic geopend en alle kritiekpunten op een rij gezet. En daar centraal een reactie op gegeven, die ik wellicht nog kan aanpassen als er tot nieuwe inzichten wordt gekomen.

De goede tips genoemd tot nu toe zijn:

wiki waar gebruikers aan kunnen toevoegen
bugtracker
iemand die als communicatiechef optreedt richting de community

HOE moet een welwillend persoon met de juiste vaardigheden dan helpen ? Er is geen documentatie, onderliggende code en scripts zijn niet openbaar... waar staat de vacature op de site waar mensen kunnen appliceren.

Nu is dat gewoon heel lastig. Het project is nog niet toe aan brede community development. Al zou het dat zijn, er zijn hoogstwaarschijnlijk niet genoeg mensen die serieus tijd aan het project zouden willen besteden.

Het is niet zo erg denk ik zelf. De invloed van de community gaat vanzelf groeien als deze meer knopjes tot zijn beschikking krijgt. En die knopjes.. juist.. die maken Jason en ik. Dus gun ons de tijd om die realiteit te verwezenlijken. Een alternatief is er niet; het documenteren van heel ZFSguru zou ook een maand of twee kunnen kosten. Dan zou denk ik geen goede prioriteitenplanning zijn.

Ik heb eerder de indruk dat jullie af en toe wel laten uitschijnen hulp te zoeken maar eigenlijk wordt er liever met twee verder gedaan. Het is een beetje het kip/ei verhaal. Men wil documentatie...teveel werk om tijdelijk te doen, past niet in het lange termijn concept. Men wil helpen met communicatie...onmogelijk want het warm water moet eerst opnieuw worden uitgevonden om een website te kunnen draaien?

Haha. Nouja je hebt wel een punt dat de beperkte documentatie ook de hulp niet bevordert. Maar even serieus, denken jullie echt dat als wij die 2 maanden nu gaan besteden aan het schrijven van documentatie dat opweegt tegen de extra commits die we zouden mogen verwachten? Ik geloof daar niet zo in... niet alsof het dan gaat regenen van alle hulp van buitenaf. Niet iedereen kan coden, en ZFSguru zoals FireDrunk ook al aangaf geen project wat conform algemene conventies is geschreven. Het heeft een smaakje wat je moet bevallen, als ik het zo mag uitdrukken.

Maar, ondertussen blijf ik wel trouw ZFSGuru draaien op mijn NAS, want stabiel is het in ieder geval $_/-\o_$

Laat ik dan toch herhalen: dan is het toch allemaal niet zo erg dat het iets langer duurt allemaal en de documentatie er niet is enzovoorts? Gedurende die tijd deed ZFSguru prima zijn werk. Alleen die sLOG-bug dan is het enige smetje. Maar afgezien daarvan heeft alles prima gedraaid en in 2013 zijn er veel nieuwe services en systeemversies gekomen. Ook is een basis gelegd voor wat nog komen gaat. Allemaal goed nieuws denk ik, twee developers die samen leuke ideeën hebben en samen grotendeels op één lijn zitten en beide sterk gedreven zijn... daar kunnen mooie dingen uit voortkomen.

Ik wil niet de indruk wekken dat ik de kritiek opzij schuif of niets mee doe. Echter hoop ik ook jullie enigszins te kunnen overtuigen dat alle goedbedoelde adviezen niet altijd praktisch uitvoerbaar zijn. Het blijft neerkomen op: wacht maar af wat het in de toekomst gaat worden. Daarnaast kun je ook kijken naar wat nu beschikbaar is. Dat werkt prima. ZFSguru loopt qua systeem voorop met de overige projecten.

vrijdag 3 januari 2014 08:56

Acties:

0 Henk 'm!

FireDrunk

Zfs
ZFSguru
Opslag

Wat denk ik belangrijk is, is dat je je beseft dat je niet alles alleen moet willen doen, totdat die tools er zijn.
Wat let het je om een Wiki te openen, en een selectief aantal mensen daar rechten op te geven.
Zodra SUB-Mesa af is kan je toch altijd migreren?

Datzelfde geldt voor de bugtracker, wat let het je om nu een bugtracker te openen (Redmine is echt super gaaf en werkt super fijn, gebruik het zelf ook...)

En daarna migreren is simpel. Zet de bugtracker dicht. los alle bugs op, release een nieuwe versie, en open de nieuwe bugtracker.

Allemaal "Means to get there" ipv de "I am the one and only" mentaliteit.

Even niets...

vrijdag 3 januari 2014 09:23

Acties:

0 Henk 'm!

syl765

Wat wil ZFSguru eigenlijk worden?
Wil ZFSguru een NAS/SAN systeem worden voor zakelijk gebruik?
Wil ZFSguru een NAS/SAN systeem worden voor thuis gebruik?
Wil ZFSguru een NAS/SAN systeem worden voor thuis gebruik met allerhande software om te downloaden, tv te kijken enz.

Hier begint het, als je ook de zakelijke markt wil bedienen, dan zul je toch echt moeten zorgen dat de basis goed is. (FreeBSD en ZFS is een goede basis) Maar de gui dient ook bepaalde zaken te bevatten die gewoon werken.

Sowieso vertrouw ik (en jason ook) de security niet van dit soort pakketten. Servers worden vaak gehackt doordat een bepaald softwarepakket vulnerabilities heeft en niet wordt gepatched of er is nog geen patch. Dus als we dit soort pakketten gebruiken - al is het tijdelijk - dan moet dat in een jail. Dan zit je weer met IPs want je kunt geen drie jails dezelfde poort 80 laten gebruiken.

Een reverse proxy ertussen, en je kan aan de achterkant alle kanten op.
Maar hiervoor dien je dan wel apache, nginx, squid of een ander reverse proxy systeem te installeren.
Of vertrouwen jullie deze software ook niet? Dan maak je het jezelf wel heel erg moeilijk en zul je zelf alles moeten gaan schrijven. Dit is niet te doen. Er gaat dus heel veel tijd verloren in zaken waar standaard pakketen voor zijn. ZONDE.... zeker als je roept dat er al niet veel tijd is.
Wie geeft jou de garantie dat je eigen forum software ook geen exploits bevat?
Niemand die het weet, misschien zit er al iemand binnen er is niemand die een code audit uitvoert op die zelf geschreven code, het is alleen de maker die denkt dat het goed zit en daar zit gelijk ook het gevaar.

Het is een tijd geleden dat ik ZFSguru heb geprobeerd, en ik zal van het weekend deze weer eens installeren op een virtuele bak en melden wat ik allemaal tegen kom.

Als ik ooit nog eens een project moet starten, dan is Mailborder https://www.mailborder.com wel het project dat ik als uitgangs punt zou nemen.
een goede website, een goed forum, een goed help systeem (ook vanuit de applicatie links naar video uitleg) enz.
Wat ik echter niet zou doen is het gesloten houden zoals mailborder dat doet.

vrijdag 3 januari 2014 09:32

Acties:

0 Henk 'm!

Bigs

Midas.e schreef op donderdag 02 januari 2014 @ 16:52:
[...]

Klopt, je dient alleen wel code van andere aan te geven. Het mooiste zou zijn als ZFSguru op github zou verschijnen zodat iedereen hier een fork van zou kunnen maken en/of helpen met de ontwikkeling.

Dit. Ik gebruik zelf plain FreeBSD, maar bepaalde delen van ZFSguru zijn voor mij best interessant (zoals de benchmark tool). Als code op Github staat kunnen andere ontwikkelaars er eenvoudig mee aan de slag en aan bijdragen.

vrijdag 3 januari 2014 09:49

Acties:

0 Henk 'm!

EnerQi

Voordat deze discussie uitmond in een "vechtpartij" hoe het beter kan: is er een streefdatum waarin we de nieuwe website/wiki/bugtracker kunnen verwelkomen? Als dit namelijk binnen 3 maanden is, is dit dus gewoon een non-issue. Duurt het nog een jaar (of langer), zou ik toch voor een tijdelijke oplossing gaan (inclusief meerdere usernames en wachtwoorden ivm security). Het migreren van een wiki is alleen copy/past

Wil ZFSguru een NAS/SAN systeem worden voor thuis gebruik met allerhande software om te downloaden, tv te kijken enz.

Dit komt het beste in de buurt: voor iedereen te gebruiken (thuis + zakelijk) met allerlei software die de gebruiker kan kiezen om te installeren (basis is clean).

Dit. Ik gebruik zelf plain FreeBSD, maar bepaalde delen van ZFSguru zijn voor mij best interessant (zoals de benchmark tool). Als code op Github staat kunnen andere ontwikkelaars er eenvoudig mee aan de slag en aan bijdragen.

Waar ik mee zit, zijn die forks. Forks helpen niet zfsguru maar gaan een andere richting op. Het migreren van allerlei forks helpt ook niet in ontwikkelingstijd in het orginele project. Ook je opmerking hierboven is een dooddoener (in mijn ogen). Je wilt wel de benchmark tool maar niet bijdragen

.
Waar zit het voordeel voor Jason/CiPHER om forks te hebben?

vrijdag 3 januari 2014 10:04

Acties:

0 Henk 'm!

SparC-EHV

Anoniem: 15758 schreef op donderdag 02 januari 2014 @ 17:31:
[...]

Maar als gebruikers ook moeten inloggen, moet dat dan met nieuwe accounts of wordt het wachtwoord gedeeld? Bij dat laatste is ook weer de overweging of het wel veilig is.

Daarnaast had ik een tijd terug alle open source bugtrackers eens bekeken qua screenshots en demo's. Er zaten wat kandidaten tussen, maar heel positief was ik niet echt. Een lekker duidelijke no-nonsense interface was er niet echt, velen erg nerdy. Anderen weer met tig opties.

Sowieso vertrouw ik (en jason ook) de security niet van dit soort pakketten. Servers worden vaak gehackt doordat een bepaald softwarepakket vulnerabilities heeft en niet wordt gepatched of er is nog geen patch. Dus als we dit soort pakketten gebruiken - al is het tijdelijk - dan moet dat in een jail. Dan zit je weer met IPs want je kunt geen drie jails dezelfde poort 80 laten gebruiken.

no offence meant, maar is dat niet denken in problemen ipv oplossingen?
Eerlijk is eerlijk, ik waardeer het enorm welke tijd en effort in ZFSGuru wordt gestoken, maar wordt er soms niet teveel ergens een excuus voor verzonnen om zodoende toch de eigen wil door te drukken het anders te doen? En dat mag, begrijp me niet verkeerd, het is jullie product, maar al eerder gezegd, deel de liefde en de motivatie om dingen anders te doen met je community. Zorg voor draagvlak

Given a task to do one that seems impossible, given the desire to do it...humans can accomplish almost anything. - Capt. Jim Lovell

vrijdag 3 januari 2014 12:05

Acties:

0 Henk 'm!

Anoniem: 15758

Topicstarter

FireDrunk schreef op vrijdag 03 januari 2014 @ 08:56:
Wat denk ik belangrijk is, is dat je je beseft dat je niet alles alleen moet willen doen

Die behoefte is er bij ons beide wel aanwezig. Zit een beetje in het karakter. Maar dat is wel een probleem hoor, dus goed dat jullie wat bijsturen op dat punt.

In elk geval het draaien van third-party dingen totdat wellicht in-house het kan overnemen, sta ik wel positief tegenover. Het is natuurlijk onzin om zaken als wiki te herschrijven. Al zou een bugtracker wellicht wel kunnen. Toch niet zoveel werk en dan kun je het wel heel mooi in de nieuwe website integreren. En in je eigen ZFSguru GUI zien welke bugs van je nog openstaan en dat soort gein.

Maar jullie zeggen eigenlijk: het gaat niet alleen om morgen maar ook om vandaag. Prima!

EnerQi schreef op vrijdag 03 januari 2014 @ 09:49:
is er een streefdatum waarin we de nieuwe website/wiki/bugtracker kunnen verwelkomen? Als dit namelijk binnen 3 maanden is, is dit dus gewoon een non-issue. Duurt het nog een jaar (of langer), zou ik toch voor een tijdelijke oplossing gaan (inclusief meerdere usernames en wachtwoorden ivm security). Het migreren van een wiki is alleen copy/past .

Een jaar zeker niet. Maar ik gok inderdaad wel 2 maanden. Misschien draait de nieuwe dedicated server vanaf maart, dan kunnen we alles draaien wat we willen in afgeschermde jails. Dan is de security ook goed geregeld.

Maar er is een alternatief: nu al hosten ipv over een paar maanden. Normaliter krijg je dan probleem met jails die zijn eigen IP wilt hebben voor poort 80, maar ik kan de wiki en bugtracker ook hosten op een andere poort. Voordeel is dat ik het dan nu al kan hosten ipv een paar maanden hoef te wachten.

Kortom, even het overzichtje van bruikbare tips:

Eigen Wiki op korte termijn (of wachten op server, of nu al doen op een andere poort)
Eigen bugtracker op korte termijn (of wachten op server, of nu al doen op een andere poort)
Iemand die de communicatie verzorgt richting de gebruikers (community officer)

Dat laatste is nog iets ingewikkelder, maar de eerste twee kan prima. En wellicht hebben jullie gelijk dat het ook sneller zou kunnen, al is die 2 maanden ook gauw om hoor.

Waar zit het voordeel voor Jason/CiPHER om forks te hebben?

Nergens, ik denk dat daar niets positief uit voort komt. Alleen maar het gevoel dat het project uit elkaar valt, of dat anderen met de code vandoor gaan bijvoorbeeld voor commerciële doeleinden.

SparC-EHV schreef op vrijdag 03 januari 2014 @ 10:04:
Eerlijk is eerlijk, ik waardeer het enorm welke tijd en effort in ZFSGuru wordt gestoken, maar wordt er soms niet teveel ergens een excuus voor verzonnen om zodoende toch de eigen wil door te drukken het anders te doen? En dat mag, begrijp me niet verkeerd, het is jullie product, maar al eerder gezegd, deel de liefde en de motivatie om dingen anders te doen met je community. Zorg voor draagvlak

ZFSguru is het resultaat van die eigen wil. ZFSguru is het product van dat anders denken en anders doen. Dus als je ZFSguru kunt waarderen, moet je ook die eigenzinnige mening/karakter van ons beide kunnen waarderen, in elk geval gedeeltelijk. Er zullen vast positieve dingen en negatieve dingen uit voortkomen. Positief dat het product bij vlagen heel goed ontworpen is en goed aansluit bij de doelgroep daar waar andere projecten het op dit punt laten afweten. Negatief dat er soms andere prioriteiten worden gesteld of door de do-it-yourself-mentaliteit er ook werk dubbel wordt gedaan. Zou zo maar beide kunnen kloppen.

vrijdag 3 januari 2014 12:12

Acties:

0 Henk 'm!

Anoniem: 15758

Topicstarter

syl765 schreef op vrijdag 03 januari 2014 @ 09:23:
Wat wil ZFSguru eigenlijk worden?
Wil ZFSguru een NAS/SAN systeem worden voor zakelijk gebruik?
Wil ZFSguru een NAS/SAN systeem worden voor thuis gebruik?
Wil ZFSguru een NAS/SAN systeem worden voor thuis gebruik met allerhande software om te downloaden, tv te kijken enz.

Jason heeft in The State of the Project aangegeven wat ZFSguru niet is en wat het wel is. ZFSguru is géén NAS OS wat enkel NAS functionaliteit biedt. Dat is wel wat sommigen wilden; die vinden alle aandacht voor services en andere dingen overbodig en hebben liever dat ZFSguru enkel en alleen op ZFS richt en verder niets.

Dat is uitdrukkelijk niet de wens van Jason. Die had wat anders voor ogen met ZFSguru. Jason ziet het NAS OS meer als opstapje voor wat groters. Belangrijke goede basis, dat wel, maar niet als einddoel. Dan kom je meer op een multi-purpose server operating system. Oftewel een modulair server OS, dát is wat ZFSguru is!

Modulair duidt natuurlijk op het feit dat je kaal begint en extra functionaliteit zelf toevoegt naar wens. Dus geen bloated OS met allerlei dingen die draaien waar je geen weet van hebt; dat is vies en gaat gauw stuk. De services zijn onmisbaar om ZFSguru de extra glans te bieden. Voor nu betekent dat een NAS OS met leuke addon apps. In de toekomst zouden die apps wel eens belangrijker kunnen worden dan het NAS-gedeelte. Denk aan ZFSguru als firewall/DHCP/DNS/PXE server, denk aan een internet server (web, database, mail), denk aan een gameserver, denk aan een HTPC met XBMC fullscreen. Maar ook denk aan virtualisatie, waarbij ZFSguru bij voorkeur host OS is en je guest OS onder je krijgt. Straks met Xen en BHyVe gaat dat pas leuk van de grond komen, want dat VirtualBox is leuk voor nu maar straks hebben we wat leukers!

Hier begint het, als je ook de zakelijke markt wil bedienen

ZFSguru is al geschikt voor licht zakelijk gebruik. Zo is er een film mee gemonteerd dus je kunt het voor werk gebruiken. Daar is het stabiel genoeg voor, dat bestanden delen via het netwerk is wel iets wat gewoon werkt.

Maar als ik Jason goed begrijp is het vooral voor thuisgebruikers die zelf dingen willen draaien. Bijvoorbeeld eigen mailserver is best een goed voorbeeld. Je kunt zelf in de weer gaan met allerlei software, maar het is vaak toch best lastig om een werkende mailserver op te zetten die blijft werken en ook goede anti-spamvoorzieningen heeft. Dit zijn nou de dingen waar ZFSguru zijn waarde kan laten zien, door de gebruiker met twee muisklikken een werkende mailserver te geven. En met mooie interface zodat iedereen zijn eigen mailserver kan draaien; dat kost een paar muisklikken en invullen van emailadres en wachtwoord, that's it. Als het zo simpel wordt, dan betekent dat het zelf draaien van dit soort services toegankelijk wordt voor een veel groter publiek. Iedereen kan zijn eigen server draaien en allerlei services actief hebben; daar hoef je niet langer maandenlang tutorials in te duiken en een hoop bij te leren.

Dus de ambitie voor een NAS OS vind ik te laag. ZFSguru wilt meer kunnen bereiken. Een goed desktop OS zal het voorlopig niet worden, maar een laagdrempelig server OS, dat is er nog niet echt. Daar kan ZFSguru zeker toevoegde waarde bieden.

vrijdag 3 januari 2014 12:44

Acties:

0 Henk 'm!

Bigs

EnerQi schreef op vrijdag 03 januari 2014 @ 09:49:

[...]

Waar ik mee zit, zijn die forks. Forks helpen niet zfsguru maar gaan een andere richting op. Het migreren van allerlei forks helpt ook niet in ontwikkelingstijd in het orginele project. Ook je opmerking hierboven is een dooddoener (in mijn ogen). Je wilt wel de benchmark tool maar niet bijdragen .
Waar zit het voordeel voor Jason/CiPHER om forks te hebben?

Er zijn een miljoen projecten op Github die het tegendeel bewijzen. Door het forken eenvoudig te maken kan iemand eenvoudig aanpassingen maken en die door middel van een pull request aanbieden aan de maintainers van het project. Dit is veel toegankelijker dan het traditionele 'stuur maar een patch naar de mailinglist, oh sorry je patch is op de versie van 3 dagen geleden dus daar kunnen we niets mee'. Ik geef duidelijk aan dat ik zou bijdragen aan die benchmark tool als ik daar mogelijkheden voor zie. Nu kan ik niet eens aan de source komen, laat staan dat er een eenvoudig proces is om iets bij te dragen aan het project. Het is geen dooddoener, het gaat om het succesvol maken van een open source project.

vrijdag 3 januari 2014 12:59

Acties:

0 Henk 'm!

Anoniem: 15758

Topicstarter

Er is nog nooit iets geweigerd qua patches; allemaal worden ze handmatig door ons geintegreerd in de code. Zoveel patches zijn er ook niet.

Als je punt is dat er meer patches zullen/kunnen komen als een publieke repo beschikbaar is, dan denk ik dat je gelijk hebt.

Maar er zijn redenen om te veronderstellen dat het bij ZFSguru tegen zou kunnen vallen. Zo past het project om meerdere redenen niet zo goed in een community opzet. Ten eerste is er de 'stijl' van design van de interface, maar wellicht belangrijker is dat de opzet van de code betekent dat je een beetje de denkwijze moet begrijpen van ZFSguru. FireDrunk bijvoorbeeld had hier veel moeite mee. Niet omdat hij niet goed code kan lezen, ik heb geen twijfels aan zijn vaardigheden op dat vlak. Maar ik vermoed wel dat de manier-van-denken van ZFSguru niet zo goed viel bij hem. En hij geeft aan dat ZFSguru niet helemaal volgens de gangbare methoden werkt.

Voor een project met een dergelijk karakter is het wellicht juist wel goed als een klein team de kern verzorgt. Zeker als daaromheen vanalles gebeurt wat de community zelf doet en het 'kernteam' niet nodig heeft, zoals wij voor ogen houden.

De situatie die jij schetst is er een van een groter project (of groter deel van de code) wat veel patches krijgt of zou kunnen krijgen maar daar nauwelijks gebruik van wordt gemaakt. Dit situatie is niet van toepassing op ZFSguru. Mocht dat in de toekomst wel het geval zijn, kan het oordeel ook anders uitvallen natuurlijk. Dan is ZFSguru in een nieuwe fase beland. Maar het idee is wel dat de 'core' helemaal niet zo groot zou mogen worden.

De services is straks waar het allemaal om draait. Net zoals de appstore voor iPhone onmisbaar is, anders heb je wel basisfunctionaliteit, maar mensen willen toch meer en heel specifieke zaken kunnen draaien. Dat kunnen we natuurlijk niet allemaal alleen doen en daarom willen we de infrastructuur bouwen zodat gebruikers zoals jullie via de interface zelf allerlei dingen kunnen doen. Op die manier ontstaat vanzelf een community en wellicht dan zou je kunnen spreken over een community-project, waarbij de basis nog steeds door een kernteam wordt verzorgd, maar door de modulaire opzet het gemakkelijk is om te werken aan eigen dingen. Zo kan ik mij voorstellen dat sommigen services bouwen voor eigen gebruik die ze elke keer opnieuw op een nieuwe ZFSguru-installatie kunnen installeren. Dan hoef je niet meer te onthouden hoe je ooit alles goed werkend hebt gekregen.

Maar we praten nu zeker anderhalf tot twee jaar verder voordat we op dit punt zijn beland. Het gaat nu eenmaal niet zo snel als je zou willen. Het op github zetten op dit moment zou daar ook niet veel aan veranderen.

vrijdag 3 januari 2014 13:04

Acties:

0 Henk 'm!

base_

Github maakt onwikkeling veel toegankelijker.
Voor mijzelf is een compleet OS met diverse services onbruikbaar, maar de webinterface bijvoorbeeld wel interessant. Het lijkt mij dan ook verstandig om dit dus apart/modulair te houden, zodat e.e.a. universeler te gebruiken is en er meer gebruikers (en developers) daadwerkelijk gebruik kunnen maken van datgene dat ze interessant vinden. Van die webinterface kan overigens ook nog een port gemaakt worden (trekt ook weer nieuwe gebruikers).

vrijdag 3 januari 2014 13:05

Acties:

0 Henk 'm!

FireDrunk

Zfs
ZFSguru
Opslag

Dat kan dus niet zomaar. De webinterface rust op het gebruik van sudo (de www gebruiker heeft volledige sudo rechten). En dat is iets wat je niet zomaar op elk systeem wil als je die port installeert.

Stel je hebt al een apache draaien (op een andere poort ofzo) en je zou ZFSguru willen gebruiken. Moet de www user sudo rechten krijgen.

Dit betekend dat alle websites sudo rechten krijgen... Niet echt gewenst gedrag...

Even niets...

vrijdag 3 januari 2014 13:09

Acties:

0 Henk 'm!

Anoniem: 15758

Topicstarter

Nee maar Jason is al met php-FPM aan het experimenteren. Dan draait er één proces direct onder root. Jason wilde echter niet zomaar commando's als root uitvoeren, alleen als dat nodig is. Maar ik geloof via een script kan hij zaken als andere users uitvoeren. Dan kan ZFSguru aangepast worden en overgaan op php-FPM. Dan kan lighttpd en fast-cgi en dus ook sudo de deur uit.

Dan is het ook hele gemakkelijk om eventjes ZFSguru op poort 81 te zetten, als je een 'echte' webserver op een andere poort wilt. Misschien zou ZFSguru zelfs standaard wel op een andere poort moeten draaien, wat denken jullie?

vrijdag 3 januari 2014 13:11

Acties:

0 Henk 'm!

FireDrunk

Zfs
ZFSguru
Opslag

php-FPM werkt volgens mij niet anders hoor.

[root@NAS ~]# ps -aux | grep php
root  84867   0.0  0.0  33100  1884  -  Ss    2:41PM     0:01.06 php-fpm: master process (/usr/local/etc/php-fpm.conf) (php-fpm)
www   84868   0.0  0.0  33100     0  -  IW   -           0:00.00 php-fpm: pool www (php-fpm)
www   84869   0.0  0.0  33100     0  -  IW   -           0:00.00 php-fpm: pool www (php-fpm)
root  47666   0.0  0.0    380   216  1  DL+   1:10PM     0:00.00 grep php

Draait gewoon onder www.

Ik heb heel lang over die security nagedacht, en de enige echt veilige oplossing is een losse daemon denk ik.
Die je dan via SOAP aanspreekt ofzo.

Even niets...

vrijdag 3 januari 2014 13:18

Acties:

0 Henk 'm!

base_

Ik denk dat het inderdaad het beste via een losse daemon/service o.i.d. kan, daarnaast het lijkt mij ook wel nuttig om die sudo opdrachten te scheiden van de PHP code. FPM/FastCGI/apache module maakt i.d.d. niet veel uit, behalve dat je eventueel een aparte pool met root rechten kan draaien voor alleen ZFSGuru.

vrijdag 3 januari 2014 13:23

Acties:

0 Henk 'm!

Anoniem: 15758

Topicstarter

code:

1 2	-R, --allow-to-run-as-root Allow pool to run as root (disabled by default)

Maar die moet je er met een patch inkrijgen dacht ik. Het is allemaal wat prutsen, maar het kan op die manier wel gaan werken. Een soort stored procedure-approach waar wij laatst via DM over hadden is nog beter, maar ook veel werk. Simpelweg de executes via een functie laten lopen die ze uitvoert als 'zfsguru' user account ipv 'www' of 'root' is vrij snel te implementeren. Kortom, deze approach lijkt mij wel goed, als het gaat werken.

vrijdag 3 januari 2014 13:27

Acties:

0 Henk 'm!

FireDrunk

Zfs
ZFSguru
Opslag

Wat is nou het verschil? Want als er een security flaw in de webinterface zit, kan je nog steeds super makkelijk root rechten verkrijgen...

sudo gpasswd -a www wheel

En gaan met die banaan...

Even niets...

vrijdag 3 januari 2014 13:27

Acties:

0 Henk 'm!

base_

Kan je die commands niet via (php) SSH2 uitvoeren trouwens?

vrijdag 3 januari 2014 14:03

Acties:

0 Henk 'm!

Anoniem: 15758

Topicstarter

@base_: lijkt mij niet zo snel als je voor elk super commando moet inloggen, dat zal zeker een vertraging geven. Het moet beter kunnen, anders kunnen we het beter voorlopig zo laten.

@FireDrunk: doordat het centrale script de security doet kun je niet verderop komen zonder de security code te hebben doorlopen. Die code zit 'vroeg' in het codepad waardoor de kans op bugs ook minder groot is. Daarnaast is het bij mesa zo dat alle URLs naar één .php script gaan. Dan kun je ook niet meer willekeurige .php scripts aanroepen. Maar opzich zou dat ook niet erg mogen zijn; je krijgt dan een lege pagina want het script bevat enkel php functies geen actieve code.

en het uitvoeren van code als www kan wel met 'su' of wat jij noemt, maar dan zit je met het probleem dat je problemen krijgt met het pipe character. sudo echo "" | whoami geeft gewoon 'www' aan ipv 'root'. Dus moet je het commando in een scriptje zetten en dat uit laten voeren. Het is omslachtig, helaas. Jammer dat dit soort dingen niet beter geregeld zijn.

Wat we eigenlijk willen is een ultra-ultra-ultra-lichte webserver die kan luisteren op een opgegeven poort en ALLE requests naar één .php script stuurt. Webserver doet HTTP requests en weinig meer. Want lighttpd is zo light nog niet. Het moet echt ultra-light zijn, want 6 kilobyte ofzo. Dat zou gaaf zijn!

vrijdag 3 januari 2014 14:11

Acties:

0 Henk 'm!

FireDrunk

Zfs
ZFSguru
Opslag

Dat kan wel met Python volgens mij hoor... Er zijn een aantal python webserver initatieven.
Voordeel is dat je monitoring en mailing ook vanuit die Python daemon kan doen.

Even niets...

vrijdag 3 januari 2014 14:18

Acties:

0 Henk 'm!

base_

Python is nou niet bepaald "light", hier staat een voorbeeld van een binary wrapper: http://stackoverflow.com/...ute-root-commands-via-php, vars en commando's zal je moeten scheiden en valideren, onafhankelijk van welke taal of omgeving je gebruikt.

vrijdag 3 januari 2014 14:37

Acties:

0 Henk 'm!

FireDrunk

Zfs
ZFSguru
Opslag

Python is zo light als je het zelf maakt. Grote voordeel is dat het al een belangrijk onderdeel is van FreeBSD. Het is dus reeds een grote dependancy van het OS zelf, en niet iets wat de gebruiker moet installeren.

Maak van de Python Daemon inc de Web interface een PBI en je hebt een pracht programma...

Maar goed, dat is mijn mening

Even niets...

vrijdag 3 januari 2014 15:02

Acties:

0 Henk 'm!

Au Contraire Mon Capitan!

Zfs
ZFSguru
Opslag

Ik snap niet zo goed waarom je je druk zou maken over het runnen van lighttpd. Dat is light zat voor wat je er mee wil, lijkt me. Of moet ZFSguru ook op arduino draaien?

vrijdag 3 januari 2014 15:02

Acties:

0 Henk 'm!

base_

Python onderdeel van FreeBSD? Ik heb hem tot nu toe nog altijd apart moeten installeren en Python is groot (en draait zowiezo op een interpreter).
Voor lighweight zou ik misschien zoeken in de richting van LUA (182k + 244K) en Mongoose (40k)?

vrijdag 3 januari 2014 15:29

Acties:

0 Henk 'm!

FireDrunk

Zfs
ZFSguru
Opslag

Hmm, ben ik dan misschien in de war met Perl...

Of met Gentoo... Nu twijfel ik een beetje

In theorie kan je natuurlijk ook C++ gebruiken...

[ Voor 21% gewijzigd door FireDrunk op 03-01-2014 15:30 ]

Even niets...

vrijdag 3 januari 2014 15:41

Acties:

0 Henk 'm!

Anoniem: 15758

Topicstarter

Ik dacht eraan om iemand te vragen die makkelijk C / C++ code kan schrijven om een miniwebserver te bouwen. Alleen daemonize en HTTP listen socket implementeren en alle inkomende requests aan een (php) script geven. De interface met PHP is denk ik het enige struikelblok; ik weet niet precies hoe CGI werkt maar volgens mij is het een methode om een binary/script aan te roepen met bepaalde variabelen ingesteld en de output van ervan te gebruiken als (HTML) output.

Zoiets zou toch moeten kunnen met 100-200 regels code? Misschien zelfs minder.

vrijdag 3 januari 2014 15:50

Acties:

0 Henk 'm!

Bigs

Een eigen webserver ontwikkelen lijkt me een beetje zonde van je tijd, je gaat dan een hele hoop wielen opnieuw uitvinden (Apache begon ook als 100-200 regels

). Het is makkelijker om een eenvoudige achtergrond worker als root te laten draaien die via een queue opdrachten aanneemt van het frontend. Er zijn verschillende kant-en-klare oplossingen die je daar zo voor kunt gebruiken (in Ruby gebruiken wij Sidekiq of Resque, me dunkt dat daar PHP alternatieven voor zijn die ook zonder Redis werken).

[ Voor 4% gewijzigd door Bigs op 03-01-2014 15:57 ]

vrijdag 3 januari 2014 16:10

Acties:

0 Henk 'm!

Au Contraire Mon Capitan!

Zfs
ZFSguru
Opslag

@Cipher, zo'n miniwebserver bestaat al, die heet 'ncat'.

)

Het spijt me heel erg maar ik haak af (voor zover ik dat al niet was), dit gaat echt nergens meer over wat mij betreft, met alle waardering voor alle goede bedoeingen.

Waarom andere mensen wielen opnieuw laten uitvinden om problemen op te lossen die er niet zijn? Waar ligt de focus? Waarom niet gewoon op de schouders van giants gaan staan en daar op voort borduren? Dat is al moeilijk genoeg. Zo krijg je ZFSguru nooit 'af'.

[ Voor 14% gewijzigd door Q op 03-01-2014 16:12 ]

vrijdag 3 januari 2014 16:12

Acties:

0 Henk 'm!

Anoniem: 15758

Topicstarter

Wat stel je dan heel concreet voor?

vrijdag 3 januari 2014 16:18

Acties:

0 Henk 'm!

ItsValium

Anoniem: 15758 schreef op donderdag 02 januari 2014 @ 20:59:
Omdat ik het ook ergens moet kunnen hosten. En aparte user-registratie is ook weer wat. En mails vanaf mijn eigen hosts komen niet altijd aan, door de strenge spamregels van Google enzovoorts. Er zijn allemaal belemmeringen om dit 'eventjes snel' te doen.
...

Als dat het grootste struikelpunt is, kan ik hier even in meehelpen, ik zit namelijk met mijn bedrijf in de hostingbranche en ben gerust bereid om naargelang de noden hier als donatie/sponsoring/whatever iets aan te bieden ...

vrijdag 3 januari 2014 16:19

Acties:

0 Henk 'm!

Au Contraire Mon Capitan!

Zfs
ZFSguru
Opslag

Anoniem: 15758 schreef op vrijdag 03 januari 2014 @ 16:12:
Wat stel je dan heel concreet voor?

De context was de applicatie server (netcat vs. lighttpd) dus ik neem aan dat je het daar over hebt: maak juist gebruik van frameworks die er zijn en probeer niet overal het wiel opnieuw uit te vinden. Ik weet niet hoe dit botst met wat er nu is.

vrijdag 3 januari 2014 16:27

Acties:

0 Henk 'm!

wallyberk

Anoniem: 15758 schreef op vrijdag 03 januari 2014 @ 16:12:
Wat stel je dan heel concreet voor?

Nou je geeft zelf al het antwoord:

Anoniem: 15758 schreef op donderdag 02 januari 2014 @ 17:07:
Misschien is er wel te weinig respect voor de grote plannen en mooie ideeën. Misschien moeten jullie gebruikers gewoon geduldig zijn en tevreden met wat je nu al hebt. Als je over wederzijds respect spreekt, betekent dat ook respect voor de inspanningen die iemand zonder tegenprestatie levert. Dat het dan niet volgens jouw opgegeven specificaties wordt uitgevoerd kun je ons niet kwalijk nemen. Misschien zeg je over één à twee jaar wel dat we misschien toch een punt hadden en dat er wel degelijk veel bereikt is met alle inspanningen die nu worden bekritiseerd. Alles is mogelijk!

Anoniem: 15758 schreef op donderdag 02 januari 2014 @ 22:09:
Wel een grappige analogie! Maar is het bij Ubuntu anders, om maar wat te noemen? Of Mac OSX? Het onderliggende OS is ook gewoon open source code, maar daar komt niet iedereen aan. Linux torvalds is als een dictator de baas wat er in Linux komt en wat niet. Dat is ook goed voor een project van die klasse, een strenge portier die de knoop doorhakt wat erin komt en wat niet.

De communitie heeft gehoefte aan mensen met grote plannen en mooie ideeën. Mensen die zich bezig houden met details worden niet niet serieus genomen. Dus als je denkt dat goed is om een eigen webserver te creeeren, think again. Tevens is Linus voornamelijk een motivator, een man met grote plannen. Mensen volgen hem omdat hij een visie heeft.

Maar voor ZFSguru project geldt meer: vraag niet om de communitie hulp als je niet accepteert waarmee de communitie je kan/wilt helpen. In andere woorden: als de communitie je wilt helpen bij het coderen/programmeren in een gebruikersinterface en niet bij het creeeren van een nieuwe webserver, dan zou ik ze niet vragen om een nieuwe webserver te bouwen.

vrijdag 3 januari 2014 16:31

Acties:

0 Henk 'm!

Anoniem: 15758

Topicstarter

Welke hulp wordt precies niet geaccepteerd dan? Ik snap ook niet helemaal de relatie tot mijn vraag richting Q.

vrijdag 3 januari 2014 16:34

Acties:

0 Henk 'm!

roy.jacobs

Een korte bloemlezing:

Er is nogal wat sprake van NIH.

Ik dacht eraan om iemand te vragen die makkelijk C / C++ code kan schrijven om een miniwebserver te bouwen.

Een eigen webserver ontwikkelen lijkt me een beetje zonde van je tijd, je gaat dan een hele hoop wielen opnieuw uitvinden

Ik snap niet zo goed waarom je je druk zou maken over het runnen van lighttpd. Dat is light zat voor wat je er mee wil, lijkt me.

Leidt tot:

Wat stel je dan heel concreet voor?

vrijdag 3 januari 2014 16:41

Acties:

0 Henk 'm!

Anoniem: 15758

Topicstarter

Ik snap de logica niet zo. Er is nu een onvolmaakte situatie. Je quote over lighttpd klopt niet helemaal; het leid tot meer packages (Bloat) maar belangrijker nog dat via sudo alle www users root rechten krijgen. Dat is een ongewenst security-issue.

Dat kan op meerdere manieren worden verholpen. Iedere oplossing kent voordelen en nadelen, en varieert qua benodigde energie/tijd/kennis die nodig is om het te realiseren. Als jullie willen meedenken welke oplossing de beste is, is dat heel mooi. Maar het lijkt nu alsof ik alles dwars zou bomen en dan denk ik dat jullie mij verkeerd begrijpen.

Als een zelfgemaakte server die een kennis van mij in een middagje zou kunnen schrijven de beste oplossing is en haalbaar, dan ga ik nu geen energie steken in van lighttpd naar iets anders te migreren. Dat zou zonde van de inspanning zijn. Dan beter bij Lighttpd blijven want Q heeft natuurlijk wel gelijk dat het in principe prima werkt zo. Afgezien van security.

vrijdag 3 januari 2014 16:45

Acties:

0 Henk 'm!

wallyberk

Anoniem: 15758 schreef op vrijdag 03 januari 2014 @ 16:31:
Welke hulp wordt precies niet geaccepteerd dan?

Zie:

Anoniem: 15758 schreef op donderdag 02 januari 2014 @ 22:09:
Je bedoelt dat het geen community-project is. Nee dat klopt, maar nergens wordt ook elders beweerd. Open source is het per definitie, omdat de (.php) broncode gewoon plaintext beschikbaar is, evenals de scripts.

Als je de community vraagt om mee te helpen, besef dan dat je er een community-project van maakt.

vrijdag 3 januari 2014 16:46

Acties:

0 Henk 'm!

roy.jacobs

Okee, anders verwoord: Het wekt niet zoveel vertrouwen als je aan de ene kant claimt dat je een ontzettend revolutionair systeem aan het bouwen bent (zonder bugtracker of open source repo) en aan de andere kant continu je eigen ramen ingooit met opmerkingen als "Ik vraag iemand om in een paar honderd regels code een webserver in elkaar te gooien", "Object oriented programming hebben we niet nodig", "Ik weet niet hoe CGI werkt", enzovoorts.

Ik denk dat je hart op de juiste plek zit, maar het lukt de mensen hier niet om tot je te laten doordringen dat dat misschien niet de handigste manier is om te communiceren.

vrijdag 3 januari 2014 16:47

Acties:

0 Henk 'm!

HMS

Heb er even snel doorheen gelezen, en om even op de hosting in te haken. Waarom gooi je het niet op GitHub? Waarom wil je alles zelf hosten? Met GitHub Pages heb je ook zo een leuke site in elkaar.

Over de rest heb ik weinig te zeggen, daar ik een ZoL gebruiken ben (naar volle tevredenheid

)

vrijdag 3 januari 2014 16:48

Acties:

0 Henk 'm!

Anoniem: 15758

Topicstarter

Ik moet nu weg, ik reageer zo later wel.

vrijdag 3 januari 2014 16:51

Acties:

0 Henk 'm!

wallyberk

HMS, waarom zouden ze? Het is geen community-project. Wat wil je bereiken met die GitHub? Het integeren van nieuwe code kan als ze toch met de 2 developer gaan doen, toch op de huidige manier.

vrijdag 3 januari 2014 16:51

Acties:

0 Henk 'm!

HMS

Issue tracker, Wiki, web pages. Ook al gebruik je de source control (nog) niet.

edit: Eventueel een private bitbucket ding, geen idee. Ik weet niet of ze de issue tracker voor zichzelf hebben, of zodat mensen issues kunnen melden.

[ Voor 49% gewijzigd door HMS op 03-01-2014 16:52 ]

vrijdag 3 januari 2014 16:53

Acties:

0 Henk 'm!

FireDrunk

Zfs
ZFSguru
Opslag

Ze willen echt *alles* zelf bouwen, en zelf het wiel uitvinden.
Ik denk dat (voor mij) de discussie daar wel een beetje mee gesloten is.

Als je niet van de fouten van anderen wil leren (zoals en duzenden andere projecten gefaald zijn omdat ze alles zelf wilden bouwen), kunnen wij nog zo hard roepen dat ze bewezen technieken moeten gebruiken.

Als ze dat niet willen, willen ze dat niet. Simpel...

Even niets...

vrijdag 3 januari 2014 17:26

Acties:

0 Henk 'm!

Wim-Bart

Zie signature voor een baan.

Ik ben ZFSGuru nu al een tijdje aan het volgen, omdat ik iets anders wilde dan FreeBSD, FreeNAS of equivalent. Ondanks dat ik voornamelijk in de Windows hoek zit vindt ik ZFS een leuke oplossing voor iSCSI/NFS/FC provisioning van storage. Nu las ik in deze thread dat CiPHER schreef:

Dat is uitdrukkelijk niet de wens van Jason. Die had wat anders voor ogen met ZFSguru. Jason ziet het NAS OS meer als opstapje voor wat groters. Belangrijke goede basis, dat wel, maar niet als einddoel. Dan kom je meer op een multi-purpose server operating system. Oftewel een modulair server OS, dát is wat ZFSguru is!

waardoor mijn interesse voor ZFSguru in 1 keer is gereduceerd naar 0. Met name die uitspraak zegt eigenlijk. We willen een splitsing van FreeBSD maken met allerlei leuke dingen. Met de upcomming FreeBSD 10.0-STABLE en de 11.0 ontwikkelingen van FreeBSD is ZFSGuru dus eigenlijk een overbodig product geworden in de markt. Want als je al FreeBSD of een fork van FreeBSD hebt, waarom zou je dan een product als ZFS Guru maintainen.

Zelf had ik gehoopt dat ZFS Guru een mini ZFS in een box zou worden met een handige Web interface/tooling set voor ZFS, Netwerk configuratie, iSCSI, Fibre channel, NFS en CIFS. Een soort NetApp maar dan met ZFS als basis.

Beheerders, Consultants, Servicedesk medewerkers. We zoeken het allemaal. Stuur mij een PM voor meer info of kijk hier De mooiste ICT'er van Nederland.

vrijdag 3 januari 2014 18:16

Acties:

0 Henk 'm!

EnerQi

Met name die uitspraak zegt eigenlijk. We willen een splitsing van FreeBSD maken met allerlei leuke dingen. Met de upcomming FreeBSD 10.0-STABLE en de 11.0 ontwikkelingen van FreeBSD is ZFSGuru dus eigenlijk een overbodig product geworden in de markt. Want als je al FreeBSD of een fork van FreeBSD hebt, waarom zou je dan een product als ZFS Guru maintainen.

Vooral voor de handige webinterface. Het wordt makkelijker om iets te beheren voor non-freebsd mensen

vrijdag 3 januari 2014 18:25

Acties:

0 Henk 'm!

Anoniem: 15758

Topicstarter

wallyberk schreef op vrijdag 03 januari 2014 @ 16:45:
Zie: (..)
Als je de community vraagt om mee te helpen, besef dan dat je er een community-project van maakt.

We praten heerlijk langs elkaar heen. En je hebt gelijk, dat is mijn fout. Ik moet beter communiceren.

Wat ik bedoel met community project is dat alle devs gelijkwaardig zijn en beslissingen op basis van consensus wordt genomen. FreeBSD is aardig dat idee, waar er een kernteam is wat van samenstelling is. Een soort naamloze vennootschap (NV) dus, in tegenstelling tot een BV wat een duidelijke eigenaar kent.

Als het punt is dat de community dicteert welke richting ZFSguru op gaat, dan is het geen community-project. Als het punt is dat het project openstaat voor toevoegingen uit de community, dan is dat zeker wel van toepassing.

roy.jacobs schreef op vrijdag 03 januari 2014 @ 16:46:
Okee, anders verwoord: Het wekt niet zoveel vertrouwen als je aan de ene kant claimt dat je een ontzettend revolutionair systeem aan het bouwen bent (zonder bugtracker of open source repo) en aan de andere kant continu je eigen ramen ingooit met opmerkingen als "Ik vraag iemand om in een paar honderd regels code een webserver in elkaar te gooien", "Object oriented programming hebben we niet nodig", "Ik weet niet hoe CGI werkt", enzovoorts.

Ik denk dat je hart op de juiste plek zit, maar het lukt de mensen hier niet om tot je te laten doordringen dat dat misschien niet de handigste manier is om te communiceren.

Ik denk dat jullie me verkeerd begrijpen, waarschijnlijk omdat ik het zelf niet goeg genoeg uitleg.

Het punt is tijd, alles kost tijd. Een bugtracker in elkaar flanzen ook; ik heb wat argumenten gegeven. Dat betekent niet dat het er niet komt, ook niet dat alles een in-house oplossing moet zijn. Tijdelijk wat anders is prima, misschien wel permanent we zien wel. Maar er kan niet alles tegelijkertijd.

Ik ken toevallig iemand die in het verleden aangeboden heeft om wat dingen te coden, dus daar dacht ik dan aan, misschien een leuk relatief eenvoudig project voor hem. Of eventueel voor een ander die zich geroepen voelt. Komt het er niet, jammer dan blijven we bij Lighttpd, geen tijd verloren. Komt het er wel, dan zijn Jason en ik ook geen tijd kwijt, omdat een ander deze toevoeging doet.

Er is geen goed alternatief beschikbaar voor het bouwen van een simpele webserver. Alle andere oplossingen kennen nadelen die de 'perfecte' oplossing niet heeft. Dus dat we uiteindelijk naar de beste oplossing willen is niet heel vreemd. Hoe we in de tussentijd de zaken regelen, daar kun je wel over twisten.

En die opties liggen allemaal op tafel. Daarom dat ik vraag, wat stellen jullie concreet voor?

Het zo houden (lighttpd+sudo+security issue)
Overstappen op php+FPM met workers als root (dan draait alles als root, ook niet de bedoeling)
Stored Procedure-approach met commando's die aan ene zijde vast staan en alleen van variabelen worden voorzien, en de unprivileged clientside die de vars opstuurt. Net als SQL stored procedures dus.
Apache/Nginx/whatever ipv Lighttpd (en sudo dan?)
Python webserver (klinkt gaaf, maar...)
Anders...

Als jullie willen dat ik luister naar 'geluiden uit de community' moeten die ook concreet genoeg zijn en haalbaar om te realiseren. De voorstellen voor een wiki, bugtracker en hosting zijn heel concreet en daar sta ik heel positief tegenover. Jullie hebben mij overigens niet nodig; een wiki kan elk van jullie opzetten. Dan kost het mij helemaal geen moeite. Maar als dat niet gebeurt komt het toch neer dat alles tijd opsnoept van de écht belangrijke dingen die we proberen te bereiken. Voor sommige dingen is dat het waard (wiki/bugtracker) maar andere dingen misschien weer niet (documentatie, etc).

vrijdag 3 januari 2014 18:35

Acties:

0 Henk 'm!

base_

Anders/stored procedure achtig: binary wrapper (met enige validatie voor commando's en vars) voor de sudo functies. Ander voorbeeld: http://goodworkaround.com/node/39. Die wrapper binary kan je dan mooi een eigen user/group en rechten geven, en daarin zitten dan ook alle shell commando's.

vrijdag 3 januari 2014 18:35

Acties:

0 Henk 'm!

Anoniem: 15758

Topicstarter

FireDrunk schreef op vrijdag 03 januari 2014 @ 16:53:
Ze willen echt *alles* zelf bouwen, en zelf het wiel uitvinden.
Ik denk dat (voor mij) de discussie daar wel een beetje mee gesloten is.

Nou dat zou ik jammer vinden. Het klopt dat bestaande oplossingen soms worden gelaten voor wat het is. Maar dat kent ook voordelen. Zo zou ZFSguru anders een nanoBSD-derivative worden als Jason had geluisterd naar anderen. Gelukkig hebben we nu de veel flexibelere systeemarchitectuur en alle nadelen en brokenness die nanoBSD nu kent heeft ZFSguru geen last van.

Maar het wiel opnieuw uitvinden is onzin. Er is geen simpele webserver zoals ik voor ogen heb, die enkel alles naar één php script stuurt. Dat zou de beste oplossing zijn, met de minste nadelen. Alleen is hij er nu nog niet, en misschien duurt het nog heel lang voordat hij er komt. Wat is het probleem?

Je doet net alsof wij ipv de belangrijke dingen allerlei zijwegen in gaan. Dat is toch niet zo? Het is juist andersom dat we aan de belangrijke dingen willen blijven werken, ipv afleiden met documentatie en andere dingen. Dat is nu gewoon even minder prioriteit.

Wim-Bart schreef op vrijdag 03 januari 2014 @ 17:26:
Ik ben ZFSGuru nu al een tijdje aan het volgen, omdat ik iets anders wilde dan FreeBSD, FreeNAS of equivalent. Ondanks dat ik voornamelijk in de Windows hoek zit vindt ik ZFS een leuke oplossing voor iSCSI/NFS/FC provisioning van storage. Nu las ik in deze thread dat CiPHER schreef:

(verhaal over dat ZFSguru niet enkel een NAS OS is maar een multi-purpose Server OS)

waardoor mijn interesse voor ZFSguru in 1 keer is gereduceerd naar 0. Met name die uitspraak zegt eigenlijk. We willen een splitsing van FreeBSD maken met allerlei leuke dingen. Met de upcomming FreeBSD 10.0-STABLE en de 11.0 ontwikkelingen van FreeBSD is ZFSGuru dus eigenlijk een overbodig product geworden in de markt. Want als je al FreeBSD of een fork van FreeBSD hebt, waarom zou je dan een product als ZFS Guru maintainen.

Je begrijpt het verkeerd. ZFSguru is absoluut géén fork van FreeBSD. Daarvoor kunnen Jason en ik niet goed genoeg coden. Nee wat wij maken is een derivative - iets wat leunt op een ander project maar aangepast is. Zo blijft ZFSguru de nieuwste dingen van FreeBSD overnemen, en zit Jason per 4 uur te F5-'en of de 10.0-RELEASE commit al is aangekomen. Dat doe je niet bij een fork....

En wat jij wilt, een mooi kaal ZFS OS, dat is ZFSguru zonder services geïnstalleerd. Dus je hebt wat je wilt, by default. Het punt is dat ZFSguru niet enkel een NAS OS wilt zijn, maar aspiraties heeft om meer te zijn. Dit is een andere koers dan diegenen die vinden dat het project enkele een ZFS-manage web-interface zou moeten zijn. Maar wees eerlijk: dat gedeelte is al bijna af, we moeten verder kijken. We hebben nu al een mooie systeemarchitectuur en servicearchitectuur. Zou raar zijn als we opeens alles deleten en enkel nog op het oppoetsen van de GUI gaan richten. Dan zouden we weinig ambitie hebben om van ZFSguru écht wat te maken.

vrijdag 3 januari 2014 19:17

Acties:

0 Henk 'm!

Wim-Bart

Zie signature voor een baan.

Je begrijpt het verkeerd. ZFSguru is absoluut géén fork van FreeBSD. Daarvoor kunnen Jason en ik niet goed genoeg coden. Nee wat wij maken is een derivative - iets wat leunt op een ander project maar aangepast is. Zo blijft ZFSguru de nieuwste dingen van FreeBSD overnemen, en zit Jason per 4 uur te F5-'en of de 10.0-RELEASE commit al is aangekomen. Dat doe je niet bij een fork....

Maar als je zelf al aan geeft dat jij en Jason niet goed genoeg kunnen coden, dan is het maken van eigen veilige code in plaats van hergebruik standaard frameworks veel gevaarlijker.

Maar is het niet eenvoudiger om in eerste instantie uit te gaan van een FreeBSD-STABLE release, bijvoorbeeld 9.2-STABLE of straks (hopelijk nog deze maand uitkomende 10.0-STABLE) en daar een FSGuru ports voor te maken welke jullie ZFS enhancements bevat, inclusief tooling. Dat is namelijk het mooie van de Ports onder FreeBSD, je kan zonder GitHub of de FreeBSD omgeving zelf ports maken en deze embedden (kijk maar eens naar hoe MS dat doet met de Hyper-V ondersteuning in 9.2 en lager).

Zoals anderen aangeven, is de web interface veel makkelijker voor de gemiddelde gebruiker en is een zekere plusfactor voor ZFSGuru, maar om een nieuwe distributie te maken is heel wat meer voor nodig.

Overigens geloof ik in Lean en Mean. Dat wil zeggen, een minimale OS footprint met daarop alleen de nodige services, wat je overigens onder ieder OS kan doen (ja zelfs Windows kan je helemaal down-tunen).

Zelfs heb ik iets van:

Neem een stable OS release, FreeBSD is een goede optie, de halve wereld gebruikt dit als basis of neem een andere distributie;
Maak een installer welke het OS minimaal installeert met de minimale eisen zoals een kleine standaard http/https deamon, minimale network stack, etcetera.
Zorg voor custom scripts welke je vanaf bijvoorbeeld je eigen Web interface kan aftrappen voor installatie van iSCSI, NFS, Samba, et cetera, lekker modulair, definieer hier een API voor (ZFSWebApi) of iets dergelijks zodat deze simpel in de Web interface kan worden opgenomen. Laat deze gewoon standaard modules/ports installeren met de minimale opties (bijvoorbeeld zonder X11 componenten et cetera).

Op deze wijze neem je heel veel werk uit handen wat je normaal handmatig moet doen. Zelf liep ik bijvoorbeeld aan tegen de complexiteit (in de vorm van handmatige acties) om een simpele iSCSI lun te presenteren aan mijn Hyper-V doos. Dat moet eenvoudiger kunnen.

Gebruik door ontwikkelde componenten, hergebruik wat al jaren door de hele community is gebruikt en getest. Persoonlijk heb ik liever een lek in een standaard component waarvan ik weet dat ik na 1 fetch/update/make deze gefixed heb dan dat ik maar moet hopen op een release van iets wat door 1/2/3 man wordt onderhouden.

[ Voor 37% gewijzigd door Wim-Bart op 03-01-2014 19:29 ]

Beheerders, Consultants, Servicedesk medewerkers. We zoeken het allemaal. Stuur mij een PM voor meer info of kijk hier De mooiste ICT'er van Nederland.

vrijdag 3 januari 2014 19:28

Acties:

0 Henk 'm!

Anoniem: 15758

Topicstarter

Het coden van een kernel is iets heel anders dan PHP-code voor het ZFSguru project. Dat gaat prima. Maar Jason en ik zijn niet van het kaliber om kernel developer te worden, dat zou nodig zijn als we inderdaad FreeBSD zouden forken in nóg een BSD-variant. Ik heb liever dat NetBSD, OpenBSD en FreeBSD weer samen groeien tot één BSD variant. Dat er meerdere derivatives van komen is alleen maar goed. Ubuntu leunt op Debian en zo leunt ZFSguru op FreeBSD.

Maar is het niet eenvoudiger om in eerste instantie uit te gaan van een FreeBSD-STABLE release, bijvoorbeeld 9.2-STABLE of straks (hopelijk nog deze maand uitkomende 10.0-STABLE)

Je bedoelt 10.0-RELEASE; STABLE is wat anders en 10-STABLE bestaat allang. Dat is wat straks 10.1 gaat worden. 10.0 is al gebrached sinds RC1 en heeft nu los van 10-STABLE en 11-CURRENT (HEAD).

en daar een ZFSguru ports voor te maken

Ports zijn niet afhankelijk van het systeem, zoals bij ZFSguru wel is. Het idee van ZFSguru was ook dat je stappen hebt en niet zomaar een release. De officiële releases zijn er zodat er feedback komt over medegebruikers met éxact die versie. Als het aan de systeemversie ligt - een bug in Samba in die versie, ik noem maar wat - dan is dat iets wat bekend wordt voor die systeemversie. Zeker als straks de community infrastructuur er is ga je vragen zien of anderen ook probleem X hebben en uiteindelijk wordt duidelijk dat er een bug in zit, met misschien workarounds. Kom jij om de hoek kijken en je ziet gelijk die workaround, kijk dat scheelt je veel tijd! Dat zal één van de mooie features worden van ZFSguru.

vrijdag 3 januari 2014 19:33

Acties:

0 Henk 'm!

Wim-Bart

Zie signature voor een baan.

Correctie, ik bedoel release inderdaad. Was even in de war. Overigens ben benieuwd naar 10.0-RELEASE want zo stable is 10.0-RC3 niet (RC4 maar even niet aan begonnen).

Beheerders, Consultants, Servicedesk medewerkers. We zoeken het allemaal. Stuur mij een PM voor meer info of kijk hier De mooiste ICT'er van Nederland.

vrijdag 3 januari 2014 19:39

Acties:

0 Henk 'm!

Anoniem: 15758

Topicstarter

Een x.0 release is vaak nog minder stabiel dan een .1, .2 of .3 release. Maar dat is wel mooi aan BSD, je kunt de branches af en kiezen hoe conservatief je bent. Nog 8.4, 9.2, 10.0, 10-STABLE of 11-CURRENT, van conservatief naar bleeding edge.

vrijdag 3 januari 2014 19:46

Acties:

0 Henk 'm!

FireDrunk

Zfs
ZFSguru
Opslag

Anoniem: 15758 schreef op vrijdag 03 januari 2014 @ 18:35:
[...]

Nou dat zou ik jammer vinden. Het klopt dat bestaande oplossingen soms worden gelaten voor wat het is. Maar dat kent ook voordelen. Zo zou ZFSguru anders een nanoBSD-derivative worden als Jason had geluisterd naar anderen. Gelukkig hebben we nu de veel flexibelere systeemarchitectuur en alle nadelen en brokenness die nanoBSD nu kent heeft ZFSguru geen last van.

Wat heeft nanoBSD met de discussie te maken?

Maar het wiel opnieuw uitvinden is onzin. Er is geen simpele webserver zoals ik voor ogen heb, die enkel alles naar één php script stuurt. Dat zou de beste oplossing zijn, met de minste nadelen. Alleen is hij er nu nog niet, en misschien duurt het nog heel lang voordat hij er komt. Wat is het probleem?

Dan heb je denk ik nog niet genoeg gekeken, er zijn echt honderden webservers...
En om maar even de meest gebruikte lichtgewicht te laten zien:

[root@NAS ~]# ls -lah /usr/local/sbin/nginx
-r-xr-xr-x  1 root  wheel   565K Jan  2 14:00 /usr/local/sbin/nginx

Als je 600k te groot vind, wat is er dan in vredesnaam aan de hand hier? We praten over arrays van TiB's groot... en 600k zou te veel zijn?

Je doet net alsof wij ipv de belangrijke dingen allerlei zijwegen in gaan. Dat is toch niet zo?

Ja, wel, dat is wel zo... Eigen service architectuur (waarom geen ports?), eigen packaging architectuur (waarom geen PBI?), eigen template engine (waarom geen ...[insert random template engine) , eigen javascript (waarom geen JQuery?), eigen bugtracker (waarom geen redmine?), eigen benchmark tools (waarom geen [insert 10 verschillende tools].

Doet dat een lichtje branden?

Het is juist andersom dat we aan de belangrijke dingen willen blijven werken, ipv afleiden met documentatie en andere dingen. Dat is nu gewoon even minder prioriteit.

Beter gezegd: Je werkt aan de dingen die jullie belangrijk vinden... Ik vind het vele honderden malen belangrijker dat jullie eens bugs zouden gaan pletten ipv een FreeBSD 10.0 image zouden uitbrengen... Dat is dus een *mening* en niet wat belangrijk *is*....

Even niets...

vrijdag 3 januari 2014 20:09

Acties:

0 Henk 'm!

Anoniem: 15758

Topicstarter

FireDrunk schreef op vrijdag 03 januari 2014 @ 19:46:
Wat heeft nanoBSD met de discussie te maken?

Nouja het ging erom dat ZFSguru geen bestaande oplossingen zou kiezen maar eigen dingen ontwikkelt. Het beste voorbeeld daarvan is nanoBSD. Dat is wat Jason is aangeraden op het FreeBSD forum. Hij heeft er naar gekeken maar vond het allerlei beperkingen hebben en niet geschikt voor wat hij wilde. Dan zeg jij misschien: bouw voort op wat er al is. Maar Jason is op zo'n moment eigenwijs en ontwikkelt iets wat hem de vrijheid geeft voor wat hij voor ogen heeft. Het gevolg is nu de huidige servicearchitectuur die inmiddels ook op 10.0 werkt. Andere projecten zijn nog niet zover. Ook heeft ZFSguru nu een stevige basis als project niet alleen als web-interface maar ook met een eigen build environment om van FreeBSD een ZFSguru smaakje te geven. Dat gaat zich op termijn uitbetalen!

Je klaagde in het verleden dat de systeemreleases elkaar niet snel genoeg volgen. Dat klopt ook wel, door alle wijzigingen in BSD-land de laatste tijd moest er veel worden aangepast aan de build environment en dat kostte tijd. Maar ook op dit gebied van het project maken we goede vorderingen. Zo denken we over een half jaar een volautomatische buildenvironment te hebben zodat een wekelijkse release vrijwel zonder menselijke interactie mogelijk wordt. Ook is dat leuk voor service maintainers, die dan hun eigen submission in de officiële tree zien komen. Dat is de toekomst van ZFSguru, en niet enkel een web-interface.

Dan heb je denk ik nog niet genoeg gekeken, er zijn echt honderden webservers...
En om maar even de meest gebruikte lichtgewicht te laten zien:

Het ging erom dat php als root gedraaid zou kunnen worden, of een andere methode heeft om root access te verkrijgen. Kortom een drop-in alternatief voor wat ZFSguru nu gebruikt, zodat er weinig tijd nodig is om zaken aan te passen. Als iemand iets schrijft wat wij precies nodig hebben, is dat de perfecte oplossing, toch?! En dan denk ik aan 6K inderdaad, maar het punt is natuurlijk niet dat een megabyte RAM-gebruik de issue is.

Maar ook bij nginx geldt: hoe krijgt ZFSguru root-toegang? Nog steeds via sudo? Wat is dan het voordeel boven Lighttpd+fastcgi+sudo wat ZFSguru nu gebruikt? Dat kunnen we het beter zo laten, totdat iemand onze perfecte oplossing schrijft, of een ander haalbaar alternatief zich aandient.

Wat kunnen we anders doen?

Ja, wel, dat is wel zo... Eigen service architectuur (waarom geen ports?)

Services zijn toch gebaseerd op ports? Wij builden ze voor een bepaalde BSD versie en dan is het een appliance geworden waar een stuk software werkt of niet, maar niet een rolling release. Dat is conform de denkwijze, omdat het bepaalde voordelen heeft. Vooral in de toekomst, waar je precies kunt horen van andere mensen dat versie X van Virtualbox geen bug heeft maar versie Y wel. En dan gaat het ook om de wijze van integratie met ZFSguru. Kortom, dit is de gekozen weg. Mooi toch?

, eigen packaging architectuur (waarom geen PBI?)

Gewoon pkgNG, de nieuwe package-infrastructuur van FreeBSD 10. PBI ken ik niet zo, lijkt een soort unified BSD package te zijn. Maar hoe kun je dan controleren of de gecompileerde binaries voldoen aan de ZFSguru systeemversie? Allemaal niet erg praktisch...

, eigen template engine (waarom geen ...[insert random template engine)

Kost toch ook weer tijd? Zoveel tijd kostte het niet die theme engine. En gaaf toch, tenminste iets waar je zelf aan zou kunnen beginnen als je nu zou willen meehelpen: je kunt de 'default' directory kopiEren naar 'newtheme' en de web-GUI laat je automatisch deze optie kiezen. En dan kun je .css enzo aanpassen en je eigen stijl ontwerpen en die weer aan ons submitten. Als je dat wilt, uiteraard.

eigen javascript (waarom geen JQuery?)

jQuery alleen als het nodig is. Javascript is een breed ondersteunde taal. Waarom jQuery als het met Javascript kan? Werkt prima. Misschien later, als er dingen in ZFSguru terecht komen die wel leunen op jQuery. Misschien kan dan de knop een keer om. Maar ik ken Javascript ook beter dan jQuery. Volgens mij geldt hetzelfde voor Jason. Dus wat is wijsheid?

eigen bugtracker (waarom geen redmine?)

Op termijn eigen misschien, voorlopig is een andere prima. Net zoals de wiki natuurlijk. Ik had een stuk of 8 open source bugtrackers bekeken maar was nog niet laaiend enthousiast. Weet niet meer precies over Redmine, maargoed ik zal wel een leuke maken uit een van de minst slechten.

eigen benchmark tools (waarom geen [insert 10 verschillende tools].

ZFSguru gebruikt dd en rawio, low-level programma's die sequential en random I/O kunnen testen. Wat ZFSguru in-house heeft gebouwd is een scripted manier om allerlei ZFS configuraties na elkaar uit te proberen en alle resultaten in een grafiek te verwerken, zodat je ziet hoe de performance toeneemt met het uitbreiden van de hoeveelheid disks in configuraties als RAID0, mirror, RAID-Z1/2/3.

Dat is toch een mooie feature van ZFSguru? Je gaat juist een van de paradepaartjes bekritiseren.

Doet dat een lichtje branden?

Nou eerlijk gezegd nog niet echt.

Beter gezegd: Je werkt aan de dingen die jullie belangrijk vinden... Ik vind het vele honderden malen belangrijker dat jullie eens bugs zouden gaan pletten ipv een FreeBSD 10.0 image zouden uitbrengen... Dat is dus een *mening* en niet wat belangrijk *is*....

Bugs zijn allang geplet en dat wordt binnenkort gereleased. Dus aan die prioriteit wordt tot gevolg gegeven? Het had inderdaad eerder gekunt ja, dan had beta9 een bugfix release geweest en beta10 was nu wat beta9 gaat worden.

10.0 build start zodra de commit binnen is. Leuk want beta9 is dan wel af en kan dan mooie nieuwe ISO worden gemaakt met 10.0-RELEASE (final dus geen RC of beta) met de nieuwe beta9 web-interface. Daar is toch niets op tegen?

FireDrunk, je moet onderscheid kunnen maken tussen de plannen voor de toekomst (inderdaad, die zijn wild..) en wat we op kortere termijn proberen te bereiken. Dat laatste is echt de belangrijke dingen, geen rare zijwegen. Jullie vragen juist om documentatie en bugtracker en wiki, juist dat leidt af van ontwikkeltijd. Maar als het belangrijk genoeg gevonden wordt, natuurlijk dan kan het. Maar realiseer je wel dat alles tijd afsnoept van het doorontwikkelen van de kern van ZFSguru.

vrijdag 3 januari 2014 20:28

Acties:

0 Henk 'm!

CurlyMo

Zfs
ZFSguru
Opslag

Toch ook maar een reactie van mijn kant. Men ziet mij een beetje als een RaspberryPi guru hier op tweakers. Daarnaast heb ik regelmatig wat dingen gepost in het ZFS topic. Daarnaast heb ondertussen wel wat ervaring met community projecten door XBian van een soort ZFSGuru tot een Open Source project te maken. Hetzelfde doe ik nu met pilight.

Anoniem: 15758 schreef op vrijdag 03 januari 2014 @ 15:41:
Ik dacht eraan om iemand te vragen die makkelijk C / C++ code kan schrijven om een miniwebserver te bouwen.

Dat kan prima met libwebsockets, zoek maar eens op google. Dat gebruik ik ook in pilight:
https://github.com/piligh.../libs/pilight/webserver.c

Mogelijkheden in pilight:
- Mogelijkheid van caching van bestanden (via fcache library).
- Socket connectie via websockets (realtime).
- AJAX via door de server gegenereerde pagina's.
- HTTP login mogelijkheden.
- Nette 404 pagina's.

Eerst een korte reactie op hoe een community project werkt (vanuit mijn ervaring).
1. Je zet alle code op git of vergelijkbare plekken zodat het inzichtelijk is.
2. Zodra er meer gebruikers komen, komen er ook meer mensen die dingen willen toevoegen veranderen. Dat merkte ik met XBian en nu ook met pilight. Zeggen dat je de denkwijze moet begrijpen is natuurlijk onzin. Je legt namelijk alle verantwoordelijkheid bij de ander neer. Het maakt dan toch niet uit als er geen input komt. Dan is de situatie namelijk gewoon zoals die nu is. De verantwoordelijkheid voor dit uitblijven ligt dan tenminste bij de community, niet bij jullie.
3. Je begint zodra het een beetje begint te leven een kant-en-klaar forum. Iedereen kan zich aanmelden.
4. Je koppelt een wiki aan dat forum (zelfde login) en geeft iedere forum gebruiker toegang tot de wiki (zie www.pilight.org). Als zij een wiki willen, laten ze dan verantwoordelijkheid nemen. Komt er geen input op de wiki, dan blijft opnieuw de situatie hetzelfde als nu.
5. Zodra je merkt dat bepaalde personen veel meedenken en -werken geef je ze aanvullende rechten en toegang tot een gesloten forum. Zo komt er inzicht in het proces en heb je een brug tussen daadwerkelijke admins en de gebruikers. Zo hoef je zelf niet de communicatie te doen, maar kan je daar anderen voor vragen.

Je kunt nog steeds op je eigen manier werken, maar je geeft de community de mogelijkheid om inzicht te krijgen. Het is dan aan hun om met verbeteringen / toevoegingen te komen. Git maakt het mogelijk om vervolgens makkelijk nieuwe code te integreren. Geen handwerk meer nodig.

Wat ik veel hoor ik het argument dat er plannen zijn maar niemand weet wat die plannen zijn. Wat let je om duidelijk te maken wat die zijn. Zelf heb ik daar een apart topic voor genaamd "Feature Requests". Daar zet ik ook alle dingen ik die ik zelf van plan ben te maken. Dat gedeelte van het forum heb ik alleen toegang toe zodat het niet vervuild raakt met allerlei meuk van gebruikers. Ik kies wat ik erin zet.

Binnen pilight zijn er vanuit nature de volgende rollen gekomen:
- Zij die meehelpen met ontwikkelen van protocollen (4 personen).
- Zij die meehelpen met electronica (ook 4 personen).
- Iemand die de blogs op de website schrijft (2 personen).
- Mensen die externe apps schrijven (6 personen).
Ikzelf meegerekend.

Daar heb ik niks aan hoeven doen. Ze kwamen vanzelf.

Wat ik bedoel met community project is dat alle devs gelijkwaardig zijn en beslissingen op basis van consensus wordt genomen. FreeBSD is aardig dat idee, waar er een kernteam is wat van samenstelling is. Een soort naamloze vennootschap (NV) dus, in tegenstelling tot een BV wat een duidelijke eigenaar kent.

Dat is een beperkte visie van community. Vrijwel alle grote community projecten hebben een aantal "redacteuren". Zie bijv. XBMC: https://github.com/xbmc/xbmc/pulls. Het hoofd team bepaalt wat er in het project komt en wat niet. Devs zijn dus verre van gelijkwaardig.

Als het punt is dat de community dicteert welke richting ZFSguru op gaat, dan is het geen community-project.

Opnieuw een negatieve weergave. De community dicteert niet. De community gebruikt ZFSGuru niet voor niks. Daarnaast bepaald je zelf welke ideeën je integreert en welke niet.

Het punt is tijd, alles kost tijd. Een bugtracker in elkaar flanzen ook; ik heb wat argumenten gegeven. Dat betekent niet dat het er niet komt, ook niet dat alles een in-house oplossing moet zijn. Tijdelijk wat anders is prima, misschien wel permanent we zien wel. Maar er kan niet alles tegelijkertijd.

Die heeft git zelf al.

Ik ken toevallig iemand die in het verleden aangeboden heeft om wat dingen te coden, dus daar dacht ik dan aan, misschien een leuk relatief eenvoudig project voor hem. Of eventueel voor een ander die zich geroepen voelt. Komt het er niet, jammer dan blijven we bij Lighttpd, geen tijd verloren. Komt het er wel, dan zijn Jason en ik ook geen tijd kwijt, omdat een ander deze toevoeging doet.

Iemand doet deze toevoeging alleen als het hem zo min mogelijk moeite kost. Dus wanneer zijn workflow ook wordt gefaciliteerd. Daarbij kan git bijv. al helpen.

Sinds de 2 dagen regel reageer ik hier niet meer

vrijdag 3 januari 2014 20:38

Acties:

0 Henk 'm!

Anoniem: 15758

Topicstarter

*** Groot nieuws ***

Jason heeft een reactie gegeven:

Lees de reactie van Jason

vrijdag 3 januari 2014 23:15

Acties:

0 Henk 'm!

EnerQi

Ik heb zijn reactie gelezen en er staat niet veel nieuws in. Hij zegt hetzelfde als jou CiPHER

.

Ik denk dat hier ook de meeste commentaren terug te brengen is naar communicatie en de manier hoe naar het project gekeken wordt vanaf de zijlijn. Jullie (CiPHER en Jason) zien ZFSguru in alle glorie en zien ook waar het naar toe gaat, jullie communiceren onderling meer. Wij (simpele) gebruikers zien dat niet / onvoldoende. Dit in combinatie met "community project" en het niet faciliteren van dit (documentatie/bugtracker/wiki, inspraak??), zorgt voor onvrede. Door dit topic wordt dit geuit en hopelijk kunnen jullie hier iets mee.

Persoonlijk denk ik dat we (users) best kunnen wachten op de "eigen" wiki/bugtracker zonder potentiele security problemen (+- 2a3 maanden). Ik kan me namelijk goed voorstellen dat de tijd die je nu eraan besteed niet echt zinvol is. Het is niet zo dat ZFSguru kapot is

. Het is nu wel van belang dat jullie "on speaking terms" blijven. Zorg met een simpele post/topic wat de problemen zijn waar jullie tegenaan lopen en wanneer we iets kunnen verwachten. Wees hierin realistisch en hou de kerngebruikers (mensen in dit topic dus

) te vriend. Zij zullen namelijk het project doorvertellen/"verkopen" aan andere waardoor het project dus meer input krijgt waarmee jullie iets kunnen. Hoe meer zielen, hoe meer vreugd.

p.s. moet ik dit ook vertalen naar het engels?

zaterdag 4 januari 2014 09:19

Acties:

0 Henk 'm!

Wouter.S

e^(i*pi ) +1 = 0

Tof om te zien dat Jason toch de moeite heeft genomen om onze feedback te lezen, al vrees ik dat de boodschap toch niet volledig goed overkomt (het taalverschil draagt hier natuurlijk ook tot bij). Dit is spijtig van zoals EnerQi zegt zitten hier toch wel een belangrijke groep beta-testers en hulp voor de (verre) toekomst van het project.

Ik snap de hele polemiek rond security en een wiki/bugtracker niet helemaal. Als er toch nergens code wordt gepost wat is dan het probleem ? Er zijn toch tig zulke websites op het grote wereldwijde web, waarom is ZFSGuru hier anders? Het is toch gewoon een oplijsting van informatie, geen toegang tot nucleaire launch codes ofzo

En ik zou zeggen wacht zeker geen 3 maanden hiermee...zelfs als het wat extra tijd kost het is ten minste een teken naar 'de community' dat ze gewaardeerd worden. Zo kan dit wat momentum opbouwen, wanneer het dan volgens jullie tijd is bij de release van een meer complete versie is er ten minste al IETS aanwezig. Want volgens mij gaan jullie er een beetje vanuit dat wanneer er een bepaalde grote stap bereikt is in de ontwikkeling er plots honderden mensen gaan staan springen om te helpen, terwijl dit in mijn ogen juist iets is wat over tijd wordt opgebouwd.

Om het even in jouw term uit te drukken CiPHER, tijd is inderdaad zeer waardevol. Niet alleen tijd om te coden/ontwikkelen maar minstens even belangrijk tijd om een goede band op te bouwen met de mensen waarvoor je iets probeert te maken, het menselijk aspect wordt volgens mij nogal onderbelicht.

Bekijk het eens zo: Resultaat = Oplossing x Aanvaarding

Momenteel werken jullie nagenoeg uitsluitend aan de technische oplossing, de in jullie ogen meest ideale manier en als iets niet volledig naar jullie wens is schrijven jullie zelf dingen. Laten we zeggen O=99% van perfectie.

De tijd en moeite die jullie voorlopig investeren in de community/mensen (zaken als bugtracker, wiki, etc...) is zeer beperkt. Laten we zeggen A=10% van wat het zou moeten zijn.

Als resultaat haal je dus R = 99% x 10% = 9.9% bitter weinig dus ondanks dat technisch alles zowaar perfect is.

Maar als jullie nu ook de focus leggen op de community/mensen dan kunnen jullie wel bijvoorbeeld 70% halen voor A. Dit gaat dan wel ten koste van O, bijvoorbeeld ook 70% van de perfecte oplossing, maar dit is niet erg! Als resultaat haal je dan namelijk al R= 70% x 70% = 49 %, en zeg nu zelf, welk rapport zouden jullie het liefste krijgen

Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction.

zaterdag 4 januari 2014 09:27

Acties:

0 Henk 'm!

FireDrunk

Zfs
ZFSguru
Opslag

Mooi gezegd!

Even niets...

zaterdag 4 januari 2014 09:40

Acties:

0 Henk 'm!

EnerQi

En ik zou zeggen wacht zeker geen 3 maanden hiermee...zelfs als het wat extra tijd kost het is ten minste een teken naar 'de community' dat ze gewaardeerd worden. Zo kan dit wat momentum opbouwen, wanneer het dan volgens jullie tijd is bij de release van een meer complete versie is er ten minste al IETS aanwezig. Want volgens mij gaan jullie er een beetje vanuit dat wanneer er een bepaalde grote stap bereikt is in de ontwikkeling er plots honderden mensen gaan staan springen om te helpen, terwijl dit in mijn ogen juist iets is wat over tijd wordt opgebouwd.

Het klopt dat de communitie over tijd opgebouwd wordt. De vraag die ik mij stel, kunnen wij geen 3 maanden wachten? Het feit dat CiPHER en Jason de moeite genomen hebben om reacties te geven in dit topic geeft toch ook al aan dat ze ons waarderen?

Als de oplossing over 2a3 maanden beter is (zegt CiPHER en Jason

), dan verwacht ik niet dat hier veel mensen afhaken of bijspringen bij de tijdelijke oplossing. Het risico zit nu in die 3 maanden, die is nu al te vaak genoemd om nog vanaf te wijken

.

-----
Ergens staat ook vermeld dat CiPHER bezig is met ZFSguru 0.3 features. Dit is dus DE manier om de communitie te laten afhaken. Er wordt namelijk niet verteld waarom hij niet bezig is met de nieuwe wiki/bugtracker etc. De zaken waar de commitie op aan het wachten is. Hoogstwaarschijnlijk wegens gebrek aan hardware, maar dit wordt niet verteld

[ Voor 14% gewijzigd door EnerQi op 04-01-2014 09:46 . Reden: toevoeging ]

zaterdag 4 januari 2014 10:08

Acties:

0 Henk 'm!

FireDrunk

Zfs
ZFSguru
Opslag

Als dat het enige probleem is mag hij zo meeliften op mijn redmine installatie hoor. Ik heb een VPS met een werkende Redmine installatie inclusief SCRUM plugins

Even niets...

zaterdag 4 januari 2014 12:09

Acties:

0 Henk 'm!

Wouter.S

e^(i*pi ) +1 = 0

Niet om de zaag uit te gangen maar als er gezegd wordt 2 à 3 maand dan zou ik verwachten dat het effectief 4 à 5 maand zal duren. En dat zeg ik zeker niet om Jason of CiPHER af te breken, maar gewoon objectief kijkend naar alle voorgaande data die worden vooropgesteld en de effectieve uitvoering ervan. Dingen gaan immers vaak net iets trager dan gedacht, dit is overal zo. En 4 à 5 maand is gewoon...lang, bedenk eens wat er kan groeien in een community op deze tijdspanne...

Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction.

zaterdag 4 januari 2014 13:19

Acties:

0 Henk 'm!

HyperBart

Zfs
ZFSguru

Met alle antwoorden en posts die hier gedaan zijn, val ik ook maar even bij.

Ik denk dat het grootste probleem is, dat jullie inzet in bepaalde prioriteiten afgezet tegen het nut wat wij als gebruikers er van inzien bij jullie heel scheefgetrokken is...

Eigenlijk verwacht ik van jullie als NAS-distro bouwers dat jullie focussen op de distro, en niet op 43 andere projecten daarrond....En nu heb ik het gevoel dat jullie een NAS distro willen op de markt zetten en ondertussen tot de constatatie zijn gekomen dat de onderliggende funderingen rot zijn, die helemaal gaan omgooien en ondertussen maar wat aanmodderen met de huidige functionaliteiten en daar telkens halve ruïnes op bouwen ipv eens strak en deftig blok per blok af te werken...

zaterdag 4 januari 2014 14:04

Acties:

0 Henk 'm!

roy.jacobs

Anoniem: 15758 schreef op vrijdag 03 januari 2014 @ 20:09:
Waarom jQuery als het met Javascript kan? Werkt prima. Misschien later, als er dingen in ZFSguru terecht komen die wel leunen op jQuery. Misschien kan dan de knop een keer om. Maar ik ken Javascript ook beter dan jQuery.

Je lijkt hier te zeggen dat jQuery een aparte taal is, los van Javascript?

zaterdag 4 januari 2014 14:58

Acties:

0 Henk 'm!

FireDrunk

Zfs
ZFSguru
Opslag

Hij heeft er duidelijk nog niet genoeg mee gewerkt om de voordelen te zien.

Even niets...

zaterdag 4 januari 2014 15:02

Acties:

0 Henk 'm!

roy.jacobs

Nou ja, ik probeer gewoon te achterhalen wat nu eigenlijk het niveau van de twee developers is, dat wordt me niet zo goed duidelijk.

zaterdag 4 januari 2014 15:55

Acties:

0 Henk 'm!

ikkeenjij36

Ook ik zzal even mijn mening geven,als newbie linux/nas gebruiker heb ik de verschillende distro's geprobeerd als freenas nas4free omv enz enz.
Tot ik zfsguru tegen kwam,dat werkt voor mij tot nu toe nog het makelijkste mag er eens wat mis gaan omdat ik iets via de ports probeer te instaleren/veranderen ff mijn ssd tje schoon en opnieuw beginnen.
Echter de support op het forum is nagenoeg dood en dat is erg jammer want als beginner is het toch reuze makkelijk als er support is.
Ook nu nog na eens een fresh install nadat er wat mis is gegaan zijn er nog bepaalde services die buggy zijn/blijven en als ik die rechtstreeks wil gebruiken bv. via LaSi.sh lukt het niet omdat er een bug in de build zit,iets met python libtools,dat wordt dus veroorzaakt door zfsguru en niet door mezelf want ik heb het over een clean install.
Echter dit allemaal geklaagd hebben moet ik wel de complimenten aan CIPHER geven want als ik er echt niet meer uitkom en niet al mijn data wil/moet dl dan krijg ik meestal binnen de kortst mogelijk tijd antwoord.
Ik kan natuurlijk niet zo diep mee discusieren over de onderliggende systemen zoals de meeste van jullie maar ik wou ook even mijn mening laten horen als beginnende gebruiker.
En voor de rest zal ik het hier en op het grote zfs topic blijven volgen.

zaterdag 4 januari 2014 18:12

Acties:

0 Henk 'm!

Anoniem: 15758

Topicstarter

EnerQi schreef op vrijdag 03 januari 2014 @ 23:15:
Ik denk dat hier ook de meeste commentaren terug te brengen is naar communicatie en de manier hoe naar het project gekeken wordt vanaf de zijlijn. Jullie (CiPHER en Jason) zien ZFSguru in alle glorie en zien ook waar het naar toe gaat, jullie communiceren onderling meer. Wij (simpele) gebruikers zien dat niet / onvoldoende. Dit in combinatie met "community project" en het niet faciliteren van dit (documentatie/bugtracker/wiki, inspraak??), zorgt voor onvrede. Door dit topic wordt dit geuit en hopelijk kunnen jullie hier iets mee.

Nouja we gaan het zeker serieus nemen. Echter tot nu toe heb ik nog niet het gevoel dat we echt tot kernissues zijn gekomen. Zo vraagt Jason ook heen concreet: wat willen jullie?

Ik had een lijstje gemaakt:

Wiki
Bugtracker
Community officer

Maar ik neem aan dat alle kritiek veel breder is dan dat. De vraag is dus, welke concrete verbeteringspunten kunnen jullie voorstellen aan Jason? Dan kan ik met een concreet voorstel naar Jason stappen en vragen en dan is het ja of nee, maar dan komt er in elk geval wat uit. Want ik hoop natuurlijk - net als jullie dacht ik - dat er iets moois komt uit dit discussietopic. Dat jullie mij hebben weten te overtuigen over het één en ander, en omgekeerd misschien ook of in elk geval het e.e.a. verduidelijkt.

Persoonlijk denk ik dat we (users) best kunnen wachten op de "eigen" wiki/bugtracker zonder potentiele security problemen (+- 2a3 maanden). Ik kan me namelijk goed voorstellen dat de tijd die je nu eraan besteed niet echt zinvol is.

Misschien is wachten toch niet nodig. Ik kan ook gewoon hem nu op bravo server draaien in een jail op een andere poort met shared IP. Dan zou de wiki er al heel binnenkort kunnen zijn, en bij aankomst van de nieuwe server verhuist hij dan en krijgt hij een mooie domeinnaam. Dat is mogelijk. Dan is het ook zo dat er direct resultaat wordt geboekt uit de discussie, anders voelt het voor jullie wellicht ook alsof het weinig heeft opgeleverd.

Nu we al een heleboel gezegd hebben, kunnen we proberen de issues te concentreren en concrete voorstellen te doen. Dus bij deze: vul mijn lijstje aan met punten die je belangrijk vindt. Morgen ofzo kan ik dan een eindlijstje maken en dat aan Jason voorleggen, zo had ik het in gedachte. Idee?

Wouter.S schreef op zaterdag 04 januari 2014 @ 09:19:
Tof om te zien dat Jason toch de moeite heeft genomen om onze feedback te lezen, al vrees ik dat de boodschap toch niet volledig goed overkomt (het taalverschil draagt hier natuurlijk ook tot bij).

Ik moet heel eerlijk zeggen dat ook ik de discussie wel erg breed vind en het voor mij ook niet altijd duidelijk is wat wordt gevraagd. Zo is al in het begin positief geantwoord op wiki en zijn er wat details besproken, maar wat is er nu precies wat jullie willen wat wij ook concreet kunnen doen/veranderen?

Filosoferen over de toekomst is ook leuk maar daar gaan natuurlijk geen concrete verbeterpunten uit voren komen.

Ik snap de hele polemiek rond security en een wiki/bugtracker niet helemaal. Als er toch nergens code wordt gepost wat is dan het probleem ? Er zijn toch tig zulke websites op het grote wereldwijde web, waarom is ZFSGuru hier anders? Het is toch gewoon een oplijsting van informatie, geen toegang tot nucleaire launch codes ofzo

Dat is een misverstand. Het gaat niet om de code wat een veiligheidsrisico is, het gaat erom dat kant en klare pakketten vaak kwetsbaarheden kennen die actief met exploits worden misbruikt. Als de wiki op dezelfde server zou draaien als de master server, betekent dit dat al jullie ZFSguru servers risico lopen. Installeer een service en er zou een virus geïnstalleerd kunnen worden. Dat kan natuurlijk echt niet.

En wij hebben geen 20 servers of meerdere IPs voor goede security (BSD Jail) oftewel privilege separation. Workaround zou zijn op een andere poort dan 80 draaien met een local alias of wachten op onze nieuwe server (2-3 maanden). Die workaround is zeker mogelijk en ga ik onderzoeken, dan kan de Wiki al veel eerder online.

Want volgens mij gaan jullie er een beetje vanuit dat wanneer er een bepaalde grote stap bereikt is in de ontwikkeling er plots honderden mensen gaan staan springen om te helpen, terwijl dit in mijn ogen juist iets is wat over tijd wordt opgebouwd.

Dat lijkt mij inderdaad zo ja. Als de drempel sterk wordt verlaagd en ook niet-coders kunnen bijdragen via geautomatiseerde mechaniek, dan betekent dit dat ZFSguru een flinke boost krijgt. Je hebt wel een punt dat een community zich opbouwt en niet opeens poef ontstaat. Maar de community nu is erg klein. Zodra ZFSguru een completer en dus interessanter product wordt, zal ook de (potentiële) omvang van de community toenemen. Als op dat moment ook de tools voor contributie (zelf services maken, etc) klaar is, dan kan op dat moment de community ook snel aantrekken. Dan is ZFSguru er 'klaar voor'.

Jullie willen nu al een community opbouwen, in de tijd waar er nog aan de kern van ZFSguru gewerkt wordt en de eerste stabiele release nog moet komen. Dat leek mij persoonlijk niet de beste keuze. Maar als dat de wens is van de community dan wil ik daar zeker naar luisteren en ook wel het één en ander voor opofferen. Want de discussies hier gaan natuurlijk ook ten koste van mijn tijd aan ZFSguru. Maar ik zie dat wel als waardevol, omdat het mij ook van gedachte kan laten veranderen. Daar probeer ik namelijk heel erg voor open te staan, al krijg ik de indruk dat jullie dat gevoel niet zo hebben.

Om het even in jouw term uit te drukken CiPHER, tijd is inderdaad zeer waardevol. Niet alleen tijd om te coden/ontwikkelen maar minstens even belangrijk tijd om een goede band op te bouwen met de mensen waarvoor je iets probeert te maken, het menselijk aspect wordt volgens mij nogal onderbelicht.

Goed punt!

zaterdag 4 januari 2014 18:28

Acties:

0 Henk 'm!

Midas.e

Is handig met dinges

Niet om het een of andere, maar Jason en Ciper jullie steken beide de kop wel een beetje in het zand. Hoe kan je spreken van veiligheid als er geen openheid van de code is? Er kan geen audit worden gedaan en dus weet niemand of er wat mis mee is. Hoe kan je zeggen of iets beter werkt als er niet mee getest wordt? Hoe kan je spreken van OSS als er geen code bestaat voor inzicht.
Zelfs in dit topic wordt er hulp aangeboden maar wordt gewoon naast je neer gelegd.

Ik twijfel dan ook erg over wat hiermee wordt gedaan, ik hoop het beste, ik verwacht niets.

Hacktheplanet / PVOutput

zaterdag 4 januari 2014 19:22

Acties:

0 Henk 'm!

Anoniem: 15758

Topicstarter

EnerQi schreef op zaterdag 04 januari 2014 @ 09:40:
Het klopt dat de communitie over tijd opgebouwd wordt. De vraag die ik mij stel, kunnen wij geen 3 maanden wachten? Het feit dat CiPHER en Jason de moeite genomen hebben om reacties te geven in dit topic geeft toch ook al aan dat ze ons waarderen?

Dat laatste misschien wel, maar ik denk inderdaad wel dat het 'momentum' weg is als het pas over 3 maanden begint. Als jullie een Wiki willen, is het leuk als het er volgende week is. Dat moet mogelijk kunnen zijn, ook al is dat met een vage domeinnaam/poort.

Ergens staat ook vermeld dat CiPHER bezig is met ZFSguru 0.3 features. Dit is dus DE manier om de communitie te laten afhaken. Er wordt namelijk niet verteld waarom hij niet bezig is met de nieuwe wiki/bugtracker etc. De zaken waar de commitie op aan het wachten is.

Nou wat de community wilt is mij nog steeds niet duidelijk. Als die wiki en bugtracker er komen, is dan alles uit de lucht? Is dat het waar jullie om vragen? Dan zijn we er toch uit? Of zijn er toch nog meer dingen die dwarsliggen?

En waarom we aan 0.3 features werken? Om ZFSguru verder te ontwikkelen! Alles eromheen, dus support, wiki, forum leidt natuurlijk wel af van de aandacht die de kern van het project zelf krijgt. Jason is ontwikkelaar, dus laat hem... ontwikkelen! Dat is wat hij kan.

Wouter.S schreef op zaterdag 04 januari 2014 @ 12:09:
Niet om de zaag uit te gangen maar als er gezegd wordt 2 à 3 maand dan zou ik verwachten dat het effectief 4 à 5 maand zal duren. En dat zeg ik zeker niet om Jason of CiPHER af te breken, maar gewoon objectief kijkend naar alle voorgaande data die worden vooropgesteld en de effectieve uitvoering ervan.

Dat klopt, de deadlines worden vrijwel nooit gehaald. Nu is dat wel een beetje traditie voor BSD-land. De FreeBSD 10.0-release is ook maanden vertraagt. Allemaal niet erg; de gebruikers willen een 'Done when it's done'-mentaliteit.

Dingen gaan immers vaak net iets trager dan gedacht, dit is overal zo. En 4 à 5 maand is gewoon...lang, bedenk eens wat er kan groeien in een community op deze tijdspanne...

Helemaal mee eens. Zou mooi zijn als in elk geval de wiki heel binnenkort al online kan. Ik wil natuurlijk ook graag laten zien dat er wat wordt gedaan met jullie suggesties. Maar het gaat me niet om er van verlost te zijn, ik wil juist wel graag overtuigd worden! Alleen gaat dat nog niet zo makkelijk, maar verlies alsjeblieft geen hoop!

FireDrunk schreef op zaterdag 04 januari 2014 @ 10:08:
Als dat het enige probleem is mag hij zo meeliften op mijn redmine installatie hoor. Ik heb een VPS met een werkende Redmine installatie inclusief SCRUM plugins

Zou zeker kunnen, misschien kun je eenvoudig een Redmine opzetten en in elk geval uittesten of het doenlijk is om dit daadwerkelijk te gebruiken. Dus als jij die tijd wilt investeren, graag!

zaterdag 4 januari 2014 19:48

Acties:

0 Henk 'm!

EnerQi

Anoniem: 15758 schreef op zaterdag 04 januari 2014 @ 19:22:

Nou wat de community wilt is mij nog steeds niet duidelijk. Als die wiki en bugtracker er komen, is dan alles uit de lucht? Is dat het waar jullie om vragen? Dan zijn we er toch uit? Of zijn er toch nog meer dingen die dwarsliggen?

En waarom we aan 0.3 features werken? Om ZFSguru verder te ontwikkelen! Alles eromheen, dus support, wiki, forum leidt natuurlijk wel af van de aandacht die de kern van het project zelf krijgt. Jason is ontwikkelaar, dus laat hem... ontwikkelen! Dat is wat hij kan.

[...]

Dat klopt, de deadlines worden vrijwel nooit gehaald. Nu is dat wel een beetje traditie voor BSD-land. De FreeBSD 10.0-release is ook maanden vertraagt. Allemaal niet erg; de gebruikers willen een 'Done when it's done'-mentaliteit.

De hint was hierin dus onduidelijk. Je vertelde eerder dat je aan 0.3 features werkt wat natuurlijk geweldig is. Alleen is het ons niet duidelijk waarom we dan moeten wachten op de nieuwe site/wiki/bugtracker etc. Voor ons voelt het meer aan als: dood project (maanden), 1 topic + nieuwe versie FreeBSD, dood project (maanden), 1 topic + nieuwe versie + state of project van Jason, dood project (maanden), nu dit topic.

Dat ontwikkelingen traag zijn, geloof ik graag en het liefst zou ik ZFSguru 1.0 al willen installeren in al zijn glorie maar ik moet ook gewoon wachten en geduldig zijn

. Ook hier geldt dat mensen dit willen weten of iets uitloopt of niet en waarom.

Communiceer wat jullie doen en waar je hulp voor nodig hebt. Eigenlijk geef je hierboven al aan dat de eigen wiki/bugtracker/site etc niet echt hoog op de prioriteit lijst staan. Laat dit dan door iemand anders doen of geef aan dat beta 10 even minder prio heeft ivm andere zaken

.

Na beta 9 zal er een nieuwe start gemaakt worden ivm bugs en verwachtingen (is mijn verwachting). De vraag die iedereen (de kerngebruikers) bezig houdt: Zal er nu echt iets veranderen na beta 9?

Die vraag zal alleen positief beantwoord kunnen worden als: CiPHER en Jason actief meldingen gaan opvolgen en uitsturen + vragen beantwoorden van users (tenzij andere dit al gedaan hebben

).

Mij valt vooral op dat Jason reageert wanneer dingen al geëscaleerd zijn (ook in dit topic). Met escaleren bedoel ik: vertrouwen in de terugkeer van Jason en vertrouwen in ZFSguru (wegens niets horen van Jason). Laat zien dat het project nog springlevend is!

Niet om het een of andere, maar Jason en Ciper jullie steken beide de kop wel een beetje in het zand. Hoe kan je spreken van veiligheid als er geen openheid van de code is? Er kan geen audit worden gedaan en dus weet niemand of er wat mis mee is. Hoe kan je zeggen of iets beter werkt als er niet mee getest wordt? Hoe kan je spreken van OSS als er geen code bestaat voor inzicht.

Ik hoop ook dat dit in de toekomst ook veranderd. Ikzelf verwacht dat het moment dat de communitie services kunnen maken, er meer openheid gegeven MOET worden. (anders kun je niets maken

). Dit wil niet zeggen dat het gepost moet worden op Github ofzo. Overigens is deze discussie wel een beetje over-de-top. Microsoft deelt zijn code ook niet en toch gebruiken een hoop mensen Windows

. Ook die menen dat hun OS superveilig is.

[ Voor 14% gewijzigd door EnerQi op 04-01-2014 19:53 . Reden: Aanvulling ]

zaterdag 4 januari 2014 20:28

Acties:

0 Henk 'm!

CurlyMo

Zfs
ZFSguru
Opslag

De community wil naar mijn idee vooral als volwaardige community gezien worden. Die bestaat daarbij uit twee groepen:

De bijdragers hebben het volgende nodig:
- Alle code ergens op internet zodat meewerken mogelijk en makkelijk is (bijv. github).
- Een plek om over code te discussiëren en vragen te stellen (bijv. github).
- Een bugtracker waarop technische problemen gemeld kunnen worden en eventueel opgelost door andere uit deze groep.
- Een beschrijving van de eventuele API of logica van de code (kan eventueel ook door mensen uit deze groep geschreven worden).

De gebruikers het volgende:
- Een forum waarop vragen gesteld kunnen worden en gediscussieerd. Eventueel geleid door jullie opgewaardeerd gebruikers die er moderators zijn. FireDrunk zou zo iemand kunnen zijn. Zo hoeven de die-hard dev's zelf niet overal op in te gaan.
- Een wiki waarop alle informatie staat die een gebruiker nodig heeft.
- Een FAQ waarop snel voor de meest voorkomende problemen antwoorden te vinden zijn.

Idealiter zijn de wiki, bugtracker, beschrijving van code, en FAQ voor de mensen uit die betreffende groep te bewerken zodat de community zelf aanvullingen kan doen. Zo kost het jullie geen tijd.

Het belangrijkste van een community project is wel dat je gelooft in de meerwaarde ervan. Je moet ervan overtuigd zijn dat de community in staat is het project beter te maken, toevoegingen te doen waar jullie zelf niet aan dachten of geen tijd voor hadden. Ik hoor nog te vaak dat jullie daar sceptisch over zijn waarop ik weer sceptisch ben ik mijn hoop dat het gaat lukken.

Mijn mening is dat het ideale community project kan wisselen van (hoofd)ontwikkelaars. Wanneer degene zich aandienen die beter zijn om de dingen te doen waarvan jullie dromen, je je project als het ware van de hand kan doen ten behoeve van de kwaliteit van het project. Het gaat daarbij niet om persoonlijke eer, maar die van het project. Je kan dan altijd zelf de lijnen blijven uitzetten, maar je wordt dan vooral een manager i.p.v. ontwikkelaar. Je laat nog steeds weten waar je dromen uit bestaan, maar laat andere kwalitatieve ontwikkelaars het uitvoeren.

Mijn boodschap was hopelijk duidelijk. Als jullie een simpele webserver willen waarvan de enige eis is dat die php scripts aanroept. Dan kan ik daar wel mee helpen. Het enige dat deze webserver dan zal doen is een brug zijn tussen php code en javascript websockets. Dan kan je je hele webGUI in javascript bouwen en via een socket connectie met je php scripts communiceren.

Sinds de 2 dagen regel reageer ik hier niet meer

zaterdag 4 januari 2014 20:41

Acties:

0 Henk 'm!

Anoniem: 15758

Topicstarter

HyperBart schreef op zaterdag 04 januari 2014 @ 13:19:
Eigenlijk verwacht ik van jullie als NAS-distro bouwers dat jullie focussen op de distro, en niet op 43 andere projecten daarrond....

Dat doen we ook, we zijn met systeemarchitectuur, services en web-interface bezig geweest. 100% ZFSguru. Enige wat je kunt noemen is de nieuwe website en brainstormen over de toekomst, maar dat staat niet in verhouding tot de aandacht die ZFSguru krijgt.

Wij werken wel degelijk aan de belangrijke dingen in ZFSguru!

En nu heb ik het gevoel dat jullie een NAS distro willen op de markt zetten en ondertussen tot de constatatie zijn gekomen dat de onderliggende funderingen rot zijn, die helemaal gaan omgooien en ondertussen maar wat aanmodderen met de huidige functionaliteiten en daar telkens halve ruïnes op bouwen ipv eens strak en deftig blok per blok af te werken...

Nou dat klopt niet.

Het project begin als een demo dat FreeBSD bruikbaar is als ZFS NAS OS, op het HardOCP forum. Dat was heel simpel met shell commando's, php code en html code in hetzelfde document. Toen ZFSguru was serieuzer werd, en zijn eigen naam kreeg, wilde Jason de code herschrijven zodat php en html-code gescheiden waren. Daarbij ontstond het template-idee wat ZFSguru nu gebruikt. En stuk voor stuk zijn daarna alle features verbeterd van demo-kwaliteit maar ZFSguru-kwaliteit.

Voorbeeld is de oude Samba en NFS-functionaliteit. Dat is nu het ouste gedeelte in ZFSguru en die functionaliteit stelt niets voor. Dat wordt nu vervangen door échte functionaliteit. Dus we gaan wel degelijk de punten af met oog voor perfectie. Jason houdt niet van afraffelen. Maar als iets onvolmaakt is, dan geeft hij daar ook weinig om. Dan moet het gewoon nog écht ontwikkeld worden.

En nu zijn we op een punt dat ZFSguru compleet aan het raken is. Dan wil Jason weer een kwaliteitsronde om de code te verbeteren. Dat was Mesa, waarbij in feite ZFSguru core-code werd herschreven en gelijk in universele libraries werd gestopt. Dat is wat Mesa is geworden; of gaat worden. ZFSguru gaat uiteindelijk profiteren van shared code en betere code quality.

roy.jacobs schreef op zaterdag 04 januari 2014 @ 14:04:
Je lijkt hier te zeggen dat jQuery een aparte taal is, los van Javascript?

jQuery is een Javascript-script. Maar behalve gewoon codelibraries, laat jQuery je ook de syntax van de 'Javascript'-taal vereenvoudigen. Maar de code die je dan schrijft is 'jQuery-script' code; dergelijke code kan nooit als standaard Javascript worden geïnterpreteerd.

Javascript is een rommeltje en niet gestandaardiseerd (afgezien van ECMAscript, wat een poging daartoe is). jQuery is een extra bestandje wat je bij de pagina meelaadt en dan kun je eenvoudiger Javascript-code schrijven. Maar mijn argument is dat dergelijke code geen 'Javascript'-code meer is, maar dat jQuery inderdaad min of meer als eigen programmeertaal gezien kan worden. Het is niet vergelijkbaar met wat PEAR voor PHP is, om maar wat te noemen, dat zijn louter libraries.

zaterdag 4 januari 2014 20:42

Acties:

0 Henk 'm!

Anoniem: 15758

Topicstarter

EnerQi schreef op zaterdag 04 januari 2014 @ 19:48:
De hint was hierin dus onduidelijk. Je vertelde eerder dat je aan 0.3 features werkt wat natuurlijk geweldig is. Alleen is het ons niet duidelijk waarom we dan moeten wachten op de nieuwe site/wiki/bugtracker etc.

Omdat ook dat tijd kost, zeker om het goed te doen. Maar de Wiki kan binnen een week online zijn, en als FireDrunk aanbiedt om Redmine te configgen dan hebben we de Wiki en Bugtracker al klaar. Maar mijn vraag is: zijn de wensen dan voltooid?

Dat ontwikkelingen traag zijn, geloof ik graag

Ontwikkeling is juist heel snel voor een klein team, gezien de ambities die we hebben. Wel is het zo dat dit niet zichtbaar is voor de gebruikers, in elk geval in 2013 waar er weinig aandacht uitging naar de web-interface. Dat gezegd wordt wel vergeten dat de 0.2-beta releases hele grote stappen zijn. Het verschil tussen de eerst 0.2 beta en beta9 is gigantisch. Van 0.2-alpha tot 0.2-beta9 is denk ik ongeveer 30 keer meer werk geweest dan ZFSguru 0.0.1 (de demo op HardOCP) tot 0.1.9.

Kortom, de versienummering klopt niet helemaal. Maar je zult ook zien dat in 2014 de web-interface veel releases zal kennen. Dan denken jullie dat de ontwikkeling opeens weer heel snel gaat, terwijl in de praktijk dat helemaal niet zo is; het lijkt alleen zo.

Communiceer wat jullie doen en waar je hulp voor nodig hebt.

Dat probeer ik toch ook? Ik kan me voorstellen dat de communicatie richting gebruikers voorheen erg karig was. Maar je kunt ook niet zeggen dat we ons nergens van aantrekken. Maar nog steeds geldt dat niet echt duidelijk is wat er van ons wordt gevraagd. Beter communiceren, oke, wiki, oke, bugtracker oke, maar er wordt een heleboel meer gezegd in dit topic en daar kan ik minder gauw iets mee. Wellicht is dit ook een punt voor jullie om ook duidelijk te zijn wat jullie van ons verwachten.

Eigenlijk geef je hierboven al aan dat de eigen wiki/bugtracker/site etc niet echt hoog op de prioriteit lijst staan. Laat dit dan door iemand anders doen of geef aan dat beta 10 even minder prio heeft ivm andere zaken .

Iemand van jullie die het wilt doen? Prima! Steek de hand maar in de lucht.

Maar bij gebrek aan een vrijwilliger kunnen wij natuurlijk ook wat tijd vrijmaken voor verbetering van de community. Maar begrijp wel dat dit ten koste gaat van kostbare ontwikkeltijd. Zeker in dit stadium van het project is het inderdaad een mindere prioriteit. Maar hij gaat er komen hoor! Jullie vragen erom, dus prima. Vind het zelf ook wel geinig en misschien komen er mooie dingen van. Maar de ontwikkeling van ZFSguru, dat is toch echt topprioriteit. Alles valt of staat bij verdere ontwikkeling. Het echt opbouwen van de community kan prima later dan hebben wij onze handen ook meer vrij omdat belangrijke zaken al zijn afgewikkeld. In die fase van het project wordt de binding met gebruikers veel belangrijker, zo zit in mijn hoofd.

Na beta 9 zal er een nieuwe start gemaakt worden ivm bugs en verwachtingen (is mijn verwachting). De vraag die iedereen (de kerngebruikers) bezig houdt: Zal er nu echt iets veranderen na beta 9?

Nieuwe start in welke zin, wat zou er moeten veranderen? Wat je wel kunt verwachten, is dat er in 2014 flink meer releases zullen zijn van de web-interface. En met meer releases verwacht ik ook dat de rest eromheen gaat groeien, zoals gebruikers, downloads, feedback, etc.

Die vraag zal alleen positief beantwoord kunnen worden als: CiPHER en Jason actief meldingen gaan opvolgen en uitsturen + vragen beantwoorden van users (tenzij andere dit al gedaan hebben ).

Nouja daar ben ik dus wel bang voor. Dat Jason en ik straks vooral de loopjongens zijn voor support en aan ontwikkelen nauwelijks meer toekomen. In zo'n situatie zou het best eens kunnen zijn dat Jason en/of ik afhaken. Daarom is uitdrukkelijk de wens om een infrastructuur op te zetten zodat gebruikers elkaar kunnen helpen. Dan kunnen Jason en overige ontwikkelaars zich richten op datgene waar ze goed in zijn.

zaterdag 4 januari 2014 22:55

Acties:

0 Henk 'm!

EnerQi

Kortom, de versienummering klopt niet helemaal. Maar je zult ook zien dat in 2014 de web-interface veel releases zal kennen. Dan denken jullie dat de ontwikkeling opeens weer heel snel gaat, terwijl in de praktijk dat helemaal niet zo is; het lijkt alleen zo.

het lijkt inderdaad zo traag te gaan. Wij gebruikers zien het onvoldoende

. Hetgeen wat eigenlijk ook gecommuniceerd mag worden. Het komt nu niet echt uit de verf in die topics van Jason. Overigens ken ik ZFSguru pas sinds beta 5 denk ik

Nouja daar ben ik dus wel bang voor. Dat Jason en ik straks vooral de loopjongens zijn voor support en aan ontwikkelen nauwelijks meer toekomen. In zo'n situatie zou het best eens kunnen zijn dat Jason en/of ik afhaken. Daarom is uitdrukkelijk de wens om een infrastructuur op te zetten zodat gebruikers elkaar kunnen helpen. Dan kunnen Jason en overige ontwikkelaars zich richten op datgene waar ze goed in zijn.

HA! De zere plek

. Nee uiteindelijk moeten jullie je daar niet mee bemoeien of zelfs antwoord geven (uiteindelijk hè ). Daarom hebben de gebruikers een andere informatiebron nodig zodat ze geen vragen hoeven te stellen. Wiki kan hierbij helpen, net als de bugtracker en ingame help* (intern zfsguru help?). Meer ideeën hierover heb ik helaas niet maar teksten kunnen ook door andere mensen geschreven worden in tig verschillende talen. Beta 9 is belangrijk maar die zere plek gaat straks etteren

. Zeker als het aantal gebruikers toeneemt.

Het enige wat je krijgt op het forum zouden features requests (veel! wegens enthousiasme) moeten zijn waarop je antwoord moet/mag geven. De roadmap maakt veel duidelijk maar zou van meer detail mogen voorzien. Misschien beter van een detaillering van de volgende versie (0.3) naar vage 1.0 (wat wil je als hoofddoel eigenlijk in 1.0 hebben). De datums zou ik bewust weglaten, gezien de historie van ZFSguru maar communiceer meer.

Nieuwe start in welke zin, wat zou er moeten veranderen?

Ook zoals hierboven aangegeven, de "ruzie/discussie" die we nu hebben zou dan over moeten zijn.

* ingame help wegens gebrek aan betere bewoording.

zaterdag 4 januari 2014 23:36

Acties:

0 Henk 'm!

syl765

zijn de wensen dan voltooid

Nee er zijn altijd wensen.

Wat in mijn ogen belangrijk is is dat een knop in de gui ook werkt.
Tevens dient de basis solide te zijn. Als basis van zfsguru zie ik toch het fileserver gedeelte als hoofdmoot, inclusief wat geavanceerde netwerk instellingen zoals LACP enz.
Dus samba, nfs en een duidelijke installer. Heb je dat op orde, dan kun je gaan werken aan de services.
Wat ook belangrijk is zijn toch de monitor functionaliteiten zoals een zabbix, of nagios client. Zeker de zakelijke gebruikers willen graag dit soort zaken op orde hebben.

De meeste gebruikers zullen zfsguru toch als fileserver gaan inzetten en niet als werkstation.
Dan noemde je nog wat jullie allemaal zouden willen toevoegen aan zfsguru.
Webserver, mailserver, firewall enz. Ik denk persoonlijk dat je dit niet te veel moet doortrekken.
Een firewall is een project op zich kijk maar eens naar pfsense, is al jaren bezig en nog steeds niet af. En een firewall hoort naar mijn idee niet op je fileserver (buiten wat lokaal filteren) maar gewoon tussen je WAN en LAN te zitten.

Misschien is het wel een mooi idee om bijvoorbeeld een web of mailserver als bhyve machine te kunnen starten op je basis zfsguru machine. Zo houd je de geinstalleerde zfsguru mooi schoon en draaien die andere machines op de bhyve hypervisor.

Gr

zaterdag 4 januari 2014 23:46

Acties:

0 Henk 'm!

Anoniem: 15758

Topicstarter

EnerQi schreef op zaterdag 04 januari 2014 @ 22:55:
het lijkt inderdaad zo traag te gaan. Wij gebruikers zien het onvoldoende . Hetgeen wat eigenlijk ook gecommuniceerd mag worden. Het komt nu niet echt uit de verf in die topics van Jason. Overigens ken ik ZFSguru pas sinds beta 5 denk ik .

Zou je voor de gein een oude ZFSguru 0.2-beta5 moeten downloaden en dat eens met beta9 vergelijken straks.

Over dat op de hoogte houden, de nieuwe website waar ideeën over zijn (rustig maar.. rustig maar.. geen zesjarenplan...

) zou ook een timeline bevatten, waar alle major features in te vinden zijn, zowel in het verleden als de toekomst. Zo kun je heel duidelijk zien wat al is geweest en wat nog komen gaat. Evenals kun je afhankelijk van de resultaten in het verleden als gebruiker ook beter inschatten wanneer iets er komt. Als alle releases 2 maanden later komen dan gepland, dan zal dat voor de komende release ook zo kunnen zijn. Zo'n tijdlijn is ook minder gevoelig voor veroudering.

Want de roadmap is leuk, waarin Jason naar 0.2 wilde spurten.. Maar in de praktijk werkt dat niet. De doelen voor 0.2 worden opgerekt en er komen allerlei dingen in ZFSguru die eigenlijk pas na 0.2 zouden komen. De service infrastructuur om maar wat te noemen, zou eigenlijk 0.3 geweest zijn. Dat is al gedaan, en zo zijn er meer dingen.

Voor mijn gevoel gaat ZFSguru pas echt beginnen na de 0.2 release.

HA! De zere plek . Nee uiteindelijk moeten jullie je daar niet mee bemoeien of zelfs antwoord geven (uiteindelijk hè ). Daarom hebben de gebruikers een andere informatiebron nodig zodat ze geen vragen hoeven te stellen. Wiki kan hierbij helpen, net als de bugtracker en ingame help* (intern zfsguru help?). Meer ideeën hierover heb ik helaas niet maar teksten kunnen ook door andere mensen geschreven worden in tig verschillende talen. Beta 9 is belangrijk maar die zere plek gaat straks etteren . Zeker als het aantal gebruikers toeneemt.

Daarom is het al te belangrijk om straks als ZFSguru een groter aantal gebruikers kent, om dan alle infrastructuur voor support gereed te hebben. Dus die in-game support zoals je dat zo leuk noemt (klopt gewoon, behalve dan dat het geen game is) is wel heel belangrijk.

Het enige wat je krijgt op het forum zouden features requests (veel! wegens enthousiasme) moeten zijn waarop je antwoord moet/mag geven.

Dat is juist hartstikke leuk!

Maar altijd maar weer die bugs in apps oplossen is minder leuk. Vooral apps die je zelf nooit gebruikt hebt. Dat is niet de toekomst van ZFSguru, hoop ik dan.

De roadmap maakt veel duidelijk maar zou van meer detail mogen voorzien. Misschien beter van een detaillering van de volgende versie (0.3) naar vage 1.0 (wat wil je als hoofddoel eigenlijk in 1.0 hebben). De datums zou ik bewust weglaten, gezien de historie van ZFSguru maar communiceer meer.

Daar was Jason volgens mij een tijd terug ook wel mee bezig, een tijdlijn met features die dan drag en drop geordered konden worden. Verder heel simpel. Maar wel leuk zowel als dev als gebruiker.

Idee was globaal dat 1.0 een 'af' product zou zijn, misschien nog niet in volle glorie maar alle basisfunctionaliteit moet dan echt af zijn, inclusief 'in-game support'.

In de praktijk kun je het zien als:
0.2 beta9 : samba & NFS rewrite
0.2 beta10: guruDB
0.2 beta11: Migration Manager
0.2 RC/final: bugfixes
0.3: networking (interfaces, static IP, Jumbo Frames, Link aggregation, Firewall, DNS, DHCP, TFTP, PXE)
0.4: Embedded distribution (op USB-stick) met behoud van servicedata; 100% Root-on-RAM.
0.5: Task Manager (nodig voor periodic acties en zaken op de achtergrond)
0.6: Guru Accounts (geïntegreerd in de GUI)
0.7: Community services ('in-game help')
0.8: Vertalingen
..
1.0: final release

Vanaf versie één wilde Jason de suffix laten valen, dus krijgen we Firefox-style gewoon versie 2, 3, 4, 5, enzoovoorts. Alleen bugfix releases kunnen dan 2.1 worden enzovoort.

Noot: overzicht hierboven is maar uit mijn hoofd en het gaat in de praktijk altijd anders, dus het kan zijn dat de 0.5 vóór de 0.4 komt enzovoorts.

Ook zoals hierboven aangegeven, de "ruzie/discussie" die we nu hebben zou dan over moeten zijn.

Nouja wat ik jammer vind is dat ik niet iedereen heb kunnen overtuigen dat ze wel degelijk serieus genomen worden. Maar misschien kan dat nog komen. Mijn bedoeling is om alle feedback uit dit topic te verzamelen en concrete punten ook uit te werken, dan na een tijd de balans opmaken wat er van terecht gekomen is. Want dat drie maanden afwachten kan ik begrijpen dat sommigen daar moedeloos worden. Het kan zeker een tandje sneller. Dus stel volgende week draait de wiki en FireDrunk of een ander kan een bugtracker leveren, dan hebben we toch al wat bereikt. Maar ik hoop ook dat jullie een beetje gerust gesteld zijn dat we niet met nutteloze dingen bezig zijn ('zijwegen') maar wel degelijk de belangrijke dingen doen die nodig zijn voor morgen. Jullie hebben ons duidelijk gemaakt dat de community nu ook wat te bikken wilt hebben; prima!

zondag 5 januari 2014 00:41

Acties:

0 Henk 'm!

base_

De bijdragers hebben het volgende nodig:
- Alle code ergens op internet zodat meewerken mogelijk en makkelijk is (bijv. github).
- Een plek om over code te discussiëren en vragen te stellen (bijv. github).
- Een bugtracker waarop technische problemen gemeld kunnen worden en eventueel opgelost door andere uit deze groep.
- Een beschrijving van de eventuele API of logica van de code (kan eventueel ook door mensen uit deze groep geschreven worden).

Helemaal mee eens,
bugtracker evt ook github?
Ik heb nog steeds geen goed argument gezien om e.e.a. niet op github te zetten? (of zie ik iets over het hoofd? Bij geen/weinig ervaring met Git kan ik in ieder geval wel zeggen dat het even wennen is en je er daarna niet meer vanaf wilt

)
Discussie kan op een willekeurige plek/forum.

Pagina: 1 2 ... 10 Volgende Laatste

Reageer

Onderwerpen

Punt 1: de voortgang van de Web-interface gaat te traag

Punt 2: in beta8 zitten bugs zoals het niet kunnen toevoegen van slog.

Punt 3: de communicatie verloopt stroef en de website is verouderd.

Punt 4: de richting van ontwikkeling is onduidelijk, verkeerd of roept vragen op.

Punt 5: de ontwikkeling wordt gedomineerd door Jason en anderen hebben geen inbreng.

Punt 6: hulp wordt niet gewaardeerd.

De conclusie (2 februari 2014)

Het Oude Testament

Het Nieuwe Testament

Link naar Wiki

Link naar Bugtracker

Link naar Repository