Discussie over de toekomst van ZFSguru

[Verwijderd]

Ik eigenlijk ook.

Want hoe reageer je op goede ideeën waar totaal geen tijd of resources voor beschikbaar zijn. Wat jij voorstelt is het service-architectuur totaal omspitten en alle build scripts aanpassen aan een ander ontwerp. Dat is ongeveer een half jaar werk voordat het goed werkt; minimaal een paar maanden.

Hoe verfrissend je ideeën zijn, des te slechter komt het uit. Ik ben de afgelopen maanden bezig geweest met GitLab en de server infrastructuur. Dat is nog niet af of er komt alweer een ander iets groots op me af. Bovendien met weinig concrete voordelen. Het is iets netter dan de structuur die nu wordt gebruikt, maar kent ook nadelen. Zo krijg je de conflicten met packages van FreeBSD zelf die met andere opties zijn gecompileerd, en met andere make variabelen en kernel - zoals voor de KMS/NEWXORG systeemversies geldt.

Dat wil niet zeggen dat er geen opvolger komt van de huidige structuur. En hetgeen je aanbiedt is zeker iets wat een goede start zou kunnen zijn voor zo'n opvolger. Maar wie gaat dat doen?

Daarom mijn voorstel; zou jij het zien zitten om van de zomer hier aan te werken? Alle build infrastructuur herschrijven naar het nieuwe systeem, etc? Als jij bereid bent er serieus werk van te maken, dan wil ik best met Jason om de tafel. Mocht dat niet het geval zijn, dan zou jouw voorstel in de praktijk betekenen dat ZFSguru project een half jaar opschuift, zonder enig concreet resultaat voor de eindgebruiker. Daar ben ik geen voorstander van. Er zijn veel zaken die meer prioriteit hebben dan de motorkap nog eens af te stoffen met een andere packagestructuur. De voordelen zijn voor de doorsnee ZFSguru-gebruiker vrijwel afwezig, terwijl er wel nadelen bijkomen. Het heeft vooral voordelen voor de geavanceerde gebruiker die BSD goed kent en ZFSguru als BSD wilt gebruiken met alleen een web-interface erbij. Die groep is echter niet heel groot, ZFSguru heeft juist de eerste groep als primaire doelgroep. Die hebben weinig tot geen baat bij wat je voorstelt. Die gaan sowieso geen command line gebruiken.

Dus ja, hoe moet ik hier op reageren? Aan de ene kant vind ik het heel leuk dat je interesse toont in ZFSguru en verbeteringen voorstelt. Aan de andere kant ben ik bang dat de zo kostbare energie in de verkeerde dingen gaat zitten. We kunnen het ons niet verloven om in 2014 ZFSguru stil te laten staan - er ligt teveel op de plank wat eerst af moet. Er is in januari al gekozen voor een grote omleiding met developer website. Dat kostte ook heel veel tijd wat ten koste ging van andere development. Zo zit het leven in elkaar, kies je voor A dan gaat dat ten koste van B.

Als jij zin hebt om tegen de tijd dat ZFSguru daar klaar voor is (gitlab, licentie, infrastructuur) een belangrijke bijdrage te doen aan het redesignen van de service-infrastructuur, dan wil ik best met Jason om de tafel om dat mogelijk te maken. Maar als dat niet het geval is, dan heb ik de keuze tussen mooie dingen opgeven om jouw idee te verwezenlijken of om jouw idee voorlopig te laten varen. Beide vind ik niet ideaal.

Dus wat nu?

[CurlyMo]

Want hoe reageer je op goede ideeën waar totaal geen tijd of resources voor beschikbaar zijn. Wat jij voorstelt is het service-architectuur totaal omspitten en alle build scripts aanpassen aan een ander ontwerp. Dat is ongeveer een half jaar werk voordat het goed werkt; minimaal een paar maanden.

Dat valt reuze mee. In vrijwel alle gevallen zal het gewoon knippen en plakken zijn van de logica in de service_* scripts naar de pkgNG pkg-deinstall en pkg-install scripts. Daarnaast nog even een goeie +MANIFEST maken.

Een tweede optie is oude pakketten laten voor wat ze zijn en alleen nieuwe pakketten goed oppakken.

Zo krijg je de conflicten met packages van FreeBSD zelf die met andere opties zijn gecompileerd, en met andere make variabelen en kernel - zoals voor de KMS/NEWXORG systeemversies geldt.

Dat is juist wat je wilt Waar ze niet op te lossen zijn lever je zelf een versie aan van het betreffende pakket.

Daarom mijn voorstel; zou jij het zien zitten om van de zomer hier aan te werken? Alle build infrastructuur herschrijven naar het nieuwe systeem, etc? Als jij bereid bent er serieus werk van te maken, dan wil ik best met Jason om de tafel.

Waarom ik (alleen)? Dit is opnieuw weer een prima klus wat een community kan oppakken. Als er 10 mensen aanzitten dan kan je dit in no-time klaar hebben. En zoals gezegd, het stelt maar weinig voor.

Mijn doel was vooral om je te laten zien dat jullie services systeem echt ontzettend onhandig en omslachtig is. Hoe sneller je het dus goed kan gaan doen hoe beter. Ik denk dat er hier genoeg zijn die wel mee willen helpen als jullie maar voor de infrastructuur zorgen.

Mijn suggesties:
- Ga nieuwe pakketten in een native pkgNG systeem maken.
- Laat de community de laatste versies van huidige pakketten omzetten. Services gemaakt voor FreeBSD versies zonder pkgNG heeft toch geen zin.
- Zorg voor een server waarop nieuwe pakketten geplaatst kunnen worden en daarna door een groep gebruikers kunnen worden geverifieerd op werkzaamheid. XBian heeft drie soorten repositories:
1. Development
2. Staging
3. Stable
Als wij als community dus pakketten langzaam aan in development kunnen zetten, dan kunnen gebruikers en mede ontwikkelaars ze testen en zodra er bijv. 5 mensen zijn die de werking hebben geverifieerd, dan kan het naar staging of stable.

Zo kan dus de huidige ontwikkeling doorgaan en daar parallel aan het omzetten van huidige services gezet worden. Aan jullie dus om de infrastructuur op te zetten.

PS. als je ook mijn samba versie wil hebben om aan Jason te laten zien, dan geef maar een gil.

[Verwijderd]

Wat je zegt over het aanpassen van de services zelf is maar een deel van het verhaal. De build infrastructuur en web-interface moeten ook aangepast worden.

Ook zijn er nog veel open eindjes. Bijvoorbeeld, de huidige services worden niet in een absoluut pad zoals /usr/lib/zfsguru geinstalleerd, maar in een eigen filesystem die op de boot pool is opgeslagen. De locatie hiervan hangt af van de poolnaam en systeemversie, zoals /bootpool/zfsguru/services/10.0-002/virtualbox.

Door de vele wijzigingen zie ik dit eerder iets voor volgend jaar, zodat dit jaar veel meer aandacht kan uitgaan naar het op orde krijgen van:
1) website, inclusief de nieuwe development website en nieuw forum
2) web-interface, 0.2 final moet de deur uit. Migration manager erin en wat RC's en klaar.
3) Geautomatiseerde builds, zodat de officiële server vrij autonoom services kan bouwen en automatisch de GuruDB database kan aanpassen.

Dat vind ik zelf veel coolere features waar de gebruikers veel meer baat bij hebben op korte termijn.

Want wat zijn nu precies de voordelen van een all-pkgNG systeem wat je voorstelt?

Mijn doel was vooral om je te laten zien dat jullie services systeem echt ontzettend onhandig en omslachtig is. Hoe sneller je het dus goed kan gaan doen hoe beter.

Ik wil niet teveel de oude discussie oprakelen. Maar kun je aan een gebruiker vertellen wat dit voor hen gaat opleveren zodra al het werk achter de rug is?

Waarom ik (alleen)? Dit is opnieuw weer een prima klus wat een community kan oppakken. Als er 10 mensen aanzitten dan kan je dit in no-time klaar hebben.

Daarvoor is het wel fijn als de development infrastructuur up and running is. Dus ook hier is mijn argument dat je voorstel toch iets te vroeg komt. Tenzij je er zelf flink achter wilt zitten. Maar ik denk nu al zeker te weten dat je toch redelijk onderschat wat voor werk het allemaal teweegbrengt. Om dit dan zo op korte termijn te doen terwijl gebruikers zichtbare verbeteringen verlangen aan ZFSguru, kan ik niet verantwoorden. Op langere termijn misschien wel.

Zodra de development site open is voor registratie, kan iedereen vrijwel overal aan werken. Dus vanaf dat moment zou het werk kunnen beginnen. Maar het zal denk ik nog vele maanden duren voordat het iets bruikbaars oplevert voor het grote publiek, zelfs al werken er meerdere mensen aan mee. Het omzetten van oude stijl ZFSguru services naar nieuwe stijl ZFSguru services zie ik inderdaad wel goed komen. Maar de remote database structuur, de scripts, de build infrastructuur dat is denk ik taaier dan het omzetten van de services.

Wat ik eigenlijk meer voorstel is een poll op de ZFSguru site, waar de gebruikers zich na beta10 kunnen uitspreken over welke dingen prioriteit moeten krijgen. Want dit is wel precies het issue - dat ZFSguru geen FreeNAS is. Daar kun je alles mooi goed geprogrammeerd en gestructureerd hebben, en toch een onbruikbaar product voor de eindgebruiker. Dat wilde ZFSguru juist anders doen, met heel andere prioriteiten.

Zodra er inderdaad veel parallele development plaats kan vinden, wordt dit minder een issue. Maar Jason en ik hebben hun handen vol aan de huidige zaken en kunnen een groot iets op dit moment niet goed gebruiken. Als GitLab registratie open is, praten we verder. Dan kun je daar je bug/issue aanmaken en gaat het zijn eigen weg. Maar nu denk ik dat het beter is om te focusen op de huidige issues.

En over GitLab gesproken.... ik kan wel wat hulp gebruiken om die irritante Can't verify CSRF token authenticity-bug op te lossen. GitLab is beschikbaar als service, dus je kunt het zelf uitproberen. Ik heb ook een .iso LiveCD beschikbaar.

[CurlyMo]

Ik vind het prima als het op je lijstje komt van te verbeteren dingen van ZFSguru. Dit was een onderdeel van de discussie die ik n.a.v. dit topic voer over elke uithoek van ZFSguru. Dat is volgens mij (opnieuw) gelukt. Ik heb er iig geen haast bij.

Als je hulp wil bij gitlab dan mag je me toegang geven tot de dev server. Dan wil ik best eens kijken.

Nog even je vraag:

Want wat zijn nu precies de voordelen van een all-pkgNG systeem wat je voorstelt?

Al vaker gezegd. Dat je niet zelf het wiel opnieuw probeert uit te vinden en naadloos aansluit op de BSD infrastructuur. Jij noemde dat Appliance vs System.

Maar kun je aan een gebruiker vertellen wat dit voor hen gaat opleveren zodra al het werk achter de rug is?

Dat heb ik met mijn voorbeelden laten zien. Een paar voordelen op een rij.
1. ZFSguru wordt upgradeable zonder herinstallatie.
2. ZFSguru regelt welke pakketten ZFSguru aanlevert en welke dus van de FreeBSD geblokkeerd moeten worden. Bijv. mijn samba versie blokkeert de installatie van de FreeBSD versie van samba. FreeBSD gaat dus ook rekening moeten houden met ZFSguru pakketten i.p.v. alleen andersom.
3. ZFSguru kan zelf een pakket worden die je in FreeBSD kunt installeren.
4. De community kan veel makkelijker pakketten toevoegen.
5. pkgNG wordt onderhouden door meer capabele ontwikkelaars.
6. Het verlaagt bandbreedte doordat je je dependencies van de FreeBSD servers kan laten downloaden.
7. Geavanceerdere gebruikers kunnen via de CLI handmatig ZFSguru pakketten installeren en bijwerken. Hierdoor is tevens een herinstallatie makkelijker te automatiseren.
8. Pakketten worden gelimiteerd op systeem versie door BSD zelf, dus niet door jullie eigen scripts. Dus geen virtualbox installeren op FreeBSD 9 terwijl een bepaalde versie alleen op FreeBSD 10 werkt.
9. Makkelijker meerdere versies van pakketten kunnen onderhouden (dev, staging, stable) zodat je zelf bepaald welk risico je wilt nemen en jullie meer feedback voordat pakketten de massa bereiken.
10. pkgNG tracked alle bestanden die bij een pakket horen wat het (per ongeluk) overschrijven voorkomt en het makkelijker te verwijderen maakt.

[ Voor 8% gewijzigd door CurlyMo op 17-04-2014 20:37 ]

[Dutch2007]

iets naar een maandje bumpje, is er ondertussen nu het toch alweer juni is Meer info over de status van de development van ZFSGuru?

Zowel hier op GoT als op jullie eigen forum kan ik eigenlijk he-le-maal niets qua status update vinden...

Het is momenteel maar "gissen" wat er onderwater gebeurd...

[fluppie007]

Bumpje 2 ;-)

[Verwijderd]

Ah, nou jullie timing is niet verkeerd. Jason en ik zijn bezig met de 'State of the Project' voor 2014. Daarin zullen we veel vertellen over de toekomst van ZFSguru, en iets groots onthullen wat bijna af is.

Duurt nog wel een week of wat.

[FireDrunk]

Nog meer groots en nog meer nieuws?

Damn, zo komen de huidige features toch nooit af

[Verwijderd]

We zijn er al lang mee bezig. En het is bijna af. En zeker wel een core 'feature' voor het project.

[Verwijderd]

Heren, Dames,

Dit topic is niet bedoeld als algemeen ZFSguru vragen topic. Vragen of discussies over hardware hoort hier absoluut niet thuis, maar in plaats daarvan in het DIY RAID NAS topic en/of ZFS topic. Dit topic is speciaal bedoeld om de toekomst van ZFSguru te bespreken. Ik wil het topic vrij houden van andere posts zodat het geen ZFSguru helpdesk-topic wordt, maar ook dat het lekker rustig blijft totdat er ook echt nieuws is over ZFSguru. Recente posts in dit topic zijn niet conform deze indeling en ik wil jullie vragen om dit topic enkel te gebruiken voor het doel: Discussie over de toekomst van ZFSguru.

Alvast dank voor jullie medewerking.

[mcied]

Is er al weer nieuws? de week is ook allang weer verstreken

[Dutch2007]

yup, zag ook al een post van jason dat d'r soon (tm), lijkt ccp wel , een update zou komen ik wacht gespannen af .

Hoop dat het wachten de moeite waard gaat worden ;-)

[Mystic Spirit]

Ik ben ook zeer benieuwd! Ik ben van ZFSguru naar FreeNAS gegaan en wil eigenlijk wel weer terug vanwege het gebruiksgemak van ZFSguru. Kom dus maar door met nieuwe release

[EnerQi]

Dutch2007 schreef op woensdag 02 juli 2014 @ 22:03:
yup, zag ook al een post van jason dat d'r soon (tm), lijkt ccp wel , een update zou komen ik wacht gespannen af .

Hoop dat het wachten de moeite waard gaat worden ;-)

Alleen was die post van Jason op 9 mei.... Dat is nu al bijna 2 maanden geleden! Communiceren doen ze nog steeds niet goed ;-). Misschien hebben ze de afgelopen paar weken wel naar het WK gekeken

http://zfsguru.com/forum/zfsgurudevelopment/798.1

[Verwijderd]

De forum post die Jason wilde schrijven is uitgegroeid tot een State of the Project met een uitgebreide kijk op de toekomst van het project. En ik heb er ook aan meegeschreven. Ik zie dat Jason nog steeds aan het editen is. Maar het zal niet lang meer duren.

Om de spanning niet te hoog te laten oplopen: verwacht niet opeens dat ZFSguru 6.0 uitkomt ofzo. Maar het is wel een mooi overzicht waar het project naartoe gaat en welke vorderingen er zijn gemaakt, en een overzicht van goodies die te wachten staan.

Kan al vast zeggen dat door de ontwikkelingen en gekozen koers het project serieuzer wordt. Dat het nu op zijn gat ligt is niet zo erg; wat wel belangrijk is dat er gewerkt wordt aan een stabiele basis voor de toekomst van ZFSguru. Iets waar ik zelf ook graag aan blijf werken, omdat ik het uitdagend blijf vinden en veel potentie zie bij de gekozen koers van ZFSguru. En hopelijk ook de gebruikers die zien dat het project na wat haperingen wel belangrijke vooruitgang boekt.

[Verwijderd]

*** Update ***

Jason en ik hebben een nieuwe State of the Project geschreven voor het jaar 2014, en deze is nu te lezen:

• State of the Project [2014]

Het heeft even geduurd, dat wel, maar dan heb je ook wat.

Reacties op hetgeen geschreven is, zijn welkom!

[ Voor 5% gewijzigd door Verwijderd op 17-07-2014 04:33 ]

[FireDrunk]

Ik lees eigenlijk nog steeds weinig concreets, maar ik zal wel weer de boeman zijn...

Enige lichtpuntje: Er komt een Git repo! ..........ooit......Yay...

[ Voor 7% gewijzigd door FireDrunk op 17-07-2014 11:23 ]

[Verwijderd]

Niet zeuren, FireDrunk

Dat er geen ZFSguru 6.0 zou worden uitgebracht, had ik al voor gewaarschuwd. Maar de vorderingen die zijn geboekt met de build infrastructuur zijn zeker noemenswaardig. Als wij straks elke week of zelfs om de paar dagen in een handomdraai een nieuwe systeemversie kunnen produceren, is dat zeker een grote stap voor het project!

Bovendien kan ik me herinneren dat juist jij de frequentie van systeemversies veel te laag vond. Nu daar verandering in komt, is dat toch positief nieuws?

Vorderingen in de web-interface zijn leuk, maar zijn eenmalig. Als het project periodieke systeemversies van de band kan laten rollen, zal dat veel mensen blij kunnen maken. Samen met de migration manager wordt het dan heel fijn om de juiste systeemversie te draaien. Bugfixes in services of problemen met bepaalde systeemversies kun je dan oplossen door even een andere systeemversie te pakken. Door de hoge frequentie van systeem releases, hoef je dan ook niet meer te kloten met handmatig updaten van OS of packages enzovoorts. Wat mij betreft dus een grote vooruitgang.

Bedenk dat FreeBSD zelf ook meer dan een jaar nodig had om de package build cluster te bouwen. Nu hebben zij wel meer ports om te builden, maar dat ZFSguru een equivalent krijgt mag toch wel als mijlpaal gezien worden, vind ik.

[FireDrunk]

tbqfh, eerst zien, dan geloven. Dit soort beloftes hoor ik al jaren...

[roy.jacobs]

Ik ben benieuwd, alternatieven voor FreeNAS blijven welkom.

Maar dat ik nog steeds de focus van het project niet echt heel helder vind ben ik met FD eens. Van alle dingen die er nog moeten gebeuren worden Animated Splash Screens genoemd als iets waar aan gewerkt moet gaan worden?

[Verwijderd]

Dat zijn dingen waar het FreeBSD project aan werkt - animated splash screens die werken op de nieuwe KMS-drivers en vt-system console driver. Het is een Google 'Summer of Code' project, zie hier:

http://wiki.freebsd.org/SummerOfCode2014/Bootsplash

[CurlyMo]

Zie mijn git repo voor een animated splash.

Ik reageer later op de state...

[fluppie007]

Ik hoopte eigenlijk ook op een release planning. Wanneer we wat mogen verwachten etc... Komt die er nog?

[FireDrunk]

Ik denk dat de planning is, (en blijft).

It's done, when it's done.

[syl765]

Er stond nog wel een stukje in het kwartaal mailtje van FreeBSD over ZFSguru

http://www.freebsd.org/ne...port-2014-04-2014-06.html

ZFSguru

URL: http://zfsguru.com
URL: http://zfsguru.com/news/stateoftheproject/2014

Contact: Jason Edwards <[e-mail]>

ZFSguru is a multifunctional server appliance with a strong emphasis on storage. ZFSguru began as simple web-interface frontend to ZFS, but has since grown into a FreeBSD derivative with its own infrastructure. The scope of the project has also grown with the inclusion of add-on packages that add functionality beyond the traditional NAS functionality found in similar product like FreeNAS and NAS4Free. ZFSguru aims to be a true multifunctional server appliance that is extremely easy to setup and can unite both novice and more experienced users in a single user interface. The modular nature of the project combats the danger of bloat, whilst still allowing extended functionality to be easily deployed.

Where development in the first quarter of this year brought drag-and-drop permissions for Samba and NFS, development in the second quarter focused on strengthening the infrastructure of the project. A new library and toolkit solution dubbed 'Mesa' is in the works, providing a cleaner foundation to the project. A new master server providing secure remote services is being setup, to be located in a high-speed datacenter. But most importantly, a new system build infrastructure has shown great progress and will soon be able to provide automated system builds to our users. This not only improves the frequency of system releases but also frees much developer time to be spent on different areas of the project.

Furthermore, a new website and forum is being worked on, replacing the old-fashioned website that offers only limited functionality. The new website will be linked to the server database, providing real-time updates about the project.

In addition, a new platform for collaborative development is in the works. A service addon has been created for the GitLab project, which is a drop-in replacement of the popular GitHub website. The choice was made to host our own solution and not rely on GitHub itself. In retrospect this appears to be a good decision. The recent development where GitHub removed projects after DCMA takedowns being sent is incompatible with the philosophy of free-flow-of-information, which the ZFSguru project is a strong proponent of. By hosting our own solution, we have avoided any dependency on third party projects.

It is expected that after the infrastructure of the project has been revamped, work on the web-interface itself can continue. New functionality such as GuruDB and Service Bulletins provide a tighter connection between the server infrastructure and the web-interface. The Migration Manager is one of the last remaining features still missing in the web-interface. This functionality provides an easy way to upgrade the current system by performing a new clean installation, but migrate all relevant configuration to the new installation. It also allows to backup all system configuration in a single file to be stored on a different machine should things go awry.

A longer version of this status report giving a wider perspective on the project can be found at the stateoftheproject link.

[Verwijderd]

In het bijzonder het stukje over GitHub is interessant.

[dylanvana]

Dat is best knap van jullie Nu hopen dat de ontwikkeling een beetje meezit!

[ikkeenjij36]

Wij wachten allen in spanning af .
2014 is nog lang he
Maar tot nu gewoon als beginneling best tevreden

[ Voor 31% gewijzigd door ikkeenjij36 op 25-07-2014 16:25 ]

[MvL]

Hoi,

Mijn aandacht tot ZFSguru werd getrokken door het Asus bordje met de SAS poorten in het DIY NAS topic. Ik overweeg mijn Synology te verkopen en iets te laten bouwen met dat bordje. Ik heb nog een 16 hoswap rackmount case in mijn schuur liggen.

Ik heb development van ZFSguru al een tijdje niet meer gevolgd. Ik heb wel wat getest met ZFSguru in de begin dagen. Jason Edwards was toen maanden niet online en had persoonlijke problemen. Ik heb hem nog een beetje proberen op te beuren in een forum post. Uiteindelijk heb ik voor een Synology oplossing gekozen.

Gisteren heb ik Jason gemaild voor een password recovery. Een beetje 1980 dat het niet via het forum kan en dat ik hiervoor Jason voor moet storen.

Sorry dat ik wat offtopic informatie hier achter laat...

De opening post is zeer helder. Ik ga vanavond deze thread nog wat verder doorspitten op mijn iPad.

Ik hoop echt dat jullie wat meer communiceren met de community wat er nu speelt en wat de volgende stappen zijn. Ik heb met belangstelling "State of the Project 2014" gelezen. ZFSguru kan een awesome oplossing voor storage worden tenminste dat is mijn mening.

In mijn vakantie wil ik wat gaan testen met ZFSguru. Ik wil dit met Virtualbox doen. Mocht ik besluiten ZFSguru te gaan gebruiken wil ik ook wel de community helpen.

[Verwijderd]

MvL, de huidige manier om passwords te resetten is om handmatig SQL queries naar de master server te doen. Dat betekent 3x inloggen voor Jason en handmatig een checksum maken van het nieuwe wachtwoord, de userid opzoeken enzovoorts. Enorm omslachtig. Eenvoudig gezegd heeft hij echt geen zin in password resets.

Al die problemen zijn ook verleden tijd zodra de nieuwe website er is. Dus maak een nieuw account aan en later kun je eventueel hem wel aan zijn mouw trekken, of mijzelf want dan kan het gewoon via de forum admin GUI.

Er zijn ook genoeg manieren om mee te helpen; binnenkort althans. Met de nieuwe infrastructuur. Pas dan wordt het haalbaar om met meerdere mensen aan ZFSguru te werken; waarbij je ook echt dingen kunt doen.

En dat is misschien wel waar 2014 voor staat: het project een echte toekomst geven. Niet zozeer wat nieuwe features in de web-GUI, maar de 'infrastructuur' van het project opbeuren. En daar zijn nu al forse stappen in gemaakt.

Momenteel is Jason hard bezig met de nieuwe build infrastructuur, die automated builds mogelijk moet maken. Hopelijk kan de eerste systeemversie gemaakt met deze nieuwe manier worden vrijgegeven. Dit is een van de grootste mijlpalen die ZFSguru ooit heeft genomen. De nieuwe build infrastructuur is een project op zich. In feite maakt dit het kinderlijk eenvoudig om een BSD-derivative te bouwen. Met wat instellingen en een druk op de knop wordt alles parallel gebuild en er komen van de lopende band systeemversies, services en LiveCDs van de band rollen.

Daarna nog wat perfectioneren zodat alles ook geautomatiseerd geupload kan worden, en het project kan een nieuwe fase in wat mij betreft.

Gevolg is wel dat er voor de gebruiker in 2014 niet zo heel veel te zien is. Maar Jason vind het eigenlijk wel fijn dat het 'rustig' is binnen de community. Zodra het aantal gebruikers hard gaat stijgen, moet alles namelijk wel gereed zijn om dat op te vangen. Jason gaat echt overspannen worden als er dagelijks 10 password reset requests binnenkomen en dan nog dit en dan nog dat en ook nog de community op de hoogte houden en en en... wat blijft er dan over voor feitelijke development? Juist... dat probleem moeten we zien te voorkomen.

@CurlyMo: ik ben eigenlijk ook nog erg benieuwd naar jouw reactie? Zeker omdat je in dit topic ook actief hebt bijgedragen aan de discussie. Wat vind je van het lijstje van verbeterpunten dat in de State of the Project wordt genoemd? Is dat een goede opsomming van kritiekpunten dit in dit topic zijn behandeld?

[CurlyMo]

Zie mijn signature. Ik heb dus te maken met het opbouwen van hele andere infrastructuren

[Verwijderd]

Oh dat is flink klote....

Als je de GoT-knokploeg nodig hebt, zeg je het maar!

[CurlyMo]

Eindelijk een reactie.

Waar ik het mee eens ben:
- Easiest ZFS web-interface for novice users, many of whom have only Windows experience
- Some web-interface pages of ZFSguru are really good and easy to understand without a manual
- Installation is really easy and comes with few restrictions.
"[...] and allows a Solid State Drive to be used as boot disk, cache disk, separate ZIL and overprovisioning."
Dat is natuurlijk onzin, want het is geen feature van zfsguru, maar van FreeBSD zelf.
- Advanced users can modify their installation as they please
- Communication with the community about development progress is spotty, at best
- A lot of services are just stubs and only install packages
Meuk dus
"Some are really well designed and virtually finished, while others are stubs that only install packages."
Dat zijn ze dus niet, want anders hadden jullie het wiel niet opnieuw uitgevonden.
"These stubs should be upgraded to full-blown services with their own web-interface to accommodate the user in configuring the package."
Neeeeeeeeeeeeeee!
- The website and forum lack functionality and look old fashioned.
- There is no easy way to contribute to the project or even donate money

Waar ik het niet mee eens ben of niet belangrijk vind:
- Service addon packages are easy to install and some of them are really good.
Je kent mijn mening hierover. Ik vind het dus niks.
- Graphical services allow for optional desktop environment
Niet interressant voor een NAS. Tenzij je het een en ander virtualiseert.
- ZFSguru supports the newest (experimental) open source graphics stack
Ok, maar zie vorige punt.
- ZFSguru system releases are ahead of competition.
Ik zou dat niet zo noemen. Wanneer andere bewust niet deelnemen aan de wedstrijd, dan win je natuurlijk automatisch. Jullie kiezen vooral voor bleeding edgeness. Dat is iets anders.
- ZFSguru is still a work-in-progress
Dit is natuurlijk ook onzin. Dat is de kritiek niet. Iets is altijd te verbeteren.
- Jason's silly version scheme produced all kinds of beta releases
Boeit ook niet zo. Zie bijv. de discussie over Firefox nummering. Het probleem is juist wat versie nummers reflecteren. Wat is de roadmap die achter een nummering ligt?
- System images could be more frequent and have more information attached to them
Dit hangt er vanaf hoe je nieuwe images aanbied. Wanneer je met rolling releases werkt dan is dit helemaal geen issue.

De toekomst:

- Advanced build infrastructure
Mooi. Het geautomatiseerd bouwen van een OS is naar mijn idee the-way-to-go.
- Mesa modular framework
Onbekend voor mij
- New website, new forum
Doe a.u.b. niet te moeilijk. Er zijn zat standaard oplossingen die prima voldoen.
- GitLab development website
Zie hierboven. Leuk, maar een normaal github account was ook voldoende geweest.
- Server infrastructure: new Alpha master server
Op 1000 en 1 manieren ook gratis te regelen. Denk aan sourceforge of sponsoring. pilight draait ook compleet op een gesponserde dedicated server.

Conclusie:
Veel dingen hebben ik en anderen al vaak gezegd. Vind niet voor alles zelf het wiel uit*.
- Gitlab is leuk, maar github werkt prima.
- Eigen server is leuk, maar sourceforge werkt prima.
- Zelf een website bouwen is leuk, maar wordpress, simple, drupal etc. werken prima. Idem voor mybb of phpbb.
enz enz.

Voor mij blijven de belangrijkste punten:
- Open source maken van ZFSGuru en inherent hieraan het volgende punt:
- Mogelijkheden creëren voor code contributies / revisies.
- Geef de community meer 'macht'.
- Idealiter ook zorgen dat iedereen zijn eigen ZFSGuru image kan maken.

Het belangrijkste missende onderdeel is een roadmap + planning

*Kijk voor al deze wilde plannen toch eens een keer naar de ontwikkelingsstructuur van XBian. Daar gebeurt vrijwel alles wat jullie ook willen... Beter goed gejat dan slecht bedacht.

[Verwijderd]

CurlyMo schreef op maandag 04 augustus 2014 @ 01:03:
Waar ik het mee eens ben:
"[...] and allows a Solid State Drive to be used as boot disk, cache disk, separate ZIL and overprovisioning."
Dat is natuurlijk onzin, want het is geen feature van zfsguru, maar van FreeBSD zelf.

FreeBSD is het onderliggende operating system; maar we beoordelen de appliance. Dus ZFSguru versus FreeNAS bijvoorbeeld. Daarbij geldt dat ZFSguru dingen ondersteunt en toestaat die FreeNAS niet toelaat; zoals het gebruiken van de boot/systeem disk voor storage; dat kan onder FreeNAS niet. Ook FreeNAS is gebouwd op FreeBSD, dus het onderliggende operating system kan dit wel maar de appliance kan dit niet.

Ook ZFSguru kent beperkingen. Zo ondersteunt ZFSguru geen pools op ruwe disks zonder GPT label. Dit is een bewuste beperking om user error te voorkomen; gebruikers moeten een disk of disk partitie een naam geven voordat ze die kunnen gebruiken in de ZFSguru web-interface. Indien je buiten ZFSguru om zelf al een pool hebt zonder GPT labels, dan wordt dit natuurlijk ondersteund. Maar ook hier geldt: we hebben het niet over FreeBSD features, maar over appliance features van ZFSguru/FreeNAS/NAS4Free. Dat is waar de gebruiker mee werkt. Idem voor Mac OSX wat ook op Darwin/FreeBSD is gebaseerd; daar zitten ook beperkingen op die het onderliggende operating system niet kent.

- A lot of services are just stubs and only install packages
Meuk dus
"Some are really well designed and virtually finished, while others are stubs that only install packages."
Dat zijn ze dus niet, want anders hadden jullie het wiel niet opnieuw uitgevonden.
"These stubs should be upgraded to full-blown services with their own web-interface to accommodate the user in configuring the package."
Neeeeeeeeeeeeeee!

Services die alleen packages installeren kunnen nog steeds nuttig zijn, omdat ze de gebruiker op weg helpen naar het werkend krijgen ervan. Zelf de packages compileren met de gebruikte opties kan lastig zijn; dan moet je helemaal vanaf 0 beginnen. Het installeren van de packages is zeker de helft van het werk; editen van de config files is dan een stuk makkelijker dan helemaal vanaf 0 beginnen.

Ik snap ook niet helemaal wat je bedoelt met het wiel overnieuw uitvinden in dit verband? De web-interface voor iSCSI of AppleShare bijvoorbeeld bestond nog niet en is derhalve een onmisbare aanvulling voor dergelijke services. Niet iedereen kan of wil command line config files editen zoals jij heel gewoon vindt. ZFSguru is natuurlijk ook gericht op minder technisch onderlegde gebruikers!

Waar ik het niet mee eens ben of niet belangrijk vind:
- Service addon packages are easy to install and some of them are really good.
Je kent mijn mening hierover. Ik vind het dus niks.

Dat mag, maar voor anderen is dit een van de belangrijkste argumenten om voor ZFSguru te kiezen. Je hoeft natuurlijk niet alle features van een product nuttig te vinden voor jezelf; zolang ze maar niet in de weg zitten. Bedenk ook dat juist door de service-architectuur de basis lekker licht kan blijven. Als je de services niet gebruikt is het grote voordeel natuurlijk dat alle bloat je lekker bespaard blijft. Dat voordeel noem je niet.

- Graphical services allow for optional desktop environment
Niet interressant voor een NAS. Tenzij je het een en ander virtualiseert.
- ZFSguru supports the newest (experimental) open source graphics stack
Ok, maar zie vorige punt.

Ook hier geldt dat wat jij niet gebruikt, een ander juist een prachtige feature vindt. Ook is een grafische omgeving een unieke feature voor een NAS product vergeleken met FreeNAS en NAS4Free. Hierdoor maakt het meer mogelijk qua (server-)appliaties zoals qBitTorrent en VirtualBox en vele andere services.

Ook is ZFSguru geen NAS, maar een multifunctional server appliance. Out of the box is het een NAS, wil je meer dan kun je ervan maken wat je wilt met de services, inclusief een grafische desktop. Zo kan ZFSguru ook gebruikt worden als HTPC (Xbmc, Plex, PS3MediaServer) of als virtualisatie OS met Virtualbox, Qemu en straks ook bhyve.

- ZFSguru system releases are ahead of competition.
Ik zou dat niet zo noemen. Wanneer andere bewust niet deelnemen aan de wedstrijd, dan win je natuurlijk automatisch. Jullie kiezen vooral voor bleeding edgeness. Dat is iets anders.

Ook hier is het kernpunt weer: keuze. ZFSguru biedt naast de stabiele releases ook bleeding edge releases. Wil je die niet, blijf dan bij de stable releases. Ook hier geldt weer: keuzevrijheid.

- ZFSguru is still a work-in-progress
Dit is natuurlijk ook onzin. Dat is de kritiek niet. Iets is altijd te verbeteren.

Geen onzin. De opzet en filosofie van ZFSguru komt pas goed tot zijn recht als het is uitontwikkeld op bepaalde punten. Daarbij is de Migration Manager iets wat mist in de huidige opzet van makkelijk kunnen installeren en installeren ipv een bestaand systeem upgraden en daardoor allerlei potentiele issues veroorzaken. De filosofie achter ZFSguru komt dus pas goed tot zijn recht als de missende features zijn ontwikkeld. Dat heeft niets te maken met het feit dat iets altijd wel verder te ontwikkelen valt.

- Jason's silly version scheme produced all kinds of beta releases
Boeit ook niet zo. Zie bijv. de discussie over Firefox nummering. Het probleem is juist wat versie nummers reflecteren. Wat is de roadmap die achter een nummering ligt?

Voor anderen boeide dit wel; zie ook de forum thread waarbij mensen aangeven dat ze de versies maar ingewikkeld vonden. Het idee achter de versies was dat 0.2 de eerste stable versie was klaar voor breder gebruik. Op dit moment is de migration manager nog de enige resterende feature voordat Jason het als een startpunt ziet om breder gebruikt te kunnen worden. Op de achtergrond speelt natuurlijk veel meer mee zoals serverinfrastructuur, manier om via service bulletins belangrijke informatie naar gebruikers te communiceren, nieuwe GuruDB remote database, automatische service builds, nieuwe website en ga zo maar verder. Toch zijn we al aardig dichtbij die 0.2 en vanaf dat moment is het mogelijk dat de versienummering op de schop gaat. Zo heb ik geopperd om een simpele Firefox-achtige versienummering te gebruiken.

- System images could be more frequent and have more information attached to them
Dit hangt er vanaf hoe je nieuwe images aanbied. Wanneer je met rolling releases werkt dan is dit helemaal geen issue.

Dat is tegen de filosofie van ZFSguru. Rolling releases zullen er nooit komen. Het idee is juist dat wat jij draait, anderen ook draaien. Zo kunnen bugs of problemen in een bepaalde versie bekend worden en kunnen gebruikers anderen op de hoogte stellen dat versie X een probleem heeft met zus en versie Y een probleem heeft met zo. Als niemand problemen meldt met ene bepaalde versie en toch veel in gebruik is, kan dat betekenen dat het probleem bij jouzelf moet liggen. Het makkelijk identificeren van problemen, is een belangrijke pijler onder de strategie dat iets gewoon moet werken. Vandaar ook de term appliance. Je zet het neer, drukt op de knop en het werkt. Zo niet dan knal je er een andere versie op en dan moet het wel werken. Geen gekut meer waar je wekenlang zoet mee bent. Dat zit er achter.

De toekomst:
- Advanced build infrastructure
Mooi. Het geautomatiseerd bouwen van een OS is naar mijn idee the-way-to-go.

Oh, ik kreeg anders nog +100 strafpunten van FireDrunk met dat mooie lijstje waarbij een eigen build environment de weg naar de hel was.

Maar ik ben er zelf erg blij mee, en kost veel werk maar betekent wel dat ZFSguru een stuk serieuzer wordt als er elke week of meerdere keren per week een nieuwe versie uit komt rollen.

- Mesa modular framework
Onbekend voor mij

Komt nog wel. Wellicht ook als losstaand project tegen die tijd. Dit lijkt mij het beste project voor anderen om aan mee te helpen, omdat het zo universeel is. Bovendien de meest nette code geschreven door ons.

- New website, new forum
Doe a.u.b. niet te moeilijk. Er zijn zat standaard oplossingen die prima voldoen.

Dat is ter sprake geweest. Twee argumenten voor een eigen oplossing zijn security en customization. Zo zal de website direct geïntegreerd worden met de database en community interactie. Niet de saaie statische website die het nu is; wel php maar verder 'dood' behalve het forum. Als straks geautomatiseerd een nieuwe systeemversie wordt uitgegeven, dan komt deze automatisch op de website met een lijst van services die werken voor die specifieke versie. Ook reacties van de community worden real-time verwerkt. Zo krijgt de website veel meer elan.

WordPress enzo was allang gehackt geweest, en aangezien de huidige server geen jail separation kent is dit de reden geweest voor Jason om een oud eigen misbaksel als website engine te gebruiken, totdat er iets deftigers voor in de plaats kan komen.

Ik weet dat je het hier niet mee eens bent. Maar ik kan Jason eigenlijk prima volgen in deze. Zo'n slechte keuze is het niet. Bovendien is het aanpassen van een bestaand groot project zoals WordPress ook een hele onderneming. Soms nog meer werk dan een eigen oplossing.

- GitLab development website
Zie hierboven. Leuk, maar een normaal github account was ook voldoende geweest.

In elk geval minder werk, daar heb je zeker gelijk in. Maar op langere termijn is GitLab wel stukken veiliger voor ons project. Hierbij verwijs ik ook naar het feit dat GitHub een Amerikaans commerciëel bedrijf is dat ook moet voldoen aan Amerikaanse wetgeving. Dat is dus inclusief het voldoen aan DCMA-wetgeving en onder mom van diens takedown notices zijn al diverse repositories verwijderd. Deze software maakte niet direct inbreuk op intellectueel eigendom, maar maakte dit wel mogelijk voor anderen. Dit geldt ook voor ZFSguru omdat ZFSguru zelf geen inbreuk maakt, maar anderen wel in staat stelt te doen. Dus ook ZFSguru zou verwijderd kunnen worden en zou daarmee onder Amerikaanse (terreur-)wetgeving vallen. Jason en ik zijn hier beide fel tegen gekant. De keuze voor GitLab is dus zeker zo slecht nog niet. Gewoon lekker in Europa hosten en geen gezeik meer met Amerikaanse wetgeving die in dienst staat van grote machtige bedrijven.

- Server infrastructure: new Alpha master server
Op 1000 en 1 manieren ook gratis te regelen. Denk aan sourceforge of sponsoring. pilight draait ook compleet op een gesponserde dedicated server.

Zie hierboven.

Conclusie:
Veel dingen hebben ik en anderen al vaak gezegd. Vind niet voor alles zelf het wiel uit*.
- Gitlab is leuk, maar github werkt prima.
- Eigen server is leuk, maar sourceforge werkt prima.
- Zelf een website bouwen is leuk, maar wordpress, simple, drupal etc. werken prima. Idem voor mybb of phpbb. enz enz.

Ik snap je punt. En je hebt zeker gelijk dat het ten koste gaat van kostbare development resources. Dat is denk ik het grootste nadeel en tegenargument van de keuze die wij hebben gemaakt. Maar koppig als we zijn, denken we toch de juiste afweging te maken. De toekomst zal uitwijzen of dit terecht is.

Beter goed gejat dan slecht bedacht.

Beter goed bedacht dan slecht gejat.

Ik ben niet zo onder de indruk van wat er door anderen gemaakt is, eerlijk gezegd. Dat geldt voor eigenlijk alles wat ik zie. Alles is ook gebouwd en ontwikkeld met een commercieel motief ofwel open-source maar dan ontwikkeld door autistische nerds. Wij zijn geen van beide, denk ik. Misschien is dat wel juist een kracht waar iets moois uit kan voortkomen. Ietwat arrogant klinkt het misschien wel, en we kunnen natuurlijk niet alles zelf doen. Maar hoe minder afhankelijkheid van derde partijen, des te beter.

Om maar een voorbeeld te geven: ZFSguru heeft dependencies op php5-session en php5-gd. Twee dependencies waarbij zelfs dit al problemen geeft. Zo is er een irritante bug in php5-session die bij het aanroepen van session_start(); een lege pagina geeft in zeer specifieke gevallen, zonder enige error in de logs met maximale logging. Dan voel je je toch flink genaaid. Zo'n simpele extensie, zo'n voor de hand liggende dependency, maar zelfs dit geeft al problemen.

Alles zelf maken betekent maximale controle en uiteindelijk ook maximale betrouwbaarheid. Dus ook deze dependency gaat waarschijnlijk op de schop. Het is een route die jij vast totaal niet ziet zitten, maar verschil mag er zijn toch? FreeNAS en NAS4Free zijn meer casual projecten die dingen wel doen volgens mainstream opvattingen. Laat ZFSguru dan die vreemde eend zijn die dingen anders doet. We zullen zien wie straks de beste kaarten heeft!

Ik dank je voor je feedback! Ik waardeer dat zeker, ook al zijn we het niet overal over eens is het belangrijk voor mij en voor het project om te horen van kenners zoals jij. Begrijp alleen dat wij niet zijn zoals jij bent, en dat hoeft niet direct een zwakte te zijn maar kan juist ook een kracht van vernieuwing zijn.

[CurlyMo]

Verwijderd schreef op maandag 04 augustus 2014 @ 02:49:
FreeBSD is het onderliggende operating system; maar we beoordelen de appliance.

Ok, alhoewel je dit wel erg ten voordelen van ZFSGuru uitlegt

Ik snap ook niet helemaal wat je bedoelt met het wiel overnieuw uitvinden in dit verband?

Zoals ik met mijn proof-of-concept heb laten zien dat je prima in kan voegen in de native FreeBSD package systeem.

Dat voordeel noem je niet. [...] Ook hier geldt dat wat jij niet gebruikt, een ander juist een prachtige feature vindt.

Je vroeg mijn mening. Desktop en NAS zijn (zonder virtualisatie) voor mij onverenigbaar...

Ook is ZFSguru geen NAS, maar een multifunctional server appliance.

Voor mij blijft het een NAS systeem. In afwachting van een betere product placement. Coca Cola blijft voor mij ook een medicijn tegen misselijkheid

Ook hier is het kernpunt weer: keuze. ZFSguru biedt naast de stabiele releases ook bleeding edge releases. Wil je die niet, blijf dan bij de stable releases. Ook hier geldt weer: keuzevrijheid.

Dat is wat ik zeg, maar niet wat jullie zeggen. Jullie lopen opnieuw dingen veel te ruim te nemen waardoor je onzin begint te verkopen.

Geen onzin. De opzet en filosofie van ZFSguru komt pas goed tot zijn recht als het is uitontwikkeld op bepaalde punten. Daarbij is de Migration Manager iets wat mist in de huidige opzet van makkelijk kunnen installeren en installeren ipv een bestaand systeem upgraden en daardoor allerlei potentiele issues veroorzaken. De filosofie achter ZFSguru komt dus pas goed tot zijn recht als de missende features zijn ontwikkeld. Dat heeft niets te maken met het feit dat iets altijd wel verder te ontwikkelen valt.

Het blijft wel onzin omdat o.a. ook een migration manager onzin is. Als je nu zou aansluiten bij het native package systeem van FreeBSD en daarmee ook rolling releases zou ondersteuning dan heeft zo'n migration manager totaal geen meerwaarde meer.

Voor anderen boeide dit wel; zie ook de forum thread waarbij mensen aangeven dat ze de versies maar ingewikkeld vonden.

Dat is meer een communicatie probleem dan een nummeringsprobleem waarin officieel een major, minor, patch enz. nummering gebruikt zou moeten worden... Doe ik overigens ook niet.

Dat is tegen de filosofie van ZFSguru. Rolling releases zullen er nooit komen. Het idee is juist dat wat jij draait, anderen ook draaien. Zo kunnen bugs of problemen in een bepaalde versie bekend worden en kunnen gebruikers anderen op de hoogte stellen dat versie X een probleem heeft met zus en versie Y een probleem heeft met zo.

Dat is zo (no-offense) domme keuze. Gebruikers hebben geen probleem met een bepaalde systeem versie. Gebruikes hebben problemen met een bepaalde versie van een pakket. Dat kan dus ook een kernel of firmware versie zijn. Pakket versies bugfixen en -tracken is vele malen makkelijker dan complete systeemversies. Je wilt dus eigenlijk je systeem in zo klein mogelijke maar nog steeds handzame pakketten onderverdelen.

Het is daarnaast voor je eigen imago ook niet slim. In mijn geval waren (en zijn) alle ZFSGuru systeemversie klote omdat ze allemaal geen CIFS prullenbak ondersteunen in mijn setup. Als eindgebruiker wijt ik dat aan ZFSGuru terwijl er een bug in samba zat (welke ik zelf heb gevonden en waarvan mijn patch in de officiele samba word opgenomen). Was het niet veel gemakkelijker geweest als jullie hadden kunnen zeggen:

We zijn ons bewust van het probleem. In enkele dagen rolt er een nieuwe zfsguru samba versie uit die dit probleem oplost. Dus even een pkg upgrade doen en klaar.

Hoe makkelijk zou dat zijn. Idealiter zou ik als ZFSGuru gebruiken zelf de nieuwe samba service voor jullie hebben gemaakt. Nu betekent het voor mij opnieuw en opnieuw images uitproberen om te zien of ze allemaal het probleem hebben. Je trekt dus problemen met bepaalde pakketten naar jullie toe terwijl die niet bij jullie horen. Door deze manier van communicatie impliceer je dat wel ten koste van je eigen product.

Voorbeeld uit de praktijk. Mensen die XBian gebruikten hadden een probleem met CEC en een bepaalde type televisie. In vorige versies van CEC werkten het wel, maar in nieuwere niet meer. Gebruikers van dat type televisie waren dus verplicht om bij een bepaalde XBian versie te blijven, omdat die de specifieke CEC versie bevatten. Nu kunnen gebruikers elke laatste XBian updates installeren (via rolling releases) behalve die ene CEC versie. Die kunnen ze gedowngrade laten totdat het CEC probleem is opgelost. Hetzelfde geldt voor de laatste Raspberry Pi kernels. Hierin zit een bug waardoor pilight niet meer werkt. In update gewoon de kernel niet meer totdat het probleem is opgelost. Ondertussen kan ik gelukkig nog wel de laatste versies van andere pakketten blijven installeren.

Geen gekut meer waar je wekenlang zoet mee bent. Dat zit er achter.

Naïviteit zit hierachter... Tuurlijk kan je altijd een bepaalde combinatie van pakketten tot nieuwe versie image maken. Aansluiten bij FreeBSD releases is een goed idee. Dan blijf je in sync met hun. Maar om dit als argument te gebruiken om geen rolling releases te willen ondersteunen is meer een argument van onkunde, onwetendheid en in contradictie met je eerdere stokpaarde:

Ook hier is het kernpunt weer: keuze. [...] Ook hier geldt weer: keuzevrijheid.

Maar ik ben er zelf erg blij mee, en kost veel werk maar betekent wel dat ZFSguru een stuk serieuzer wordt als er elke week of meerdere keren per week een nieuwe versie uit komt rollen.

Mensen zitten niet te wachten op meerdere keren per week een nieuwe versie als dat betekent dat ze voor elke versie een herinstall moeten doen. Mensen willen meerdere keren gewoon via een pkg upgrade nieuwe versie van pakketten (of in jullie jargon services) binnenhalen en daarmee up-to-date blijven. Ik snap die +100 starfpunten dus wel.

Dat is ter sprake geweest. Twee argumenten voor een eigen oplossing zijn security en customization.

Ik kan de argumenten en ben het er niet mee eens

In elk geval minder werk, daar heb je zeker gelijk in. Maar op langere termijn is GitLab wel stukken veiliger voor ons project. Hierbij verwijs ik ook naar het feit dat GitHub een Amerikaans commerciëel bedrijf is dat ook moet voldoen aan Amerikaanse wetgeving.

Bla bla bla alu hoedje* bla bla bla.

Zie hierboven.

Inderdaad. Zie mijn vorige argumenten. PS. daarvoor zijn image checksums in het leven geroepen. Die staan op een veilige server zodat images altijd geverifieerd kunnen worden in jullie slechtste scenario.

Ik snap je punt. En je hebt zeker gelijk dat het ten koste gaat van kostbare development resources. Dat is denk ik het grootste nadeel en tegenargument van de keuze die wij hebben gemaakt. Maar koppig als we zijn, denken we toch de juiste afweging te maken. De toekomst zal uitwijzen of dit terecht is.

Ik noem het naïef en star.

Ik ben niet zo onder de indruk van wat er door anderen gemaakt is, eerlijk gezegd. Dat geldt voor eigenlijk alles wat ik zie. Alles is ook gebouwd en ontwikkeld met een commercieel motief ofwel open-source maar dan ontwikkeld door autistische nerds. Wij zijn geen van beide, denk ik. \

Van dat eerste geloof ik geen zak. Ten eerste omdat ik het niet wil geloven omdat het in groot contrast staat tot die laatste zin. En ten tweede omdat ik het simpelweg nogal arrogant vind. Er zijn tig voorbeelden te noemen die tevens laten zien dat jullie in vergelijking tot andere projecten toch echt het onderspit delven. Voorbeelden:
- Kwaliteit van code
- (Voor de zoveelste keer) Opnieuw maar slechter het wiel uitvinden.
- Keuzes qua veiligheid
- Communicatie

Misschien is dat wel juist een kracht waar iets moois uit kan voortkomen. Ietwat arrogant klinkt het misschien wel, en we kunnen natuurlijk niet alles zelf doen. Maar hoe minder afhankelijkheid van derde partijen, des te beter.

WAT?!? Dat is juist wat iedereen juist zegt. DOE DAT DAN OOK NIET. Het heeft ook niks met afhankelijkheid te maken. Als je kijkt naar bijvoorbeeld de manier waarop XBian is opgebouwd dan kan je dat verbeteren, maar ben je daar dan in enige vorm afhankelijk van Beide projecten lijken echt veel meer op elkaar dan dat jij denkt. Jammergenoeg doet die laatste (behalve dan in communicatie) het écht vele malen beter dan jullie.

Om maar een voorbeeld te geven: ZFSguru heeft dependencies op php5-session en php5-gd.

Makkelijk (zonder dirty hacks) op te lossen zoals ik al eerder heb aangetoond.

Alles zelf maken betekent maximale controle en uiteindelijk ook maximale betrouwbaarheid.

Alleen als je zelf kundiger bent dan de ontwikkelaars van bestaande oplossingen. Dat zijn jullie niet. In sommige gevallen zelfs verre van.

*en dat zegt een privacy junkie

[ Voor 10% gewijzigd door CurlyMo op 04-08-2014 10:20 ]

[FireDrunk]

Jij roept dingen als WordPress hacken om nieuwe releases automatisch te tonen?
Ik geloof dat er al JAREN iets is als RSS feeds... Je kan een nieuwe release maken op GitHub, en met je eigen WordPress blogje automatisch de RSS feed van je eigen project uitlezen en tonen...

Daar is weinig gehack aan...

Maar goed, jullie discussieren er lekker op los, maar ik zie nog steeds geen concreet stappenplan...
Je ziet GitLab weer als de heilige graal, maar misschien is er over een paar maanden/jaar wel weer iets anders, en zitten we weer een half jaar tot een jaar te wachten op een nieuwe source code repo.

Het is juist de kunst om niet zo afhankelijk te zijn doordat je off-the-shelf producten gebruikt... Dit maakt je veel meer portable.

Het is leuk om iets 100% gecustomized te hebben naar wat jij precies wil, maar dat werkt maar zolang je applicatie niet veranderd... Zodra de community development gaat rollen, durf ik er geld op in te zetten dat jouw eigen GitLab niet voldoet...

[Verwijderd]

Beste CurlyMo,

Ik vroeg inderdaad om je mening, maar natuurlijk wel om je mening over het project. Niet je mening over jou als (potentiële) gebruiker. Om een analogie te maken: als ik aan iemand vraag "wat vind je van mijn hamburgertent?" dan verwacht ik geen antwoord als "ik vind tomatensaus niet lekker" maar dan verwacht ik feedback verplaatsende in de doelgroep van mijn hamburgertent. Het verschil is natuurlijk dat niet direct relevant is wat jij van service X of service Y vindt, omdat je dat persoonlijk niet gebruikt. Die services kunnen wel degelijk nuttig zijn voor anderen, en dat als geheel maakt het project ook wat het is. Feedback op dat geheel is natuurlijk veel waardevoller dan alles vanuit je eigen persoonlijke smaak te bekijken. Waar ik wat aan heb is hoe de doelgroep iets beleeft en hoe het project verbeterd kan worden ten voordele van die doelgroep.

ZFSguru is juist een project wat zowel novice gebruikers als gevorderden probeert te verenigen in één interface. Dat is ambitieus. Meestal is het òf heel simpel en geschikt voor newbies, of een hoge leerdrempel en eigenlijk alleen geschikt voor gevorderden. ZFSguru probeer dit conflict te vermijden door een slimme interface te maken die zowel newbies als gevorderden kunnen waarderen, en daarnaast heel veel zaken optioneel te maken.

Dat jij geen grafische omgeving op je NAS wilt, betekent niet dat dit voor anderen ook geldt.
Dat jij periodieke releases onzin vindt, betekent niet dat dit voor anderen ook geldt.
Dat jij een migration manager onzin vindt, betekent niet dat dit voor anderen ook geldt.
Dat jij bepaalde opvattingen hebt over hoe code geschreven moet zijn, betekent niet dat anderen dit ook zo belangrijk vinden.

Je bent waarschijnlijk helemaal niet de doorsnee gebruiker waar wij voor ontwikkelen. Dus je mening als gebruiker an sich is niet zo heel erg interessant; wel je mening over het project en de te volgen route, mits je je kunt inbeelden wat wij proberen te bereiken op korte maar vooral ook op langere termijn. De State of the Project van Jason en ik gaat juist in op die toekomst; daar wil ik dan ook graag feedback op.

Je lijkt niet erg onder de indruk van de filosofie achter ZFSguru. Alle voorstellen die je doet zijn vooral erop gericht om ZFSguru te maken zoals andere projecten dat doen. Daarmee verdwijnt denk ik ook het bestaansrecht van het project. Als ZFSguru is zoals FreeNAS / NAS4Free, waarom zou het dan bestaan? Zij hebben meer developers, resources en inkomsten. Concurreren op dezelfde manier is zinloos. Bovendien zijn Jason en ik helemaal niet goed in het ontwikkelen volgens de concepten die jij voorstelt.

De minachting voor de manier waarop wij dingen proberen te benaderen vind ik jammer. Vooral omdat ik juist denk dat er wel degelijk bestaansrecht is voor een alternatief project met een bredere scope en die een andere kijk heeft op zaken dan de meer traditionele projecten. Veel mensen die ZFSguru gebruiken, noemen ook de voordelen van ZFSguru versus de concurrentie. Dat is toch knap aangezien het hoofdzakelijk het werk is van één iemand, tegenover een heel team aan zwaarbetaalde krachten van iX Systems Incorporated. Dat kan alleen als er wel degelijk iets te zeggen valt voor de afwijkende keuzes die Jason en ik maken aangaande het project.

Je noemt bijvoorbeeld de mogelijkheid om ZFSguru een eigen pkg-repository te laten gebruiken. Dat is enorm veel werk, terwilj het minimaal 99% van onze gebruikers - onze doelgroep - niets zou uitmaken of er handmatig files worden geschreven of via BSD-packages wordt geïnstalleerd. Bovendien zou het bepaalde zaken onmogelijk maken, zoals de Newcons experimentele packages; die zijn afhankelijk van de systeemversie en met welke kernelconfiguratie die zijn gebuild. Dat probleem heeft FreeBSD zelf ook; omdat er pas onlangs WITH_NEW_XORG packages zijn gemaakt en de repo is overgegaan op de nieuwe X.org server. Dit terwijl ZFSguru al veel langer deze mogelijkheid bood, met een paar muisklikken. Ook de keuze om voor de oude server te gaan (X-server, X-server-KMS) en diens dependency packages zoals nVidia-drivers en Virtualbox-drivers; die niet zomaar werken als de X-server anders gecompileerd is. Dus je proof-of-concept is zeker een aanzet voor een andere stijl van add-on packages, maar kan vanuit het oogpunt van de eindgebruiker juist een stap achteruit in plaats van een stap vooruit betekenen.

Bovendien, ook voor de <1% die dit belangrijk vindt, is het prima te doen. Installeer geen services! Doe alles zelf op de command line met 'pkg'. Dus voor diegenen die alles via 'pkg' willen doen, biedt ZFSguru ze alle bewegingsvrijheid, in tegenstelling tot FreeNAS en NAS4Free die geeneens een complete basis hebben en ook alles in jails moet gebeuren. Of dat nu goed of slecht is, het is een beperking van vrijheid. ZFSguru biedt juist alle vrijheid, maar beschermt casual gebruikers wel tegen user error - bijvoorbeeld door ze GPT labels te laten gebruiken.

Ik wil je zeker bedanken voor de tijd die je hebt genomen om een antwoord te geven, maar vooralsnog kan ik er niet heel veel mee. Ook vind ik het jammer dat je voornamelijk negatief bent, vooral als het gaat om de zaken waar ZFSguru afwijkt van de concurrentie. Dat is nu juist de hele reden dat ZFSguru bestaansrecht heeft. Dat krijgen we ook regelmatig te horen via het forum en via email. Als ik jouw voorstellen zou volgen en aan features zou werken die onze doelgroep helemaal niet interessant vinden, maar wel enorm veel tijd kosten, dan is dat denk ik het einde van het project. Niemand zit te wachten op een wannabe-FreeNAS of wannabe-NAS4Free. Maar er is denk ik wel degelijk ruimte voor een alternatief project wat andere keuzes maakt en unieke features heeft met veel eigen werk en liefde erin gestoken, en volledig niet-commercieel dat mag ook genoemd worden.

Je noemt ten slotte communicatie als probleem, maar juist daar wordt toch hard aan gewerkt? De State of the Project die een duidelijke richting geeft aan het project, mijn bijdragen in dit topic van inmiddels 535 posts, de ontwikkeling van Bulletins waarbij gebruikers van ZFSguru in de interface worden gewaarschuwd voor belangrijke errata-berichten, zoals upgraden van bootcode als ze updaten. Voor een project van slechts twee developers kun je denk ik niet veel meer verwachten; het is niet alsof we een fulltime persvoorlichter in dienst hebben. Al voelt het soms wel zo dat ik die rol vervul. En daarmee ook alle shit over me heen krijg.

Waarom zo negatief over ons? Is hetgeen we tot dusver al bereikt hebben echt zo slecht? Heeft het project geen enkel bestaansrecht? Ik zie het juist best wel zitten met alle ontwikkelingen. De kritiekpunten die er waren, zijn denk ik vrijwel allemaal aan bod gekomen in de State of the Project en ook allemaal voorzien van een perspectief op verbetering. Hoe lang het gaat duren, is van secundair belang. We doen wat we kunnen doen. En langzamerhand groeit ZFSguru naar iets waar veel mensen gebruik van maken en waar ook mensen aan mee willen helpen. En tegen die tijd heeft ZFSguru ook de infrastructuur om dat goed te kunnen doen, zonder ons uit te leveren aan de grillen van Amerikaanse wetgeving. Koppig én principieel!

[CurlyMo]

Verwijderd schreef op maandag 04 augustus 2014 @ 11:32:
Lang verhaal om één punt te maken.

Je lijkt niet erg onder de indruk van de filosofie achter ZFSguru.

Klopt.

Alle voorstellen die je doet zijn vooral erop gericht om ZFSguru te maken zoals andere projecten dat doen. Daarmee verdwijnt denk ik ook het bestaansrecht van het project. Als ZFSguru is zoals FreeNAS / NAS4Free, waarom zou het dan bestaan? Zij hebben meer developers, resources en inkomsten. Concurreren op dezelfde manier is zinloos. Bovendien zijn Jason en ik helemaal niet goed in het ontwikkelen volgens de concepten die jij voorstelt.

Je blijft dit argument aanhalen om ten onrechte iets te verdedigen. Dat eerste en laatste is echt onzin. Jullie zijn gewoon eigenwijs. Het maken van jullie service systeem is vele malen complexer dan gewoon een native FreeBSD package maken.

"Daarmee verdwijnt denk ik ook het bestaansrecht van het project."

Als je dat écht denkt, dan moet je sowieso eens gaan nadenken over jullie bestaansrecht. Dat kan je negatief noemen van me, maar je roept het op jezelf af door deze antwoorden te geven.

Je noemt bijvoorbeeld de mogelijkheid om ZFSguru een eigen pkg-repository te laten gebruiken. Dat is enorm veel werk, terwilj het minimaal 99% van onze gebruikers - onze doelgroep - niets zou uitmaken of er handmatig files worden geschreven of via BSD-packages wordt geïnstalleerd.

Dat zou ze wel uitmaken, al is het maar dat je zo rolling releases en daardoor automatisch een migration manager hebt. Ik denk dat de gemiddelde XBian gebruiker een grotere noob is dan de gemiddelde ZFSGuru gebruiker. Ik denk dat ik dus een aardig referentiekader heb.

Bovendien zou het bepaalde zaken onmogelijk maken, zoals de Newcons experimentele packages; die zijn afhankelijk van de systeemversie en met welke kernelconfiguratie die zijn gebuild.

Nee hoor. Al via een proof-of-concept bewezen.

Dus je proof-of-concept is zeker een aanzet voor een andere stijl van add-on packages, maar kan vanuit het oogpunt van de eindgebruiker juist een stap achteruit in plaats van een stap vooruit betekenen.

Nee hoor, anders zou je zelf geen aparte migration manager bouwen.

Ook vind ik het jammer dat je voornamelijk negatief bent, vooral als het gaat om de zaken waar ZFSguru afwijkt van de concurrentie. Dat is nu juist de hele reden dat ZFSguru bestaansrecht heeft.

Ik ben niet negatief over ZFSGuru als potentieel, maar ik ben negatief over jullie eigenwijzigheid die je maar blijft herlabelen als "andere richting". En ik ben niet de enige die dat keer op keer zegt in dit topic.

Als ik jouw voorstellen zou volgen en aan features zou werken die onze doelgroep helemaal niet interessant vinden, maar wel enorm veel tijd kosten, dan is dat denk ik het einde van het project.

Opnieuw, dat is niet waar want anders zou je niet een migration manager bouwen.... Het gaat niet meer tijd kosten. Je kunt prima vanaf nu FreeBSD pkgNG pakketten gaan bouwen en de oude blijven ondersteunen totdat de oude services overbodig zijn geworden. En zoals zovaak gezegd: Schakel de community in. Ik ben best bereid om enkele pakketten te herschrijven die voor mij belangrijk zijn.

Voor een project van slechts twee developers kun je denk ik niet veel meer verwachten

Vind ik wel. Maar dat is opnieuw inherent aan de keuzes die jullie maken.

Waarom zo negatief over ons? Is hetgeen we tot dusver al bereikt hebben echt zo slecht?

Om een politiek antwoord te geven. Het is functioneel Ik ben echter (net als velen hier) van mening dat je een doodlopende weg inslaat als jullie zo eigenwijs blijven.

Heeft het project geen enkel bestaansrecht?

Ja, want anders zou ik het zelf niet gebruiken.

We doen wat we kunnen doen. En langzamerhand groeit ZFSguru naar iets waar veel mensen gebruik van maken en waar ook mensen aan mee willen helpen.

Dat laatste hangt echt af van de keuzes die gemaakt worden. Ik weet niet of ik wel aan gitlab ga deelnemen als ik gewoon als een github account heb. Ik ga in ieder geval geen services schrijven, maar wel pkgNG scripts. Hopelijk sta ik hier alleen in.

Onderschat ook de userbase van github niet. Nu kan ik, als ik een verbetering wil doorvoeren in een github project, makkelijk de code aanpassen waarna github automatisch een fork maakt en een patch verstuurd naar de ontwikkelaars. De drempel is hiermee vele malen lager dan hiervoor een apart nieuw account te moeten maken bij elk project. Het publiekelijk patchen van projecten zoals Samba zal ik niet veel vaker meer doen gezien de moeite die ik ervoor heb moeten doen om het gedaan te krijgen.

[ Voor 5% gewijzigd door CurlyMo op 04-08-2014 12:10 ]

[FireDrunk]

Ik sluit me volledig aan bij CurlyMo, ik heb het zelf ook al vaker gezegd, je verschuilt je achter een filosofie dat jij maakt wat andere mensen leuk vinden...

Ik kan je 1 ding zeggen: Niets zo veranderlijks of onverzadigbaars als gebruikers... Jij zegt dat je jaren nodig hebt om een goede basis te leggen voor features die gebruikers wilen, terwijl ik denk dat die features over een paar manden alweer outdated zijn omdat gebruikers constant veranderen...

The only constant in life is change...

Zoals CurlyMo ook al zegt, trek de community er nou eens bij. Als je niet kan hebben dat gebruikers (omdat ze invloed hebben) een iets andere weg inslaan (door code/features te bouwen die jij niet handig vind), hoe kan je dan het idee ophouden dat je je dingen maakt voor gebruikers?

Het is jouw beeld om bepaalde features te maken voor gebruikers.

Als dat *echt* zo is, maak dan maar een burndownchart, en maak een gigantische poll voor eindgebruikers, en maak de dingen die bovenaanstaan.

MESA is jullie eigen feestje, en absoluut niet iets wat gebruikers willen... Het zal mensen echt jeuken hoe de zfsguru.com website er uit ziet, als hij maar functioneel is...

Met het roepen dat je MESA wil gebruiken stoot je keihard tegen je eigen filosofie in dat je maakt wat gebruikers willen...

Zoals CurlyMo duidelijk zegt: "Gebruikers willen functionaliteit, het zal ze jeuken hoe het gemaakt is"...

_{Met als enige uitzondering (vanuit mijn kant) security, want daar schort het nogal aan (o.a. in de code, maar ook by-design)}

[Verwijderd]

@CurlyMo
Ik respecteer je mening dat bepaalde overtuigingen van Jason en mijzelf niet door jou worden gedeeld. Maar respecteer je ook dat wij willen doen waar wij goed in zijn, in plaats van te conformeren aan iets wat ons inziens nooit een groot succes gaat worden?

Met andere woorden: Can we agree to disagree?

Ik heb je mening en inzichten echt een serieuze overweging gegeven, maar ik blijf erbij dat de door ons ingeslagen weg veel meer perspectief biedt dan een weg in te slaan anderen al hebben gekozen en daar ook al veel meer progressie in hebben bereikt.

Een groot gedeelte van je verhaal gaat ook over packages en de manier hoe ZFSguru hier mee omgaat. Ook al zou het voor de eindgebruiker beter zijn als we dit heel anders zouden aanpakken, het is wel wat we op dit moment hebben en gebruiken. Het veranderen zou veel ontwikkeltijd vergen, en daarmee ook ten koste gaan van belangrijke features waar Jason en ik vele liever aan werken. Dat gezegd; als ZFSguru in de toekomst bij een punt is beland waar zelfs jij je prettig bij voelt, staat niets je in de weg om een eigen implementatie te maken. Al zou het niet de default worden, is er niets wat in conflict komt met onze overtuigingen om dit als keuze beschikbaar te stellen aan gebruikers. Wil jij je eigen package-repository en ben je bereid hier wat maandjes aan te werken, dan ben je natuurlijk van harte welkom.

Hoewel je me verleid om op technische zaken in te gaan, ben ik hier terughoudend in omdat ik liever niet over de details wil praten. Maar de Migration Manager is natuurlijk veel meer dan een methode om packages te updaten. Het is ook een methode van backup, het is ook een methode om clone-ZFSguru installaties te maken waarbij je uitgaat van een skelleton-configuratie, het is ook een manier om je systeem te updaten behalve packages alleen. En vooral is het een toegankelijke methode waarbij gebruikers alle configuratie in één bestand hebben, en daarmee het verlies van de operating system device goed kan verdragen. Zou je een USB-stick hebben die het begeeft, heb je je ZFSguru.migrationpack bestand nog op je desktop staan en kun je binnen notime een nieuwe USB stick maken met exact dezelfde configuratie. Dat kan ook als je handmatig op de command line dingen doet, maar het hele idee is natuurlijk gebruiksgemak en toegankelijkheid voor minder onderlegde gebruikers. Dit alles past ook binnen de filosofie dat ZFSguru een appliance is; geen systeem waar je elke dag moet aaien en knuffelen om het tevreden te houden.

[CurlyMo]

FireDrunk schreef op maandag 04 augustus 2014 @ 12:10:
Zoals CurlyMo duidelijk zegt: "Gebruikers willen functionaliteit, het zal ze jeuken hoe het gemaakt is"...

Dit is deels correct geinterpreteerd. Het is nu functioneel, maar werkt op allerlei manieren maar half of (under-the-hood) slecht. Je noemt zelf veiligheid als voorbeeld en ik blijf de service en migration manager aanhalen. Wat jij het stukje "by-design" noemt vind ik ook van wezenlijk belang. Daarom zou ik graag een pkgNG packages willen zien.

[EnerQi]

Maar goed, jullie discussieren er lekker op los, maar ik zie nog steeds geen concreet stappenplan...
Je ziet GitLab weer als de heilige graal, maar misschien is er over een paar maanden/jaar wel weer iets anders, en zitten we weer een half jaar tot een jaar te wachten op een nieuwe source code repo.

Het is juist de kunst om niet zo afhankelijk te zijn doordat je off-the-shelf producten gebruikt... Dit maakt je veel meer portable.

Het is leuk om iets 100% gecustomized te hebben naar wat jij precies wil, maar dat werkt maar zolang je applicatie niet veranderd... Zodra de community development gaat rollen, durf ik er geld op in te zetten dat jouw eigen GitLab niet voldoet...

De opmerkingen van FireDrunk zouden de mijne kunnen zijn. Ik mis het stappenplan (of zoals CurlyMo zegt: roadmap + planning). Voor mijn gevoel is ZFSguru gegroeit van webpagina naar Server OS maar waardoor de focus wel al 3x verlegd is. De “State of the Project” is een erg goede manier van communiceren maar het gebeurd te weinig. Een stappenplan houdt de developers ook gefocust te houden op onderdelen die nu nodig zijn ipv nieuwe ideeën ;-).

In 2012/2013 (gokje) is ZFSguru opnieuw geschreven om er een Server OS van te maken (onderdeel “Mesa“ genoemd). Allemaal goede ideeën die echt een toegevoegde waarde hebben maar waar de gebruikers (nog) geen vruchten van kunnen plukken EN de “webinterface” onnodig vertraging opliep. Wat naar mijn mening zou gebeurd moeten zijn, is ZFSguru 0.2 (incl migratie manager) en daarna “Mesa” ontwikkelen voor het hogere doel van ZFSguru. Vervolgens ZFSguru 0.2.1 als nieuwe versie op Mesa en daarna de webinterface vernieuwen zoals de “Samba” vernieuwing.

Het voelt aan als: ik heb een idee en dat ga ik bouwen (ZFSguru webinterface), onderweg bedenk ik me dat ik het groter wil aanpakken (ZFSguru server OS). Ow dan moet ik het anders aanpakken en gooi ik het huidige project weg (Rewrite ZFSguru) om opnieuw te beginnen met een schone lei om de “domme” fouten uit het verleden te herstellen.
* domme fouten is gewoon het leereffect van schrijven van software*

Door een stappenplan kun je de gebruikers ook informeren en heeft de community ook (mogelijk) invloed wat er gemaakt wordt in welke volgorde. Zet er dan ook “rewrites” tussen om de zoveel features omdat het soms nodig is ;-).

p.s. Of sneller typen of gewoon ja knikken op FireDrunk

[CurlyMo]

Verwijderd schreef op maandag 04 augustus 2014 @ 12:14:
@CurlyMo
Ik respecteer je mening dat bepaalde overtuigingen van Jason en mijzelf niet door jou worden gedeeld. Maar respecteer je ook dat wij willen doen waar wij goed in zijn, in plaats van te conformeren aan iets wat ons inziens nooit een groot succes gaat worden?

No offense, maar was dat maar zo... Opnieuw negatief maar eerlijk.

Ik heb je mening en inzichten echt een serieuze overweging gegeven, maar ik blijf erbij dat de door ons ingeslagen weg veel meer perspectief biedt dan een weg in te slaan anderen al hebben gekozen en daar ook al veel meer progressie in hebben bereikt.

Dat zijn er tenminste twee die dat vinden

Een groot gedeelte van je verhaal gaat ook over packages en de manier hoe ZFSguru hier mee omgaat. Ook al zou het voor de eindgebruiker beter zijn als we dit heel anders zouden aanpakken, het is wel wat we op dit moment hebben en gebruiken. Het veranderen zou veel ontwikkeltijd vergen, en daarmee ook ten koste gaan van belangrijke features waar Jason en ik vele liever aan werken.

Volgens mij spreek je jezelf hier tegen

Dat gezegd; als ZFSguru in de toekomst bij een punt is beland waar zelfs jij je prettig bij voelt, staat niets je in de weg om een eigen implementatie te maken. Al zou het niet de default worden, is er niets wat in conflict komt met onze overtuigingen om dit als keuze beschikbaar te stellen aan gebruikers. Wil jij je eigen package-repository en ben je bereid hier wat maandjes aan te werken, dan ben je natuurlijk van harte welkom.

Als het ooit open-source wordt, misschien maak ik dan wel een fork...

Het is ook een methode van backup

ZFS send/receive?

het is ook een methode om clone-ZFSguru installaties te maken waarbij je uitgaat van een skelleton-configuratie,

Pakketten lijst opvragen van de oude installatie en laten installeren op de nieuwe?

Het is ook een manier om je systeem te updaten behalve packages alleen.

Als het goed is bestaat het systeem uit alleen maar pakketten.

En vooral is het een toegankelijke methode waarbij gebruikers alle configuratie in één bestand hebben, en daarmee het verlies van de operating system device goed kan verdragen.

ZFS send naar een bestand.

[FireDrunk]

Volgens mij probeert CiPHER het walhalla van migraties te maken, de configuratie losweken van de pakketten. De restore strategie is dan, pakketten herinstalleren, configuratie terugzetten, rebooten et voila, dat zou het moeten zijn.

Het grappige is, dat dit de UNIX/POSIX filosofie was met de /etc folder, daar moesten alle configuratie bestanden in.

Als je die dus op een losse partitie zet, en backupped, zou je in principe alles moeten kunnen restoren (qua configuratie).
In de praktijk blijkt dit helemaal niet goed te werken, waarom?, niemand die het duidelijk weet, het zal iets met de diversiteit van pakketten te maken hebben.

Mijn visie: Jullie migratie structuur zal vast werken voor misschien wel 50% van de pakketten, maar er komen geheid pakketten die gewoon niet goed werken, of waarvoor de migration manager continue voor moet worden herschreven...

En dat is juist niet wat gaat werken, want dan moet je dus alsnog op een rare manier ZFSguru zelf gaan updaten, omdat je de migration manager moet updaten...

Dus tenzij dat zelf een pkgNG pakket is, zal het gewoon in de toekomst stuklopen...

Als je *ECHT* wil leren hoe een rolling release werkt, en hoe je dat kan implementeren, kijk dan eens naar Gentoo. Die jongens weten pas echt wat het is om een rolling release te maken...

[ Voor 7% gewijzigd door FireDrunk op 04-08-2014 12:28 ]

[CurlyMo]

Of gewoon in je cutom pkgNG pakketten het configuratie bestand op een aparte partitie opslaan en een symlink maken naar de originele locatie. Dat is hoe ik het doe.

En daarnaast dus een goede oude zfs send rootpool@backup | gzip -9 > backup.gz

[ Voor 21% gewijzigd door CurlyMo op 04-08-2014 12:42 ]

[Verwijderd]

FireDrunk schreef op maandag 04 augustus 2014 @ 12:10:
Ik sluit me volledig aan bij CurlyMo, ik heb het zelf ook al vaker gezegd, je verschuilt je achter een filosofie dat jij maakt wat andere mensen leuk vinden...

Nee, we maken iets volgens onze eigen principes en overtuigingen, en later blijkt dat dit aanslaat bij een groep eindgebruikers, die projecten als FreeNAS en NAS4Free links laten liggen en ZFSguru meer bevalt. Dat betekent dat ZFSguru op dit moment al meerwaarde heeft boven de genoemde projecten. En dat is natuurlijk niet omdat wij precies hetzelfde doen als FreeNAS en NAS4Free.

Ik kan je 1 ding zeggen: Niets zo veranderlijks of onverzadigbaars als gebruikers... Jij zegt dat je jaren nodig hebt om een goede basis te leggen voor features die gebruikers wilen, terwijl ik denk dat die features over een paar manden alweer outdated zijn omdat gebruikers constant veranderen...

Dat denk ik niet. Welke features zijn verouderd dan? Drag en drop Samba permissies? Juist een mooie ZFSguru-only feature die FreeNAS en NAS4Free niet hebben. Zoiets moeilijks als file permissies heerlijk toegankelijk maken voor een brede doelgroep, dat soort dingen vind ik tof aan ZFSguru. Waar je als kleintje groot in kan zijn.

Als je quote anders mag interpreteren: als ZFSguru een ZFS-web-interface was gebleven, was het project tegen de tijd dat het af was alweer verouderd. ZFS en Btrfs en ReFS zijn dan gemeengoed geworden en ZFSguru is minder relevant. Daarom ook juist de verlegging van ZFS-interface naar ZFS appliance, en meer recentlelijk naar multi-functional server appliance. Iets wat FreeNAS weigert te doen. NAS4Free volgens mij ook. ZFSguru kiest bewust een andere weg. En ziet ZFS vooral als basis voor iets wat nog veel verder kan groeien. Zo heeft het project juist een betere toekomst dan wanneer het enkel een ZFS-interface was gebleven.

Zoals CurlyMo ook al zegt, trek de community er nou eens bij.

Wat denk je dat ik aan het doen ben in dit topic?

Het is jouw beeld om bepaalde features te maken voor gebruikers.

No shit sherlock
Hoe moet het anders? Dat de gebruikers ons gaan vertellen wat we moeten doen? Vaak is het zo dat gebruikers zelf niet weten wat ze willen. Dat zeggen ook sommige ZFSguru gebruikers: dat beta9 features had waarvan ze geeneens wisten dat ze daar behoefte aan hadden. Ik denk dat je leiderschap moet tonen door je eigen weg te durven kiezen. Aan het eind van de rit kun je conclusies maken of het succesvol is geweest.

Als dat *echt* zo is, maak dan maar een burndownchart, en maak een gigantische poll voor eindgebruikers, en maak de dingen die bovenaanstaan.

Gebruikers laten kiezen tussen verschillende features is zeker iets waar we voor open staan. Ook min of meer al gebeurt in het verleden, waarbij men voor de Samba user-management en permissies koos. Dat is dan ook gebeurt.

MESA is jullie eigen feestje

Inderdaad. Chill!

Het zal mensen echt jeuken hoe de zfsguru.com website er uit ziet, als hij maar functioneel is...

Ik denk dat een eerste kennismaking met ZFSguru heel belangrijk is. Mensen weten niet of ze ZFSguru willen. Veel mensen ontdekken pas dat ZFSguru iets leuks is nadat ze het gebruiken, terwijl de website de indruk geeft van een stoffig nerderig project.

Mesa heet trouwens drie doelen:
1) nette rewrite van code, het is een rewrite van de library-code van ZSFguru in een manier die niet meer ZFSguru-specifiek is. Uiteindelijk kan het dus ook door ZFSguru gebruikt worden.
2) als CMS-product voor de nieuwe website
3) als losstaand project waar andere mensen mee verder kunnen, waarbij hun bijdragen ook weer tegoedkomen aan het ZFSguru project.

Jullie doen ook alsof Mesa veel tijd heeft gekost; het heeft Jason denk ik anderhalve week gekost. Onderhand zijn we meer tijd kwijt door het over Mesa praten dan het hele project tot nu toe heeft gekost qua ontwikkelwerk. Dus jongens, komop... niet zo vervelend!

Zoals CurlyMo duidelijk zegt: "Gebruikers willen functionaliteit, het zal ze jeuken hoe het gemaakt is"...

Uitstekend argument tegen CurlyMo's pkg-repository.

Oke die is flauw.

Het grappige is, dat dit de UNIX/POSIX filosofie was met de /etc folder, daar moesten alle configuratie bestanden in.

Het leuke is dat zelfs FreeBSD nu van deze filosofie afstapt. Het systeem wordt losgeweekt van de addon software. De traditionele UNIX-directorystructuur gaat op de schop. Dat is ook hoe ik het zie: operating system is één geheel met een virtuele directorystructuur, en ieder project heeft zijn eigen afgesloten gedeelte met eigen directorystructuur. Denk aan hoe Wine applicaties installeert in zijn eigen virtuele omgeving. Zo kan het één niet het ander verneuken. Ik hoor je al over Jails praten; hou je in FireDrunk, denk om je bloeddruk.

Mijn visie: Jullie migratie structuur zal vast werken voor misschien wel 50% van de pakketten, maar er komen geheid pakketten die gewoon niet goed werken, of waarvoor de migration manager continue voor moet worden herschreven...

Nee hoor. Het werkt ook heel simpel. Elke service heeft een file waarin de migratiefiles staan of directories. Voor de weinige pakketten waar extra stappen nodig zijn, zoals het uitvoeren van commando's, is er een migratiescript. Dit moet natuurlijk wel per service onderhouden worden, maar de migration manager zelf is agnostisch en heeft geen specifieke zaken - geen hacks.

---

EnerQi schreef op maandag 04 augustus 2014 @ 12:16:
De opmerkingen van FireDrunk zouden de mijne kunnen zijn.

Zeg, jullie gaan niet samenspannen hè!

Ik mis het stappenplan (of zoals CurlyMo zegt: roadmap + planning).

State of the Project geeft toch duidelijk aan wat je kunt verwachten op korte en middellange termijn. Alleen niet in welke volgorde. Het verleden wijst uit dat uitspraken hierover zelden accuraat zijn. Dus dat heeft dan ook weinig zin. Maar waar Jason op dit moment keihard aan werkt is de Automated System builds. Dat is een megaproject en heeft goede vorderingen gemaakt. Hopelijk snel genoeg klaar voor een eerste oplevering van een systeemversie gemaakt door dit systeem. Wat mij betreft een mijlpaal voor het project!

Voor mijn gevoel is ZFSguru gegroeit van webpagina naar Server OS maar waardoor de focus wel al 3x verlegd is. [..] In 2012/2013 (gokje) is ZFSguru opnieuw geschreven om er een Server OS van te maken [..] Het voelt aan als: ik heb een idee en dat ga ik bouwen (ZFSguru webinterface), onderweg bedenk ik me dat ik het groter wil aanpakken (ZFSguru server OS). Ow dan moet ik het anders aanpakken en gooi ik het huidige project weg (Rewrite ZFSguru) om opnieuw te beginnen met een schone lei om de “domme” fouten uit het verleden te herstellen.
* domme fouten is gewoon het leereffect van schrijven van software*

Maar dat is denk ik wel hoe het werkt. Je begint met iets en later zie je dat het anders moet en ga je de kern anders aanpakken. Kijk naar Firefox wat uit die stomme Mozilla Suite komt, en zo vast nog tal van voorbeelden.

[Verwijderd]

Ik kan het niet laten:

[CurlyMo]

Verwijderd schreef op maandag 04 augustus 2014 @ 12:44:
Wat denk je dat ik aan het doen ben in dit topic?

Je bent wel overtuigd dat de community de meest toekomstbestendige manier is, maar zoals ook FireDrunk zegt blijf je schermen met termen als principes en overtuigingen en maak je daarmee veel van de discussie dood.

Je kan gewoon niet redelijkerwijs blijven volhouden dat het telkens opnieuw uitvinden van het wiel beter is als ook hier je er constant op wordt tegengesproken. Als iets is wat Steve Jobs niet deed ...

Wat FireDrunk volgens mij bedoelt:
- Dat github account had er al lang geweest kunnen zijn.
- Die site, wiki en het forum ook.
- Ook had je allang al je code een officiele open source licentie kunnen geven zodat de community er tenminste iets mee kan.

Het hoeft niet gelijk volgens jullie ideeën perfect te zijn. Vind je dat gitlab de manier is, dan migreer je lekker zodra je server werkt. Is de nieuwe forum geschreven, dan migreer je die ook. Nu staan al die punten stil.

[FireDrunk]

Waar Jason (en CiPHER zelf ook) waarschijnlijk bang voor is, is het verliezen van controle, maar het leuke aan GIT zijn natuurlijk de Pull requests... Vind je iets niet goed en/of volgens de ZFSguru filosofie, dan weiger je gewoon de Pull request... Is dat netjes? Ja hoor, als je valide redenen hebt, waarom niet...

Probeer eerst je code filosofie eens onder woorden te brengen in concrete termen, denk daarbij aan de Python regels: http://python-history.blo...ns-design-philosophy.html
en de Python PEP8 Coding stijlgids.

Dit zijn dingen die juist iets excentrieks als ZFSguru concrete sturing kunnen geven... Jullie filosofie is leuk, maar niet tastbaar... Met een open code repo, een setje regels, en een burndownchart met de features gegroepeerd, krijg je jaren werk terug van de community.

Om maar even de regels er letterlijk bij te pakken:

Borrow ideas from elsewhere whenever it makes sense.
“Things should be as simple as possible, but no simpler.” (Einstein)
Do one thing well (The "UNIX philosophy").
Don’t fret too much about performance--plan to optimize later when needed.
Don’t fight the environment and go with the flow.
Don’t try for perfection because “good enough” is often just that.
(Hence) it’s okay to cut corners sometimes, especially if you can do it right later.

ZFSguru heeft op al die punten nog wel wat te leren denk ik...

[ Voor 30% gewijzigd door FireDrunk op 04-08-2014 13:13 ]

[CurlyMo]

Behalve dan dat een fork zo gemaakt is: "CurlyZFS, zfs with a twist"

[FireDrunk]

So what? Als ZFSguru het echt zo goed doet, is er niemand die overstapt...

[CurlyMo]

Dat was een reactie op je controle hypothese.

[EnerQi]

Jullie doen ook alsof Mesa veel tijd heeft gekost; het heeft Jason denk ik anderhalve week gekost. Onderhand zijn we meer tijd kwijt door het over Mesa praten dan het hele project tot nu toe heeft gekost qua ontwikkelwerk. Dus jongens, komop... niet zo vervelend!

Voor de community heeft het 1,5 jaar geduurd (minstens een jaar tussen de "state of projects"). Sterker nog, wij als gebruikers hebben er nog steeds niets aan .

Als gebruiker wil ik software die het gewoon doet wat ie moet doen en bugs snel opgelost worden. Ook wil ik dat de software up to date gehouden wordt voor de bij volgende releases van OS'en/onderliggende programma's (windows, freebsd, sabnzbd, virtualbox etc). Het idee dat ZFSguru heeft is erg goed (alleen installeren wat nodig is) maar nog niet optimaal werkt wegens gebrek aan services en update routine .

De migration manager en de automatisch releases (lees geupdaten services) zijn inderdaad dingen waarop ik aan het wachten ben. Ik ben ook benieuwd hoe het gaat werken.

[FireDrunk]

CurlyMo schreef op maandag 04 augustus 2014 @ 13:17:
Dat was een reactie op je controle hypothese.

Begrijp ik, maar ik denk dat CiPHER en Jason er nog steeds bang voor zijn... Vooral Jason is er bang voor dat iemand anders er met zijn 'kindje' vandoor gaat volgens mij...

[Verwijderd]

Meer dat het straks zijn project niet meer is; en hij er niets meer over te zeggen heeft. En daar hebben we ook uitgebreid over gepraat. Het idee is dat Jason nadat de basis klaar is, een stapje terug doet en meer een 'architect' wordt dan een ontwikkelaar. Wat dat betekent mag je rustig afwachten.

En jongens, jullie doen alsof er niet geluisterd wordt naar de feedback. Maar dat is denk ik onterecht. Het gebeurt alleen niet 100% zoals jullie het willen cq. voorstellen. Dat is niet zo erg. Belangrijk is wel dat er wat met de feedback wordt gedaan en er knopen doorgehakt worden. En GitLab is één van die knopen. Dus leef er nu maar mee. Als het een foute keuze is, dan is het nog wel onze foute keuze!

Jullie hebben echt wel goede punten, bijvoorbeeld het lijstje van FireDrunk hierboven. Het kiezen voor iets wat nu gewoon simpel werkt en later vervangen door iets beters, is inderdaad een goed argument. Dat gezegd; het is niet alsof er nu 10 developers aan de kant staan en niets te doen hebben omdat GitLab er nog niet is. Bovendien is het werken aan ZFSguru lastig omdat er ook nog documentatie moet worden geschreven.

De waarheid is gewoon; ZFSguru moet eerst een stapje hoger getild worden voordat het klaar is voor een grotere community invloed. En daar werken we aan. Hopelijk kan 2015 het jaar worden waar de vruchten geplukt worden en meer mensen aan ZFSguru kunnen gaan werken. Dan is de infrastructuur op orde, nieuwe server, nieuwe website, bugtracker, repository, feature requests, code submission, documentatie voor de manier hoe ZFSguru pagina's verwerkt, documentatie hoe services te maken, enzovoorts.

Het heeft allemaal tijd nodig. Maar we komen er wel. Alleen via een andere route die jullie zelf gekozen zouden hebben. Is dat zo erg?

---

Jullie filosofie is leuk

Kijk! Een positief woord over ZFSguru! Uit de mond van FireDrunk! De wonderen zijn de wereld nog niet uit.

[FireDrunk]

Zeg, niet zo negatief he... Hou het wel eerlijk... Het feit dat ik keer op keer zeg dat ik wel mee wil helpen zou toch al genoeg moeten zijn...

[Verwijderd]

Ja, maar begrijp ook dat ik maandenlang aan de pijnbank ook wel een keer zat ben. Ik heb echt wel moeite gestoken in jullie kritiek, opmerkingen en suggesties. Er is ook echt wel wat mee gedaan. Dus wees tevreden!

Ik hou het echt niet vol als ik alleen maar bakken kritiek over me heen krijg. Het is for-fucks-sake een vrijwilligersproject, zonder enig inkomen. Het moet wel een béétje leuk blijven. En ik vind ook dat Jason en ik prima onze eigen overtuiging mogen uitbrengen en ons project mogen vormgeven zoals wij dat willen.

En geloof me, er is voldoende ruimte voor inbreng van anderen zodra het project daar klaar voor is. 2015 lijkt me een realistische streefdatum. Kun je met redelijke documentatie aan de slag en code submitten en bugs registreren, enzovoorts. Dat is toch uiteindelijk waar het vooral om te doen is geweest? Wees blij dat vooral ook Jason keihard aan het knokken is met best wel moeilijke dingen, zonder dat hij al die jaren enig inkomen of persoonlijk profijt heeft gehad.

Dus ook wel het verzoek om het een beetje gezellig te houden. Meningsverschillen mogen er zijn, dat is het punt niet. Jullie hebben uitgebreid jullie kijk op de kwestie kunnen geven in dit topic - inmiddels toch meer dan een half duizend posts! Weeg dat ook mee. Het moet een keer klaar zijn; ik wil niet tot in de eeuwigheid horen hoe verkeerd GitLab is enzovoorts.....

[CurlyMo]

Als je voldoende input hebt, sluit dan dit topic De zwaarte van de kritiek geeft voor mij ook de aard van het meningsverschil weer. Ook is het een reactie op jullie eigenwijzigheid en soms arrogantie.

[FireDrunk]

Ik kan mij daar alleen maar bij aansluiten...

Wil je dit topic laten blijven bestaan: Leeg het dan, en stel in de startpost een nieuwe lijst met "Reeds besproken discussiepunten" en vat kort samen waar het over ging, en wat het standpunt is (KORT, dus in 2 regels).

Voor de rest, een duidelijk roadmap bovenin, en we kunnen keurig inhoudelijk verder discussieren zonder pijn naar elkaar.

Edit: of misschien beter, open een #2 en sluit deze ter referentie

[ Voor 8% gewijzigd door FireDrunk op 04-08-2014 17:18 ]

[CurlyMo]

Ter toevoeging van mijn vorige reactie misschien iets meer uitleg over mijn algemene (laatste) reacties. Neem nou die services kritiek die ik heb. Tot nu toe heb ik daar globaal de volgende reacties op gehad:

- Te veel werk
- Weinig meerwaarde
- Ga jij het allemaal omzetten?
- Niet beter dan wat we nu hebben
etc.

Op die manier maak je dus geen gebruik van een (toekomstige community). Nu wordt het erg zwart/wit. Alle verantwoordelijkheid van een eventuele merge wordt dan bij mij gelegd waardoor ik terugdeins. Weg constructief nadenken. Graag had ik een discussie gewild als:

1. Is het beter / slechter. Eerst dus inhoudelijk met elkaar van gedachten wisselen.
2. In geval van beter, dan komt het op een roadmap. Vervolgens kan je misschien ook iemand in de community vragen om het eventueel op zich te nemen / managen (in dit geval ik). Dat klinkt anders dan zeggen "ga jij in een zomer al die pakketten omzetten?". Is die persoon er niet, dan heeft het gewoon een lage prioriteit.
3. Als we dat overeen kunnen komen, dan kunnen we het hebben over de eisen en infrastructuur om in te werken.

Nu blijf ik het gevoel houden dat de service structuur gewoon niet ter discussie staat om de bovenstaande punten. Idem voor de migration manager, website, github, etc. Daarmee lijkt het middel meer aandacht te krijgen dan het doel, terwijl ik juist inhoudelijk over de beste implementatie van een bepaal doel zou willen meedenken waarin alles eindjes open liggen.

[ Voor 10% gewijzigd door CurlyMo op 04-08-2014 17:51 ]

[EnerQi]

Ik snap de services gedeelte van CurlyMo ook niet. De services binnen ZFSguru (noemen het even ZFSServices) werken naar behoren en soms nog wat manuele instellingen. Wat is er nu zo verkeerd aan deze opzet? Wat zijn de voordelen/nadelen van ZFSServices tegenover PKG van FreeBSD.

Overigens is het misschien veel handiger om te wachten t/m 2015 en vanaf dan die discussie te voeren. Dan is het werk zoals Jason/CiPHER het voor ogen hebben klaar en snappen we meer de filosofie achter het project. Na de discussie moet er misschien wel weer een deel herschreven worden, maar dan hebben we in iedergeval meer community dan nu (4 actieve posters inclusief CiPHER) .

[CurlyMo]

EnerQi schreef op maandag 04 augustus 2014 @ 17:54:
Ik snap de services gedeelte van CurlyMo ook niet. De services binnen ZFSguru (noemen het even ZFSServices) werken naar behoren en soms nog wat manuele instellingen. Wat is er nu zo verkeerd aan deze opzet? Wat zijn de voordelen/nadelen van ZFSServices tegenover PKG van FreeBSD.

Daar zou ik het best dus nog eens wat meer inhoudelijk over willen hebben, zodat iedereen het begrijpt

[ Voor 3% gewijzigd door CurlyMo op 04-08-2014 17:56 ]

[ikkeenjij36]

EnerQi schreef op maandag 04 augustus 2014 @ 17:54:
Ik snap de services gedeelte van CurlyMo ook niet. De services binnen ZFSguru (noemen het even ZFSServices) werken naar behoren en soms nog wat manuele instellingen. Wat is er nu zo verkeerd aan deze opzet? Wat zijn de voordelen/nadelen van ZFSServices tegenover PKG van FreeBSD.

Overigens is het misschien veel handiger om te wachten t/m 2015 en vanaf dan die discussie te voeren. Dan is het werk zoals Jason/CiPHER het voor ogen hebben klaar en snappen we meer de filosofie achter het project. Na de discussie moet er misschien wel weer een deel herschreven worden, maar dan hebben we in iedergeval meer community dan nu (4 actieve posters inclusief CiPHER) .

Beste EnerQi,ik zou ook wel mee willen discussieren maar ik begrijp wel een beetje waar jullie het over hebben na mjizelf maanden ingelezen en door schade en schande wijs geworden als enduser met weinig tot 0 ervaring in linux.
Nu draait mijn nas/server enkele weken stabiel en goed.
Enigste onduidelijkheid die ervoor mij is als user vwb de roadmap is(zie het niet als kritiek CipHer)
ja het is duidelijk voor wat ik ervan begrijp wat jullie ermee willen,maar aangezien er al verschillende keren dingen aangekondigd zijn en er tot nu toe nog gearriveerd zijn,maar er worden wel verwachtingen gewekt bij gebruikers en er komt maar niks.
Misschien is het beter/duidelijker als er eens per maand een melding komt van wat er zo goed als zeker af/klaar is en gereleased wordt en wat ervoor andere dingen nog tijd gaat kosten met verwachte aantal maanden/weken dat het gaat werken/draaien.
Ik pak als voorbeeld even gitlab,je kan het installeren als service maar dan krijg je een foutmelding dat het niet geinstalleerd is/gedeeltelijk en dat het niet gestart kan worden(duh ).
Als beginner denk je al gauw dat jezelf wat verkeerd heb gedaan of juist niet hebt gedaan.
Kleine puntjes maar geen kritiek mijnerzijds maar ik ken/kan niet zoveel bijdragen in de dingen zoals CurlyMo en FireDrunk.
Ik hoop dat jullie een beetje begrijpen wat ik bedoel als novice user en hoop zo toch ook mijn steentje bij te dragen aan deze discussie.

[FireDrunk]

Het is inmiddels alweer een maandje stil. Zijn er nog vorderingen?

[CurlyMo]

Hopen dat die OpenSource licentie er een keer gauw komt. Dan kunnen we vast aan de slag

[FireDrunk]

Meh, hopen dat er een (fatsoenlijke) GIT instance komt, zodat we kunnen forken

[CurlyMo]

De webgui op git zetten kan altijd al natuurlijk als de licentie er is

[Hakker]

Zoals het nu staat mag je zfsguru niet eens gebruiken. We zijn dus lekker illegaal bezig. Tweakers moet dus in princiepe elke link naar zfsguru verwijderen. Geen licentie is niets anders dan dat Jason iedereen persoonlijk moet goedkeuren om het te mogen gebruiken.

[Verwijderd]

FireDrunk schreef op vrijdag 12 september 2014 @ 14:12:
Het is inmiddels alweer een maandje stil. Zijn er nog vorderingen?

Jason heeft vorderingen gemaakt met de build infrastructuur. Bijna alle services kunnen nu geautomatiseerd gebuild worden. Het moeilijke werk is nu gedaan. De taken die open staan zijn het packagen van de services en het maken van de Gnome LiveCD. Ook zijn er nog wat issues met het onthouden van de port opties.

Waarschijnlijk deze maand kan de eerste geautomatiseerde build mét services van de band rollen.

Hakker schreef op vrijdag 12 september 2014 @ 18:07:
Zoals het nu staat mag je zfsguru niet eens gebruiken. We zijn dus lekker illegaal bezig.

Dat is ook de tactiek. Eerst zoveel mensen ZFSguru aansmeren en daarna een leger advocaten op jullie afsturen die flinke sommen geld gaan eisen.

FireDrunk schreef op vrijdag 12 september 2014 @ 14:29:
Meh, hopen dat er een (fatsoenlijke) GIT instance komt, zodat we kunnen forken

Is het daar allemaal om te doen? Jason zijn creatie een liberale licentie geven en daarna is hij niet meer nodig? Je bedoelt het waarschijnlijk niet zo, maar ik heb er wel problemen mee dat er zo gedacht kan worden.

Je opent ook een beetje mijn ogen... Zo zat ik te denken: wat zou je ervan vinden als ik een custom licentie voorstel waarbij enkele uitzonderingen zijn gemaakt? Bijvoorbeeld:

• Persoonlijk gebruik toegestaan.
• Commerciëel gebruik toegestaan, mits je de eindgebruiker bent.
• Verkopen van ZFSguru niet toegestaan; heb je een commerciële licentie voor nodig; dus leveren van ZFSguru op verkochte hardware NAS'en aan klanten bijvoorbeeld.
• Forken mag alleen als het project 12 maanden inactiviteit vertoont, of met toestemming van Jason.
• Persoonlijke forks voor eigen gebruik of binnen een bedrijf zijn wel toegestaan, zonder toestemming.

Ik ben opzich helemaal voor forken bij echte open source projecten. Neem nu OpenSSL. Dat is een zooitje en moet herbouwd worden; daarvoor is een LibreSSL project geforked die de code gaat uitdunnen en herschrijven. In dat geval is een fork zeer welkom. Ook de fork van XFree86 naar X.org was goed nadat de originele developers een GPL-onvriendelijke licentie worden gebruiken, terwijl XFree86 de fundering was onder de Linux desktop. BSD had er geen problemen van, maar dergelijk agressief gedrag tussen 'broedervolken' is zeer ongewenst.

Maar hoe zit het bij projecten wat door vrijwel één iemand is opgebouwd? Is het dan redelijk om alles mee te nemen en onder een ander project te hosten en dat de founder de middelvinger krijgt? Ik heb daar eigenlijk wel veel problemen mee. Het is Jason die nu het vuile werk doet. Er zit geen commerciële rommel of nagscreens in ZFSguru; het is pure en eerlijke software gratis voor iedereen te gebruiken. Open Source ook; maar nog zonder licentie die contributies netjes mogelijk maakt. Maar als dat een gangbare FOSS-licentie krijgt, is dat dan het einde van ZFSguru?

Er is nog niets besloten; maar ik heb wel invloed op Jason en Jason gaat de knoop doorhakken over de licentie zodra de developers website geopend wordt. Dat is ook een permanente keuze: als er eerst voor BSD/MIT-licentie gekozen wordt, dan is die keuze ook permanent. Het later wijzigen van de licentie neemt niet weg dat de eerder vrijgegeven code onder die licentie permanent te gebruiken zal zijn en dus ook te forken. Zo kan zomaar een ZFSguru-kloon worden opgezet die er als het ware vandoor gaat met de code.

Stel de core van het project zou een iets restrictievere licentie krijgen zoals ik hierboven voorstel, terwijl alle addons gangbare BSD/MIT/GPL licenties krijgen, is dat een acceptabel alternatief? Dan is de maker van de addon vrij om een eigen open source licentie te kiezen, terwijl de core van het project wel open source is maar nog wel mogelijkheden biedt aan Jason om bijvoorbeeld het project commerciële licenties te geven aan bedrijven die ZFSguru op hun NAS mee willen leveren. Zo kan Jason toch iets van inkomen tegemoed zien voor al het werk, terwijl het project voor zowel privé als commerciële eindgebruikers gewoon gratis blijft.

Hoe denken jullie over deze opzet?

[azerty]

Forken zou mogelijk moeten zijn zonder beperking, want de licentie moet sowieso overgedragen worden (dat staat toch zo in de meeste OSS licenties). Forken is niet alleen nuttig als je je eigen variant wilt bouwen (waar jij dus iets minder voor bent), maar ook om patches aan te kunnen dragen:

quote: https://guides.github.com...tributing-to-open-source/

Pull Request Pro Tips

* Fork the repository and clone it locally. Connect your local to the original ‘upstream’ repository by adding it as a remote. Pull in changes from ‘upstream’ often so that you stay up to date so that when you submit your pull request, merge conflicts will be less likely. See more detailed instructions here.

Als je dat dus niet zou mogen doen, of eerst toestemming moet krijgen van Jason voor je zou mogen forken, loop je het risico zaken te missen (imho).

Wat de licentie betreft: Ik zou ook een gelijkaardige constructie opzetten, immers wilt dat bedrijf dan geld verdienen met jouw werk, terwijl een consument/business enduser dat niet doet (misschien geld besparen in het geval van een business enduser).

[CurlyMo]

Ik verbaas me weer over je angst. Als ZFSGuru nou de meest innovatieve en wereldveranderende software zou zijn, dan zou ik me er inderdaad druk over maken. Verder krijgt Jason alle eer die hem toe hoort te komen. In de meest uitgebreide fork zou nog steeds zijn naam overal opduiken. Zorg vooral dat je een Copyleft licentie gebruikt en geen permissive.

Laat ik simpel zijn vanuit de (N=1) community kant. Ik ga niet bijdragen aan een project dat ofwel een permissive licentie heeft, of wel een te restrictieve licentie (zoals je eigen variant).

[FireDrunk]

Verwijderd schreef op zaterdag 13 september 2014 @ 01:56:
*knip*

Is het daar allemaal om te doen? Jason zijn creatie een liberale licentie geven en daarna is hij niet meer nodig? Je bedoelt het waarschijnlijk niet zo, maar ik heb er wel problemen mee dat er zo gedacht kan worden.

Je Sarcasme detector moet even geupgrade worden

Je opent ook een beetje mijn ogen... Zo zat ik te denken: wat zou je ervan vinden als ik een custom licentie voorstel waarbij enkele uitzonderingen zijn gemaakt? Bijvoorbeeld:

• Persoonlijk gebruik toegestaan.
• Commerciëel gebruik toegestaan, mits je de eindgebruiker bent.
• Verkopen van ZFSguru niet toegestaan; heb je een commerciële licentie voor nodig; dus leveren van ZFSguru op verkochte hardware NAS'en aan klanten bijvoorbeeld.
• Forken mag alleen als het project 12 maanden inactiviteit vertoont, of met toestemming van Jason.
• Persoonlijke forks voor eigen gebruik of binnen een bedrijf zijn wel toegestaan, zonder toestemming.

Ik ben opzich helemaal voor forken bij echte open source projecten. Neem nu OpenSSL. Dat is een zooitje en moet herbouwd worden; daarvoor is een LibreSSL project geforked die de code gaat uitdunnen en herschrijven. In dat geval is een fork zeer welkom. Ook de fork van XFree86 naar X.org was goed nadat de originele developers een GPL-onvriendelijke licentie worden gebruiken, terwijl XFree86 de fundering was onder de Linux desktop. BSD had er geen problemen van, maar dergelijk agressief gedrag tussen 'broedervolken' is zeer ongewenst.

Maar hoe zit het bij projecten wat door vrijwel één iemand is opgebouwd? Is het dan redelijk om alles mee te nemen en onder een ander project te hosten en dat de founder de middelvinger krijgt? Ik heb daar eigenlijk wel veel problemen mee. Het is Jason die nu het vuile werk doet. Er zit geen commerciële rommel of nagscreens in ZFSguru; het is pure en eerlijke software gratis voor iedereen te gebruiken. Open Source ook; maar nog zonder licentie die contributies netjes mogelijk maakt. Maar als dat een gangbare FOSS-licentie krijgt, is dat dan het einde van ZFSguru?

Waarom zou dat? Het is nou niet dat ZFSguru zo'n ontzettend goede naam heeft in mijn ogen... Stel er komt een "Project X - Gebaseerd op ZFSguru" zou dat voor mij eerder negatief zijn dan positief

Er is nog niets besloten; maar ik heb wel invloed op Jason en Jason gaat de knoop doorhakken over de licentie zodra de developers website geopend wordt. Dat is ook een permanente keuze: als er eerst voor BSD/MIT-licentie gekozen wordt, dan is die keuze ook permanent. Het later wijzigen van de licentie neemt niet weg dat de eerder vrijgegeven code onder die licentie permanent te gebruiken zal zijn en dus ook te forken. Zo kan zomaar een ZFSguru-kloon worden opgezet die er als het ware vandoor gaat met de code.

Stel de core van het project zou een iets restrictievere licentie krijgen zoals ik hierboven voorstel, terwijl alle addons gangbare BSD/MIT/GPL licenties krijgen, is dat een acceptabel alternatief? Dan is de maker van de addon vrij om een eigen open source licentie te kiezen, terwijl de core van het project wel open source is maar nog wel mogelijkheden biedt aan Jason om bijvoorbeeld het project commerciële licenties te geven aan bedrijven die ZFSguru op hun NAS mee willen leveren. Zo kan Jason toch iets van inkomen tegemoed zien voor al het werk, terwijl het project voor zowel privé als commerciële eindgebruikers gewoon gratis blijft.

Hoe denken jullie over deze opzet?

Veel van die licentie modellen zijn volgens mij niet zomaar aan elkaar te linken.. Dus je verhaal met plugins in een andere licentie vorm, geen idee of dat dat zomaar kan (maar ik ben geen licentie expert).

Ik zie vooralsnog vooral het meeste in een GPL licentie (in tegenstelling tot een BSD licentie).

Bij BSD mag je er commercieel geld mee verdienen, en de source daarna ook nog gesloten houden, zolang je alleen maar de originele maker noemt volgens mij... Bij GPL moet je alle direct gebruikte code open source maken en houden.

[CurlyMo]

CurlyMo dacht op zaterdag 13 september 2014 @ 01:56:
Ik ben opzich helemaal voor forken bij echte open source projecten. Neem nu OpenSSL ZFSGuru. Dat is een zooitje en moet herbouwd verbeterd worden; daarvoor is een LibreSSL project geforked die de de community wil graag de code gaatn uitdunnen en herschrijven verbeteren. In dat geval is een fork en dus een open source licentie zeer welkom.

[ Voor 3% gewijzigd door CurlyMo op 13-09-2014 13:54 ]

[FireDrunk]

Inderdaad, ZFSguru is in mijn ogen net zo'n zooitje als OpenSSL hoor...

[CurlyMo]

In geval van OpenSSL hebben we het wel over

CurlyMo schreef op zaterdag 13 september 2014 @ 10:16:
[...] wereldveranderende software [...]

Met alle respect gaat de vergelijking tussen OpenSSL en ZFSGuru dus redelijk mank Ten gunste van OpenSSL dus.

[Verwijderd]

@wsitedesign

Patches aandragen door lokaal te forken zou dan geen probleem mogen zijn. Je kunt immers met de GitLab service ook lokaal/thuis een fork van ZFSguru kunnen maken en dat lokaal managen en als je klaar bent met je mega-patch dat submitten. Bedrijven die hun eigen modified ZFSguru kloon willen hebben, kunnen evengoed forken.

Het meenemen van dezelfde licentie bij een fork is ook niet de issue; de issue is dat het werk van één iemand zo wel heel gemakkelijk naar een andere website met een andere naam kan worden gekopiëerd en zo verder gaan en Jason de vinger geven. Als dat zou gebeuren, waarom heeft Jason dan al zijn tijd en energie in ZFSguru gestoken; voor wat? Dat zou voor hem wel een nachtmerrie zijn. Ik wil hem - in tegenstelling tot sommigen - graag als de project lead houden en hem dingen laten ontwerpen waar hij goed in is. De beste coder is hij niet; dat kunnen andere mensen beter. Maar ik vind wel dat het zijn project moet blijven.

Het voorstel van een licentie hierboven zou dat mogelijk kunnen maken, terwijl het verder toch een aardig liberale licentie is met weinig beperkingen. Ook niet de beperking van copyleft die FireDrunk noemt zit er niet in. Dus code forken en wijzigingen privé houden mag ook; mits je die alleen intern gebruikt binnen je bedrijf of privésituatie.

wsitedesign schreef op zaterdag 13 september 2014 @ 10:10:
Wat de licentie betreft: Ik zou ook een gelijkaardige constructie opzetten, immers wilt dat bedrijf dan geld verdienen met jouw werk, terwijl een consument/business enduser dat niet doet (misschien geld besparen in het geval van een business enduser).

Dit stukje begrijp ik niet zo; kun je nog eens uitleggen wat je bedoelt?

@FireDrunk
Licenties maken kunnen elkaar raken zodra je ze gaat integreren. Specifiek heb je met een licentie te maken als jouw softwareproject library-functies gaat oproepen. Dus een ZFSguru .php file openen en daar een functie aanroepen, dan heb je met de licentie te maken van dat project. Het verschil tussen GPL en LGPL is hierin belangrijk bijvoorbeeld.

In de structuur die ik voorstel zou het gebruik van library functies in ZFSguru zonder beperkingen zijn. Je kunt dus een proprietary/non-permissive license plugin/addon hebben die functies van ZFSguru aanroept, deze kun je ook verkopen zonder wat met de ZFSguru licentie te maken te hebben. Daarin ben je helemaal vrij. De restrictie zit hem erin zodra je ZFSguru aanpast en het geheel buiten de ZFSguru website om wilt publiceren.

Je hebt het over geld verdienen. Ik heb er geen problemen mee als mensen geld verdienen met hun eigen addons die ze zelf publiceren. Maar ik zou er wel problemen mee hebben als al het werk van Jason door iemand uit handen genomen wordt en vrolijk verder gaat onder een andere naam.

Daarom mijn vraag: is de opzet die ik aandraag niet een goede middenweg? Het maakt mogelijk:

• Code onder een open source licentie aan te bieden, waarin iedereen aan de code kan bijdragen.
• Lokaal forken voor eigen gebruik of wat rommelen en vervolgens een grote patch submitten.
• Je eigen addons te maken onder een andere licentie; copyleft, permissive of zelfs proprietary.
• Dat Jason de leider blijft van het project, waar hij zoveel werk in heeft zitten.
• Mogelijkheid voor ons om ZFSguru te voorzien van een commerciële licentie voor bedrijven die ZFSguru willen verkopen op hun eigen NAS systemen geleverd aan klanten.

Volgens mij worden alle belangen hiermee evenwichtig geadresseerd. Natuurlijk zul je mensen hebben die het er niet mee eens zijn, maar misschien is dat de prijs die nodig is om ook de belangen van Jason te dienen.

Open source projecten zijn vaak community projecten, waar veel mensen aan hebben meegewerkt. Het resultaat daarvan is dan soort van 'public domain' - doordat iedereen eraan heeft meegewerkt, wordt het ook een beetje van iedereen. Maar hoe zit dat met een project wat door één iemand is geschreven en daar ook veel werk in heeft zitten? Is het dan redelijk als iemand zoiets mee kan nemen en onder een andere naam verder gaat? Hoe zou het voor Jason zijn als zoiets zou gebeuren? Zou hij dan nog de motivatie hebben om met zijn eigen project verder te gaan? Daar maak ik mij zorgen over.

Ik heb er zelf wel een goed gevoel over namelijk. Dat de structuur van de 'core' van ZFSguru iets meer restricties kent, maar nog wel open source is, terwijl de addons helemaal vrij zijn welke licentie je kiest, dat vind ik best een goede opzet. Op zijn minst kan met een dergelijke licentie-structuur geëxperimenteerd worden. Het kan altijd nog losser worden en de code als BSD vrijgeven in de toekomst, maar andersom is natuurlijk niet mogelijk.

[FireDrunk]

Er zijn toch genoeg basic licentiemodellen om uit te kiezen?

http://choosealicense.com/licenses/

Als ik jouw eisen lees, denk ik aan de Eclipse license.

http://choosealicense.com/licenses/epl-1.0/

[Verwijderd]

Het gebruiken van een bestaande licentie heeft de voorkeur. Maar aangezien er speciale wensen zijn en de bestaande licenties hierin niet voorzien, lijkt me een eigen licentie beter. Ik dacht zelf aan zoiets:

The GURU license

Lekker simpel en duidelijk; geen lange juridische teksten die voor de normale sterveling niet te lezen zijn.
Wel zou er nog een echt juridisch document moeten worden geschreven wat deze punten uitwerkt.

Hoe denken jullie hierover?

[CurlyMo]

, oftewel de Jason en CiPHER licentie.

[Verwijderd]

Als de licentie zo wordt geschreven dat hij ook door andere projecten kan worden gebruikt, zou hij zo in het lijstje passen van choosealicense.com.

Leuke naam ook: de GURU license.

[CurlyMo]

CurlyMo schreef op zaterdag 13 september 2014 @ 10:16:
Laat ik simpel zijn vanuit de (N=1) community kant. Ik ga niet bijdragen aan een project dat ofwel een permissive licentie heeft, of wel een te restrictieve licentie (zoals je eigen variant).

Mijn zwaaien had dus betrekking op deze zin.

[Verwijderd]

Gezien de vele bezwaren die jij hebt, is het misschien beter dat je je energie richt op andere projecten. De 'eis' dat wij een copyleft license moeten gebruiken gaat wel erg ver. Dan zou je zelf niet mee willen doen als wij een BSD, MIT of Apache license hadden gekozen. Dat hele GNU is een politieke license waarin bedrijven bestreden moeten worden. Ik geef daar weinig om; bedrijven doen maar wat ze willen zodra ze ons maar niet lastig vallen. Alleen het verkopen van de software zou aan banden gelegd kunnen worden, zodat Jason er zelf mogelijk nog iets aan kan verdienen door bedrijven die NAS-systemen verkopen met ZFSguru erop een commerciële licentie dienen af te sluiten.

Al met al vind ik dat alle belangen zo goed worden gebalanceerd, dus ik ben zelf wel positief over de basiskenmerken van de nieuw bedachte licentie.

[CurlyMo]

Jouw licentie: Alles wat ik maak / verbeter wordt overgedragen naar 2 personen.
Apache (en varianten) licentie: Alles wat ik maak / verbeter wordt overgedragen aan de wereld waarna ik er zelf niet veel meer aan heb. Aanpassingen hoeven namelijk niet openbaar gemaakt te worden dus ook de OpenSource community schiet er niet veel mee op.
GPL (en varianten) licentie: Alles wat ik maak / verbeter is ten behoeve van de 'mensheid'. Aangezien er een idealistisch oogpunt aan vast zit, wil ik dat anderen met hetzelfde oogmerk ook bijdragen aan dit ideaal. Geld verdienen met mijn werk, prima. Als ook de OpenSource community er maar beter van wordt.

Ik denk dan ook dat mijn N=1 een breder gedragen mening verwoord.

[Verwijderd]

Hoezo zou je er zelf niet veel aan hebben. Als je code aan Apache-project submit en het wordt in Apache opgenomen, dan heb je er toch zelf baat bij als je Apache gebruikt?

Dat GNU is vooral dat mensen niet willen dat bedrijven hun gang kunnen gaan. Dat is vooral politiek bedrijven. Richard Stallman noemt het niet voor niets een 'religie'. Daar heb ik weinig mee.

Als je iets aan de mensheid en dus ook de gehele mensheid wilt geven, dan maak je het public domain. Dan is het van iedereen en tegelijk van niemand. Zo ver wil ik niet gaan, maar de licentie die ik voorstel is meer permissive dan bijvoorbeeld GNU.

Als jij alleen aan GNU-licensed projecten wilt meewerken, is dat uiteraard jouw keuze. Maar wat hier centraal staat is wat goed zou zijn voor het ZFSguru project, op middellange en lange termijn.

[DaCoTa]

Ik zie niet in waarom de Eclipse licentie niet werkt?

[CurlyMo]

Verwijderd schreef op dinsdag 16 september 2014 @ 21:01:
Hoezo zou je er zelf niet veel aan hebben. Als je code aan Apache-project submit en het wordt in Apache opgenomen, dan heb je er toch zelf baat bij als je Apache gebruikt?

Omdat een persoon die graag een andere / betere webserver wil maken niet kan leren van wat ik in Apache heb gesubmit. Iedereen gaat het wiel dus opnieuw uitvinden*.

Dat GNU is vooral dat mensen niet willen dat bedrijven hun gang kunnen gaan. Dat is vooral politiek bedrijven. Richard Stallman noemt het niet voor niets een 'religie'. Daar heb ik weinig mee.

Hoe verklaar je dan de populariteit van Apple? Vrijwel allemaal opensource wat ze daar doen...

Als je iets aan de mensheid en dus ook de gehele mensheid wilt geven, dan maak je het public domain. Dan is het van iedereen en tegelijk van niemand. Zo ver wil ik niet gaan, maar de licentie die ik voorstel is meer permissive dan bijvoorbeeld GNU.

Als jij alleen aan GNU-licensed projecten wilt meewerken, is dat uiteraard jouw keuze. Maar wat hier centraal staat is wat goed zou zijn voor het ZFSguru project, op middellange en lange termijn.

Dat zeg ik niet. Ik zeg alleen dat ik niet wil dat mijn code alleen maar in privé forks of in ZFSGuru te gebruiken mag zijn. Ik wil dat iedereen die mijn verbeteringen ziet er wat van kan leren, mag gebruiken en dus niet het wiel opnieuw uitvind*.

Stel dat ik jullie services build systeem ombouw zodat hij pkgNG services gaat maken i.p.v. wat jullie nu doen. Dan is het toch van de gekke dat dat niet in andere projecten gebruikt mag worden?!?

*waar doet me dat aan denken

[Verwijderd]

Ik begrijp wel je bezwaren en dat laatste punt van je vind ik heel redelijk en valt zeker wat voor te zeggen. Maar bedenk het volgende:

• Ik probeer een licentie te vinden die zowel recht doet aan de belangen van Jason, als de belangen van de gebruikers/community. Daar probeer ik een balans in te vinden door middel van afweging van belangen. Een model wat iedereen 100% naar tevredenheid bedient, bestaat denk ik niet.
• Jason wil dat zijn project ook zijn project blijft. Tot nu toe is alles ook door hem geschreven en ontworpen, en ik heb er tot noch toe maar een klein aandeel in. Dan is het ook redelijk dat Jason een grotere stem heeft dan de rest van de community.
• De licentie die ik voorstel geldt uitdrukkelijk voor de 'core' van ZFSguru. Addons en dergelijke mogen hun eigen licenties hebben. Dus als jij iets wilt bouwen voor ZFSguru wat je zelf ook wilt gebruiken en liefst gewoon onder je GPL v3 copyleft wilt vrijgeven; dan kan dat gewoon! Alleen wijzigen aan de kern van ZFSguru zouden dan wel onder de nieuwe licentie vallen. Daarmee geef je Jason ook toestemming om die code te verkopen aan bedrijven die ZFSguru willen leveren op hun NAS. Als je dat niet wilt: doe dan geen contributies aan de core maar enkel aan addons waar je je eigen licentie kunt kiezen.
• Het includen van ZFSguru code blijft toegestaan, ook als je een proprietary license kiest. Een soort van LGPL dus. Het is dus zeker niet een heel restrictieve licentie.
• Infrastructuur die je zelf opbouwt, valt sowieso niet onder de licentie. Zo kun je je eigen 'master server' met eigen packages en meuk draaien als je dat wilt. Daar zal waarschijnlijk ooit een service voor komen waarmee je dat makkelijk kunt doen. Dan gebruik je niet de master servers van ZFSguru maar je eigen spul. Daarmee kun je doen wat je wilt en heb je met de GURU license niets te maken.

Het is vast niet zoals jij het zelf had gedaan. Maar zoals ik zeg: het is een afweging van belangen. Ik vind het heel gebalanceerd waarbij zowel de wensen/belangen van Jason worden gediend, alsmede die van de community. Vooral dat de kern van ZFSguru vrij klein blijft en alle spannende dingen in de addons gebeuren, schept ook veel vrijheid voor anderen om hun code aan te bieden op een manier waar zij zich fijn bij voelen. Vrijheid, blijheid!

[CurlyMo]

Verwijderd schreef op dinsdag 16 september 2014 @ 21:25:
Alleen wijzigen aan de kern van ZFSguru zouden dan wel onder de nieuwe licentie vallen. Daarmee geef je Jason ook toestemming om die code te verkopen aan bedrijven die ZFSguru willen leveren op hun NAS. Als je dat niet wilt: doe dan geen contributies aan de core maar enkel aan addons waar je je eigen licentie kunt kiezen.

De belangrijkste bijdragen die de mensen hier zouden willen doen gaan juist over de core van ZFSGuru. Dat is een beetje dezelfde discussie als de mixed licenties tussen shared / static libraries en je core programma. Het verbeteren van het automatische build systeem valt daar naar mijn idee ook onder. Als je daar community input voor wil dan zou het mooi zijn als je mijn bezwaren kan teckelen in je GURU licentie.

[Verwijderd]

Als jouw grootste bezwaar is dat je eigen code ook voor andere doeleinden wilt kunnen gebruiken, waarom zou dat in conflict zijn met wat Jason en ik willen?

Kun je dan niet gewoon jouw code onder GURU license vrijgeven, terwijl je als copyright holder het óók onder GPLv3 uitgeeft? Of wat je ook wilt...

Je kunt ZFSguru zelf dan niet onder GPLv3 gebruiken. Maar jouw eigen contributies kunnen wel meerdere licenties krijgen. Ik zie niet in waarom dat een conflict zou moeten zijn. Ik denk ook niet dat Jason er problemen mee heeft als contributies buiten de GURU license een andere license krijgen. Wel dien je Jason voor contributies aan de core toestemming te geven het ook onder een andere (commerciële) license uit te brengen. Ongeveer zoals bij MySQL en ook andere projecten gebeurt volgens mij.

Maar je blijft zelf copyright holder van je eigen werk; dus het staat jou vrij om je eigen code elders vrij te geven onder een andere licentie, zoals op GitHub.

[CurlyMo]

Verwijderd schreef op dinsdag 16 september 2014 @ 21:37:
Kun je dan niet gewoon jouw code onder GURU license vrijgeven, terwijl je als copyright holder het óók onder GPLv3 uitgeeft? Of wat je ook wilt...

Omdat niet alle licenties zomaar verenigbaar zijn.

Je kunt ZFSguru zelf dan niet onder GPLv3 gebruiken. Maar jouw eigen contributies kunnen wel meerdere licenties krijgen. Ik zie niet in waarom dat een conflict zou moeten zijn.

Opnieuw, dat hangt van de licenties af.

Ik denk ook niet dat Jason er problemen mee heeft als contributies buiten de GURU license een andere license krijgen. Wel dien je Jason voor contributies aan de core toestemming te geven het ook onder een andere (commerciële) license uit te brengen. Ongeveer zoals bij MySQL en ook andere projecten gebeurt volgens mij.

Dat moet ik dan maar eens gaan uitpluizen als de juridische tekst er is.

Maar je blijft zelf copyright holder van je eigen werk; dus het staat jou vrij om je eigen code elders vrij te geven onder een andere licentie, zoals op GitHub.

Hier zit nu juist de crux. Ik kan natuurlijk een buildsysteem niet gaan verbeteren als ik niet de mogelijkheid heb om het (op github) te forken.

Misschien is het ook goed om de verschillende onderdelen van ZFSGuru te beschrijven als zijnde core / niet-core:
- Kernel
- webGUI
- Services
- Build systeem
- ...

[Verwijderd]

Core:
- ZFSguru web-interface

Niet core:
- Systeem
- Services (addon)
- Infrastructuur (master servers)

Licenties zijn inderdaad niet zomaar verenigbaar; Je kunt niet zomaar GPL-code een andere licentie geven als dit in conflict is met de bepalingen van de GPL. Máár dat geldt enkel voor niet-copyright holders. Jij als copyright holder mag het eerst als GPLv3 uitgeven en daarna onder MIT. Een ander iemand - die geen copyright holder is - mag dat niet. Daarin zit hem het verschil.

[CurlyMo]

Verwijderd schreef op dinsdag 16 september 2014 @ 21:46:
Licenties zijn inderdaad niet zomaar verenigbaar; Je kunt niet zomaar GPL-code een andere licentie geven als dit in conflict is met de bepalingen van de GPL. Máár dat geldt enkel voor niet-copyright holders. Jij als copyright holder mag het eerst als GPLv3 uitgeven en daarna onder MIT. Een ander iemand - die geen copyright holder is - mag dat niet. Daarin zit hem het verschil.

Mits je niet code van andere in je project hebt opgenomen. Dan heb je meerdere copyright holders.

[Verwijderd]

Uiteraard kun je niet de GURU-license code die Jason heeft geschreven, onder GPL vrijgeven. Maar dat spreekt voor zich. Anders betekenen licenties niets meer als je het eigenhandig kunt veranderen.

Maar ik dacht juist dat jouw bezwaar was dat je je eigen creaties ook voor andere doeleinden wilt kunnen gebruiken, dan alleen voor ZFSguru. Of althans die mogelijkheid open houden. Dat is denk ik geen probleem.

[Room42]

Ik ben het met CurlyMo eens dat zo'n beperkte licentie als jullie nu voorstellen niet erg motiverend werkt om mee te helpen. Het voelt niet echt welkom en je bent als het ware in dienst van ZFSguru.

[Verwijderd]

Welkom voelen zal meer afhangen van de praktijk hoe de sfeer is, dan van de licentie. Ik vind het wel meevallen qua restricties. Zoals ik al zei: het is meer permissive dan GPL. Maar het is wel meer restrictief dan BSD/MIT.

Ook een belangrijk punt vind ik dat het enkel geldt voor de core van ZFSguru. Het idee is vooral dat meewerken aan ZFSguru betekent dat je buiten de core werkt. Het is namelijk niet de bedoeling dat ZFSguru zelf een heel bloated iets wordt wat alsmaar meer uitdijt. Maar meer een slanke basis waarop de extra functionaliteit op inhaakt.

Er zullen ongetwijfeld mensen zijn die harde eisen stellen aan welke licentie ze hun code willen vrijgeven. Maar dat moet dan maar de prijs zijn. Als genoeg mensen bijdragen aan ZFSguru er dual-license contributies doen, dan is het een kwestie van tijd voordat de Jason-onderdelen herschreven kunnen worden en het project wel onder GPL of wat dan ook kan worden vrijgegeven. Maar nu is het gewoon het product van Jason, dus heeft hij er ook het meest over te zeggen.

Wat ik nou zo graag zou willen is dat Jason de kans krijgt zijn visie goed uit te werken, want de vele plannen zijn allemaal erg mooi en wat hij tot nu toe al heeft bereikt vind ik ook heel knap voor een enkeling die zonder enige vergoeding dit alles naast zijn reguliere job doet. Gun zo'n iemand dan ook dat hij baas over zijn eigen project blijft. Ik zou het echt heel naar vinden als Jason er mee op zou houden als anderen er met zijn project vandoor gaan...

De licentie staat jullie niets in de weg om ermee te doen wat je wilt. Het enige wat niet kan is Jason zijn code onder GPL vrijgeven en als zodoende gebruiken. Nou... is dat nou zo erg? Belemmert dat nou wat jullie zouden willen?

Zoals ik al zei; volgens mij doet de voorgestelde licentie recht aan de belangen die er spelen. En als het echt niet blijkt te werken dan staat het Jason altijd vrij om een andere licentie te kiezen. Dat kan altijd nog...

[Verwijderd]

Om nog even op het punt motivering en 'welkom voelen' te reageren:

Wie denken jullie eigen dat Jason is? Een brute dictator die zijn wil ten koste van anderen wil opleggen ofzo? Ik heb nu een tijd lang met hem gewerkt en ken hem redelijk. Hij is een ietwat verlegen persoon die erg creatief is op tal van gebieden en vooral out-of-the-box denkt. Hij staat erg open voor input van anderen, maar vind het lastig als mensen hem pushen om dingen te doen die hij eigenlijk niet wilt.

In een aantal gebieden is hij minder goed. Die zijn in dit topic ook ter sprake gekomen. Ons idee was om hierop in te gaan in de State of the Project hetgeen ook gebeurd is. De belangrijkste punten zijn genoemd en op vrijwel ieder punt zijn concrete plannen voor verbetering gepresenteerd. Het is niet alsof Jason niet wilt luisteren naar goede adviezen.

Maar het is wel zo dat Jason graag de kans wilt krijgen om zijn eigen creativiteit uit te werken. Daarom is hij zijn eigen project begonnen in plaats van contributies te doen aan bestaande projecten als FreeNAS en NAS4Free, waarin zijn bewegingsvrijheid beperkt is. Met zijn eigen project kan zijn visie en zijn filosofie in vrijheid uitvoeren. Dat lijkt ook vrij goed te gaan aangezien ZFSguru door anderen wordt gewaardeerd, ook al is het op tal van punten nog niet zover als de zusterprojecten die met veel meer mensen worden ontwikkeld en ook een commerciëel bedrijf achter zich hebben.

Jason heeft jarenlang gewerkt zonder enige vergoeding, enig inkomen, donaties of hulp, en zijn product gratis en zonder bullshit (malware, adware, nagscreens) aangeboden. Wat zegt dat over zijn karakter? Een bruut die enkel zijn eigen belangen dient? Kom nou toch! Hij is juist heel erg van goede wil!

Wat ik zo jammer vind is dat het hier lijkt alsof Jason als een obstakel gezien wordt, en niet als aanwinst. Ik probeer nu juist het zo te organiseren dat Jason doet waar hij goed in is, en alle belangen en wensen van iedereen zo goed mogelijk tegen elkaar worden afgewogen. Die vrijheid heeft hij mij ook gegeven. Hij doet bijna alles wat ik wil en stemt vrijwel overal mee in. Maar dat is ook omdat hij weet dat als hij ergens een probleem mee heeft, dat ik hem daarin ook vrij laat. Tenzij hij echt onredelijk zou zijn, maar zo heb ik hem nog nooit meegemaakt. Hooguit moedeloos een enkele keer toen alle shit over hem heen kwam toen hij twee maanden absent was door persoonlijke problemen met zijn familie. Pffff. Over respect gesproken.

Als nou straks alle vitale onderdelen van het ZFSguru project op zijn plaats vallen. Dus nieuwe website, nieuw forum, gitlab voor contributies en bugtracker, nieuwe master servers, build infrastructuur, enzovoorts. Dan kan het werk volgens mij beginnen. En dan doen we dat met een duidelijke licentie waarin een paar dingen zijn die Jason graag wilt; namelijk dat niet iedereen copy-paste kan doen en er vandoor gaat met de buit, terwijl alle andere belangen zo goed als mogelijk worden bediend. Dat is helemaal niet onredelijk in deze situatie, waarbij hij al het werk heeft gedaan. Ook het feit dat hij de mogelijkheid open wilt laten om ooit te gaan verdienen aan commerciële licenties van ZFSguru aan bedrijven die NAS systemen willen leveren, vind ik niet onredelijk.

Hoe de sfeer straks zal zijn zodra contributies mogelijk worden op een fatsoenlijke manier, dat zal de tijd leren. Maar bedenk dat ik in dit topic behoorlijk wat kritiek heb gekregen op vrijwel alles, en toch altijd netjes antwoord heb gegeven en mijn best heb gedaan om de kritiek serieus te nemen en naar oplossingen te zoeken. Dat betekent niet altijd dat ik letterlijk doe wat er gezegd wordt; maar ik ben natuurlijk niet jullie slaaf. Ik probeer juist Jason en de wensen van de (toekomstige) community, deels door jullie vertegenwoordigd, te verenigen qua belangen. En volgens mij lukt dat best goed!

Bedenk nou eens wat Jason voor jullie kan betekenen, zodra hij in zijn ideale rol zit van Project Architect. Daarin bedenkt hij de grote structuren van het project, terwijl het aan de anderen is om te werken aan onderdelen die open staan, of juist hun eigen addon projecten. Want daar gaat toch echt alles om draaien in de toekomst. ZFSguru is al bijna af. Het afbouwen van de missende onderdelen, verfijnen/polishen en verbeteren van de kwaliteit van de code zijn nog openstaande taken. Maar dan is de core zo goed als af. Dan begint het project pas echt met alle modules die op elkaar inwerken. Jason heeft daar hele mooie ideeën voor en ik hoop dat dat een succes gaat worden. Wellicht dat tegen die tijd er helemaal niet zo moeilijk gedacht worden over de zogenaamde 'restricties' die worden opgelegd. Elk project heeft zijn regels en richtlijnen waar je je aan moet houden. Linus Torvalds moet je volgens mij naast het voldoen aan de GPL ook nog een verklaring laten tekenen. Ik bedoel: wat is nou echt het probleem? Alles wat jullie willen kan toch? Behalve die dingen waar Jason ongelukkig van zou worden: het copy-pasten van zijn project en hem de vinger geven. Dat moet je ook niet willen, dat is niet redelijk. Go with the flow!

Amen.

[Room42]

Ja, ik zou zo'n project zo groot mogelijk proberen te krijgen. Niet qua featureset maar qua publiek. En ik denk dat forken daarbij hoort. Zeker als de licentie zo is dat patches teruggehaald kunnen worden (dus geweldige ideeën van derden terug naar het hoofdproject), kan dit enorm groot worden. En dan houdt Jason toch de regie over zijn eigen kindje terwijl anderen met hun eigen visie los kunnen.

En als je dat goed organiseert, blijft ZFSguru superieur aan de rest en zal men altijd daar beginnen.

Maar misschien wil hij eerst een goede basis leggen voordat ie zover is, dat kan ik nog begrijpen. Maar hoe lang houd je de developers die staat te springen warm en geduldig?

[Verwijderd]

Door aandacht te schenken aan hun belangen en iedereen ruimte te geven om zijn of haar creativiteit te ontplooien. Maar dus ook die van Jason. Ik voorzie daarin een grote toekomst als het een kans krijgt.

En wie weet heb je gelijk en is na twee jaar Jason om en gaat het project een echt community-driven project worden. Zou zomaar kunnen. Maar nu beginnen met deze licentie is denk ik best verstandig. Hou je Jason binnenboord en worden zijn zorgen ook serieus genomen, terwijl de rest volgens mij prima ruimte krijgt om hun ambities te verwezenlijken. Want als die addons echt van de grond komen kan ZFSguru een heel leuk project worden. Ik heb er in elk geval wel zin in.

Dus: geef het een kans. Later kan het altijd nog veranderd worden. Laten we gewoon beginnen en kijken waar het schip strandt. Vanaf 2015 verwacht ik dat het echt mogelijk wordt om mee te helpen. Dan is al het zware werk zoals de build infrastructuur ook achter rug, zijn de nieuwe servers er, nieuwe site. Dan spreekt het ook meer aan voor anderen om er aan mee te werken omdat er meer leven in de brouwerij zit; of althans meer zichtbaar is. Dan kan het echte werk beginnen!

[FireDrunk]

1) Ik heb niets tegen Jason (persoonlijk), en ik heb er niets tegen dat hij graag de regie houdt over zijn eigen Project. Simpel.

2) Waar ik wel wat op tegen heb, is dat mijn eigen werk (of het nou voor System, Core, Website, Vertaling, Wiki, i-dont-give-a-shit) is, gebruikt wordt om geld te verdienen.

Ik heb 2 stromen in mijn leven:
Mijn day-job waar ik werk voor een ander doe, en daar voor betaald krijg, en al mijn werk van mijn werkgever wordt (tot op zekere hoogte, maar you-get-the-point...)

Mijn hobby waarin ik anderen help (Tweakers, Persoonlijk, V&A, wat knutselprogrammeerwerk) met hun IT uitdagingen. Dit is voor mij leerzaam, en helpt anderen.

Ik wil nadrukkelijk *NIET* dat bedrijven daar geld aan kunnen verdienen.... NOOIT...

Simpel gezegd volgens jouw filosofie, kan ik dus niet aan ZFSguru werken (behalve addons). Want jullie kunnen het verkopen (licenseren w/e) aan bedrijven.

Als je dat wil, moet je even mijn werkgever bellen, en mij inhuren voor 60,-/h. Dan kom ik graag elke ochtend met mijn laptopje aan ZFSguru werken

Kleine edit: Enige nuancering is nodig, je mag best geld verdienen door support te verkopen op ZFSguru, daar heb ik persoonlijk geen moeite mee.. Dan verdien je niet direct geld aan mijn werk, maar aan support op mijn werk. Daar kan ik nog mee leven.

/persoonlijkerant
--

Objectief:
Wat je je denk ik niet moet hopen/dromen is dat bedrijven licentiegeld gaan betalen voor een applicatie die gebruikers zelf gratis zouden mogen installeren... Wat is het voordeel voor een bedrijf om ZFSguru in licentie te nemen en door te verkopen aan eindgebruikers? Ze kunnen zelf addons maken en meeleveren, dat mag al met het licentiemodel wat jij noemt? Ze zeggen gewoon dat de kosten van de NAS die ze kopen voor de hardware zijn, en niet voor ZFSguru.


TL;DR;
Wat is voordeel voor een bedrijf om in de core te mogen wroeten en dat weer door te mogen verkopen aan eindgebruikers, als ze alle addons (dat lijkt mij de meerwaarde voor een bedrijf) sowieso al zelf mogen meeleveren?

[ Voor 6% gewijzigd door FireDrunk op 17-09-2014 07:55 ]

[Verwijderd]

Wat is nu precies het probleem dan voor jou?

• Dat Jason geld verdient aan wat hij zelf geschreven heeft?
• Dat Jason geld verdient aan het geheel dus inclusief contributies van anderen?
• Dat bedrijven geld verdienen aan ZFSguru?
• Dat bedrijven geld verdienen aan jouw contributies?

Als je niet wilt dat bedrijven geld verdienen aan wat jij geschreven hebt, dan moet je denk ik sowieso niet bijdragen aan open source projecten. Want als je een patch submit naar Apache dan kunnen bedrijven ook daar indirect geld aan verdienen.

Dat hele GNU gebeuren is vooral om een politieke oorlog tegen bedrijven te voeren. Persoonlijk kan het mij verrotten wat bedrijven doen of laten. Het gaat mij om de belangen die Jason en ik hebben. Als bedrijven ZFSguru in hun kont willen steken, gaan ze hun gang maar. Zolang ze de belangen van Jason maar niet schaden.

Als het punt is dat Jason persoonlijk baat gaat krijgen van contributies van anderen; tja. Is het niet redelijk na al het werk dat hij voor niets heeft gedaan? Mag hij helemaal niets terugkrijgen voor zijn creaties? Geld vragen voor ZFSguru zou een horror zijn. Met dit model blijft ZFSguru gewoon gratis voor privé én voor commercieel gebruik en blijft het ook open source, terwijl er wel mogelijkheden bestaan voor hem om het ooit meer te laten worden dan alleen hobby. Zeker op de lange termijn kan dat alleen maar betekenen dat hij betrokken blijft bij het project en het zijn volle aandacht kan geven.

Als dat niet zou mogen van jou; wat is dan het alternatief? Opgeven dat het ooit iets meer wordt dan hobby? Er zijn toch genoeg open source projecten die ook commercieel succes halen terwijl de code zelf gewoon open source is? Waarom zou dat met ZFSguru niet kunnen? En daar speelt natuurlijk hetzelfde punt dat anderen kunnen profiteren van jouw contributies. Maar dat moet je dan maar voor lief nemen denk ik. Als jij er full-time aan gaat werken voor meerdere jaren, dan is het een ander verhaal. Maar gewoon wat contributies waar je zelf ook van profiteert omdat het in de main ZFSguru code komt, wat is het probleem?