Discussie over de toekomst van ZFSguru

[CurlyMo]

@EnerQi
http://portrix-systems.de...-incremental-sendreceive/

Andere optie:
pkg install mc

[ Voor 30% gewijzigd door CurlyMo op 07-01-2014 19:16 ]

[FireDrunk]

iig geen pkg_add gebruiken... Hooguit pkg.
pkg_add is depricated.

[Verwijderd]

mc (Midnight Commander; een soort Norton Commander-kloon) zit al in de shell-utilities service addon.

De oude package manager 'pkg_add' is unsupported op moderne ZFSguru releases; je moet geen pkgNG en pkg_add door elkaar gebruiken. De nieuwe manier is pkgNG. Dat is vrijwel backwards compatible, alleen ipv
'pkg_add' gebruik je dan 'pkg add' dus zonder spatie.

[ Voor 56% gewijzigd door Verwijderd op 07-01-2014 19:24 ]

[CurlyMo]

Ik zit nog op 9.0-release en daar werkt pkg niet op

[Verwijderd]

Kun je via portstree ook installeren.

/usr/ports/ports-mgmt/pkg
http://www.freshports.org/ports-mgmt/pkg/

[EnerQi]

Bedankt voor de reacties maar als niet-IT'er praten jullie in raadsels . Nu kan ik met de bovenstaande opties natuurlijk een poging wagen om het werkend te krijgen maar daarom hoop ik op die wiki en de teksten om dit gecontroleerd te installeren .

In de werkfunctie die ik zit, ben ik de "IT'er" die niet snapt dat andere de tools niet gebruiken waarvoor ze bedoeld zijn. Exact hetzelfde waar ik nu tegenaan loop met FreeBSD (en andere niet-windows gebaseerd systeem). Onmacht, bang, niet weten dat de oplossing er is, geen makkelijke manier om het te benaderen etc.

DE reden om dus ZFSguru te gebruiken, ik heb geen idee wat ik aan het doen ben. (en de documentatie die er hopelijk bijkomt)

ik ben overigens niet vies van proberen

[CurlyMo]

Verwijderd schreef op dinsdag 07 januari 2014 @ 20:19:
Kun je via portstree ook installeren.

/usr/ports/ports-mgmt/pkg
http://www.freshports.org/ports-mgmt/pkg/

pkg werkt wel, maar de repository bestaat niet (meer):

code:

Updating repository catalogue
pkg: http://ftp-archive.freebsd.org/pub/FreeBSD-Archive/old-releases/amd64/9.0-RELEASE/packages/All//repo.txz: Not Found

[FireDrunk]

Om maar weer eens olie op het vuur te gooine...

Wat een waardeloze template engine is het toch....

Jullie sluiten ook al je files met ?>

Dit is echt NIET slim... Als er na die ?> nog een newline staat wordt deze gewoon opgestuurt.
Je kan veel beter php gewoon niet sluiten.

[ Voor 46% gewijzigd door FireDrunk op 07-01-2014 22:02 ]

[Verwijderd]

Wat een waardeloze template engine is het toch....

Dat gaat nog leuk worden straks.

Maar serieus, ik vind dus juist heel gaaf, snap eigenlijk niet wat jij er kut aan vindt.

Over php closing tags, wel goede tip zal het doorgeven. Maar de conventie is natuurlijk ook een close-tag zonder newline-character.

[FireDrunk]

Je opent eerst een tabel, daarna begin je de template tags met de naam van de tabel.
De template tags betekenen dus niet wat de naam zegt:

Er staat: %%TABLE_SERVICESLIST%%

Er moet eigenlijk staan: %%TABLE_SERVICELIST_CONTENT%%

In reguliere template engines word het genereren van de table namelijk ook door de template engine gedaan, en gebruik je die tags om op die plek de table zelf te generen.

Niet echt duidelijk dus, (het werkt wel...)

[CurlyMo]

Als mensen toch de webgui gaan herschrijven / aanpassen. Doe dat dan gelijk goed via javascript. Dan kan het makkelijk over naar websockets / ajax.

[Verwijderd]

Tabellen in de page engine zijn er gewoon voor recursie. De .php script levert een array aan met meerdere rows, en voor elke row wordt alles tussen %%TABLE_BLA%% en %%TABLE_BLA_END%% geprint met variabelen uniek voor elke row.

Dat hoeft dus niet altijd voor een HTML table gebruikt te worden; simpel voorbeeld is:

code:

<select name="selectbox">
%%TABLE_SELECTBOX%%
<option value="%%SELECTBOX_VALUE%%">%%SELECTBOX_NAME%%</option>
%%TABLE_SELECTBOX_END%%
</select>

Uiteindelijk wordt dit omgezet in:

code:

<select name="selectbox">
<option value="val1">name1</option>
<option value="val2">name2</option>
<option value="val3">name3</option>
</select>

[FireDrunk]

Ik begrijp het principe wel, alleen klopt de naamconventie niet. Je maakt zelf al een fout.
Je noemt een herhalende waarde TABLE? Waarom? Dat is misleidend en bad-practice als programmeur.

En waar zet ik error reporting aan? error_reporting(E_ALL); werkt niet...

[ Voor 17% gewijzigd door FireDrunk op 07-01-2014 22:30 ]

[Verwijderd]

Een ZFSguru 'TABLE'.

en zo vreemd is het niet. De structuur (multidimensional array) is in principe een tabel. Een row met colums met namen en meerdere values per row. Dat is de essentie van een tabel.

Maargoed, we kunnen hier lang over discussiëren. Ik vind het allemaal niet zo spannend. De page engine is vind ik juist mooi ontworpen. Pages lekker bij elkaar en alles is netjes gescheiden:

• .page voor de HTML-code
• .css voor de CSS-code, alleen actief voor die pagina (bovenop de algemene CSS code)
• .js voor Javascript-code, alleen actief voor die pagina
• .php voor de PHP-code die de data aanlevert om de passieve .page file te parsen

Bij Mesa is het door de rewrite-all rule heel simpel geworden om pages toe te voegen. Edit 'pages/test/foobar.page' in de docroot en je hebt al HTML-code zichtbaar. Zet er een .php file bij en je kunt variabele data aanleveren met allerlei functies uit libraries of van jezelf. .js en .css worden automatisch opgepikt. Ik vind dat wel lekker werken. Ook weet je waar de code staat voor welke pagina, geen hele tree die je moet leren kennen ofzo. Je hebt libraries (/includes) en je hebt pagina's. Kortom, what's the fuzz about?

Tip: edit /usr/local/etc/php.ini en pas daar aan, inclusief display_errors wat ik zelf ook gebruik. Weet niet of je 'service lighttpd restart' dient te doen.

[ Voor 6% gewijzigd door Verwijderd op 07-01-2014 22:43 ]

[CurlyMo]

Verwijderd schreef op dinsdag 07 januari 2014 @ 22:40:
Maargoed, we kunnen hier lang over discussiëren. Ik vind het allemaal niet zo spannend.

Dit vind ik wel een tekenend voorbeeld van wat je eerder beschreef als jullie logica die verder door weinig mensen te begrijpen is. In de context van HTML is een table simpelweg een bepaald HTML element, niet een php variabel type.

[Verwijderd]

Het is een concept in de theme engine. Het echte punt is dat er geen documentatie voor is. Maar dan klopt ook mijn stelling dat ZFSguru een project van het type is wat lastiger is voor derde partijen om aan bij te dragen. In elk geval in dit stadium van het project.

[CurlyMo]

Verwijderd schreef op dinsdag 07 januari 2014 @ 23:24:
Het echte punt is dat er geen documentatie voor is. Maar dan klopt ook mijn stelling dat ZFSguru een project van het type is wat lastiger is voor derde partijen om aan bij te dragen. In elk geval in dit stadium van het project.

FireDrunk en ik geven aan dat dit voorbeelden zijn van onbegrijpelijke logica. Daar gaat documentatie niks aan veranderen. Dat past bij wat ik eerder aangaf, voor community bijdrage moet je die community ook faciliteren. Dat betekent ofwel begrijpbare manier van code schrijven ofwel een kei van een plugin systeem zodat mensen je basis code nooit in hoeven te duiken.

[Verwijderd]

Dat laatste is ook in feite de bedoeling. Maar als alle problemen opgelost zijn door TABLE te veranderen naar LIST... Kijk ik krijg meer het gevoel dat de manier van denken niet aansluit. Misschien is dat zo, maar dat hoeft nog geen zwakte te zijn. ZFSguru is geen standaard project volgens standaard conventies. Maar vrij rebels en uniek van opzet met een eigen stijl. Dat kan afschrikken of juist bevallen. Maar zo zwart-wit als misleidend kun je het niet noemen.

Gevolg is wel - zoals ik al eerder in deze discussie meldde - dat het voor ZFSguru in dit stadium lastiger is om hulp van anderen te verwachten, door alle barrières die er zijn. CurlyMo, jouw betoog is heel helder. Jij zegt in feite hoe minder barrières er zijn, des te meer commits er komen. Maar ik vraag mij af of het voor wat ZFSguru betreft nu wel de juiste tijd is hiervoor. Wachten op het juiste moment is misschien nog niet zo slecht, misschien ook juist om het toegankelijker te maken voor een grotere groep ontwikkelaars/coders.

En vannacht ga ik je reactie echt afschrijven, word er gek van.

[base_]

FireDrunk schreef op dinsdag 07 januari 2014 @ 21:58:
Jullie sluiten ook al je files met ?>
Dit is echt NIET slim... Als er na die ?> nog een newline staat wordt deze gewoon opgestuurt.
Je kan veel beter php gewoon niet sluiten.

Helemaal mee eens, zie http://www.php-fig.org/. Als je een soepelere samenwerking wilt hebben raad ik aan de PSR standaard zoveel mogelijk aan te houden.
Die closing tag gaat vaak al fout bijn windows/linux newline conversie idd.

@DXaroth hieronder: dat fig niet geforceerd wordt heeft meestal te maken met het feit dat zoiets voor bestaande projecten vrij veel werk is en dus geleidelijk doorgevoerd wordt.
Rest van reactie: helemaal mee eens, had het niet beter kunnen verwoorden!

[ Voor 19% gewijzigd door base_ op 08-01-2014 12:43 ]

[DXaroth]

base_ schreef op woensdag 08 januari 2014 @ 00:55:
[...]

Helemaal mee eens, zie http://www.php-fig.org/. Als je een soepelere samenwerking wilt hebben raad ik aan de PSR standaard zoveel mogelijk aan te houden.
Die closing tag gaat vaak al fout bijn windows/linux newline conversie idd.

het is alleen jammer dat fig nergens geforceerd wordt (zoals pep-8 dat bijvoorbeeld wel is in python, als je ooit een core-lib wilt maken of een zelf-respecterende package wilt zijn)

@CiPHER: de 'drempel' voor ontwikkelaars om te komen helpen is in mijn inziens altijd zo hoog als dat de core developers het maken; als jullie besluiten om 2014 te beginnen met een nieuwe interface voor ZFSGuru, dan gok ik dat de wat meer programmeer-ingestelde mensen die 'fan' zijn van ZFSGuru wel geinteresseerd zullen zijn om hun favoriete features er 'snel' in te krijgen (noot: verwacht niet veel hulp, mensen blijven lui, en zullen pas helpen als ze zich of dood vervelen, of zien dat het echt nut heeft)

Mijn vraag van gister over een non-full-os installatie was daar ook deels op gericht; ik wil voor mijn thuis nas bijvoorbeeld geen BSD draaien, omdat veel van mijn programmeer projecten nu eenmaal soepeler aan de praat te krijgen zijn onder een debian/ubuntu afgeleide .. maar een xmlrpc <=> zfs interface bijvoorbeeld, zou ik zo integreren in mijn eigen systeem (net zoals ik de nzbget xmlrpc interface gebruik voor mijn systeem om mn downloads te tracken).
Door het afscheiden van bepaalde stukken (want je kan nog steeds een full os install aanbieden die elke debiel kan installeren, ook al is je ZFS interface bijvoorbeeld een apart 'project' ) bied je de mogelijkheid om een breder publiek aan te spreken (en bijvoorbeeld een 'makkelijk-te-installeren-zfs-interface-voor-elk-zfs-ondersteunend-systeem' te zijn -naast- een 'makkelijk-te-installeren-zfs-OS')... Als FireDrunk zijn xmlrpc code bv direct op github had gezet, had ik waarschijnlijk gister niet 5 uur aan mijn hobby python projectje zitten prutsen, maar zijn code zitten doorspitten (en waarschijnlijk een pull request of 3 insturen met toevoegingen/verbeteringen/whatever)

[syl765]

Als FireDrunk zijn xmlrpc code bv direct op github had gezet

Een stille hint

[DXaroth]

syl765 schreef op woensdag 08 januari 2014 @ 12:56:
[...]


Een stille hint

het is een statement; als FireDrunk zijn code niet op github wilt zetten is dat zijn goed recht, maar ik probeer aan te geven wat voor een effect het 'open' gedeelte van open source kan hebben (in een optimaal geval)

[wallyberk]

DXaroth schreef op woensdag 08 januari 2014 @ 14:09:
[...]


het is een statement; als FireDrunk zijn code niet op github wilt zetten is dat zijn goed recht, maar ik probeer aan te geven wat voor een effect het 'open' gedeelte van open source kan hebben (in een optimaal geval)

Het is vaker aangeven dat dit ZFSguru niet opensource is maar wel leesbaresource is. Ook is het geen community project (dankzij de definitie die CiPHER hierover heeft). Maar ik nog steeds niet wat wel en niet mag.

Dus ga ik het op een andere manier proberen:
FireDrunk kan jij inschatten of als ik een van de volgende doe, of ik dan een boze mails van jason/CiPHER kan verwachten?
- Voor ander project gebruik ik jouw Python daemon, met een verwijzing naar ZFSguru;
- Ik maak een nieuwe plugin voor ZFSguru ( bv voor een Puppet Master), maar ik gebruik mijn eigen programmeerstyle, zet mijn eigen naam erin en verspreid hem via mijn eigen site.

[CurlyMo]

wallyberk schreef op woensdag 08 januari 2014 @ 15:02:
Het is vaker aangeven dat dit ZFSguru niet de opensource is maar wel leesbaresource is. Ook is het geen community project (dankzij de definitie die CiPHER hierover heeft). Ik nu echt niet meer wat wel en niet mag.

Hier gaat CiPHER zich nog over uitspreken.

Dus ga ik het op een andere manier proberen:
FireDrunk kan jij inschatten of als ik een van de volgende doe, of ik dan een boze mails van jason/CiPHER kan verwachten?
- Voor ander project gebruik ik jouw Python daemon, met een verwijzing naar ZFSguru;

Ofwel
1. De code is van FireDrunk
2. De code wordt overgedragen aan ZFSguru.
In beide gevallen zul je af moeten wachten onder welke licentie FireDrunk of ZFSguru het uitgeeft. Als het een vrije open source licentie is, mag iedereen het gebruiken die maar wilt. Als je je veranderingen maar openbaar maakt.

- Ik maak een nieuwe plugin voor ZFSguru ( bv voor een Puppet Master), maar ik gebruik mijn eigen programmeerstyle, zet mijn eigen naam erin en verspreid hem via mijn eigen site.

Gezien deze reactie weet je volgens mij totaal niet wat Open Source licenties inhouden. Ga daar eerst eens over lezen bijv. GPLv3 of MIT.

[wallyberk]

CurlyMo schreef op woensdag 08 januari 2014 @ 15:07:
[...]

Hier gaat CiPHER zich nog over uitspreken.


[...]

Ofwel
1. De code is van FireDrunk
2. De code wordt overgedragen aan ZFSguru.
In beide gevallen zul je af moeten wachten onder welke licentie FireDrunk het uitgeeft. Als het een vrije open source licentie is, mag iedereen het gebruiken die maar wilt. Als je je veranderingen maar openbaar maakt.

[...]

Gezien deze reactie weet je volgens mij totaal niet wat Open Source licenties inhouden. Ga daar eerst eens over lezen bijv. GPLv3 of MIT.

Het probleem juist dat ik wel weet wat Open Source licenties inhouden, maar aangezien de gehele discussie over een community project, lijkt mij dat zij "andere visies" erover hebben. En ik heb totaal geen zin in boze mails ( lees het gevoel bij jason / CiPHER geven dat ik hun project aan het kapen ben ), terwijl ik het juridisch wel zou mogen.

[CurlyMo]

Het grote probleem ligt inderdaad bij Jason en CiPHER zelf:

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

Short answer: absolutely not.

Everything a person writes, whether it is software or text, is automatically under copyright. The default state of any text is that it is completely owned by the author and no one has rights to do anything with it without express permission of the author. A few decades ago, an author used to have to assert copyright in order to retain it, but this is no longer the case.

[...]

Thus, if you cannot find any license information, then you cannot copy or modify it for any reason other than personal use.

Making something "open source" is a deliberate act and for you to treat it as such, you have to have found a license that tells you explicitly what your rights to the software are. This is even true of "public domain" software. That is, something is only "public domain" if it has either expired copyright (which mostly means it was written decades ago) or if the author has explicitly placed it in the public domain in writing.

In the case you describe, your only recourse is to contact the author and request that he allow you to do what you ask. To do otherwise is flatly illegal and in theory could lead to damages. (In practice, of course, you'd have to get caught.)

[...]

Bron: http://programmers.stackexchange.com/a/148165

We zullen dus moeten wachten totdat de code officieel van een licentie wordt voorzien of er een statement komt dat alle code van ZFSguru per definitie open source is onder een bepaalde licentie.

PS. hetzelfde geldt dus voor @FireDrunk.

[wallyberk]

CurlyMo je heb gelijk CiPHER heeft nooit aangegeven dat het niet opensource is, maar wel aangeven dat hij het niet prettig zou vinden als het geforked wordt. In mijn hoofd heb ik die wens door vertaalt naar niet opensource. Sorry hiervoor.

[CurlyMo]

Je trekt de verkeerde conclusie voor wat ik probeer duidelijk te maken. Zolang code geen expliciete open source licentie heeft is het niet open source, wat CiPHER en consorten ook mogen zeggen.

[FireDrunk]

Mijn code wordt waarschijnlijk BSD licensed, maar een getraint oog kan deze code zo zelf implementeren hoor. Stelt geen bal voor. Hele API is nu misschien 100 regels code.

[Verwijderd]

Open Source != Free software (FOSS)

Open Source kan open source zijn (de broncode meegeleverd/beschikbaar) maar om het te mogen gebruiken moet je duizenden euro's betalen. Dit concept is natuurlijk wel gevoelig voor diefstal en piraterij, dus als men een product proprietary wilt maken, ligt het voor de hand dat de broncode gesloten wordt. Zo heeft Microsoft de softwaremarkt - die destijds 100% opensource was - gecommercialiseerd met gesloten (pre-compiled) software. In dit tijd was het nog gebruikelijk dat de broncode van de software werd meegeleverd zodat je het voor je eigen systeem kon compileren.

Open Source wordt natuurlijk in de praktijk vaak 'FOSS' mee bedoeld, oftewel een liberale licentie die als OSI-compliant wordt gezien. Dat is ZFSguru op dit moment nog niet, en het hangt van Jason af welke keuze hij hierin wilt maken.

Hoe meer de discussie vordert, des te meer hebben jullie mijn argumenten bevestigd over waarom ZFSguru nu nog niet klaar is voor grootschalige contributie:

• Om contributie mogelijk te maken dient een bugtracker ingericht te worden en dienen Jason en ik die ook allebei te gebruiken.
• Om contributie makkelijk te maken dient documentatie geschreven te worden.
• Om contributie makkelijk te maken dienen bepaalde concepten binnen ZFSguru afgebroken danwel aangepast te worden.
• Om contributie makkelijk te maken moet de code herschreven worden naar bepaalde standaarden.
• Om contributie makkelijk te maken dient ZFSguru een OSI-compliant license te hebben.

Verder hoor ik zaken als:

• Services kunnen overboord, we hebben al een portstree.
• De kern van het project dient te veranderen en ZFSguru dient een web-interface voor Linux te worden.
• Ga zo maar verder...

Kortom, ZFSguru moet alles zijn wat het nu niet is. Het hele project moet op zijn kop, en dat allemaal om contributie mogelijk te maken, waarvan het nog maar de vraag is in hoeverre dat ook concreet wat oplevert in dit stadium van het project. Gevolgen voor de contributie van Jason en in mindere mate mijzelf worden niet overwogen, terwijl juist dat een veel grotere invloed kan hebben. Het gevaar bestaat dat Jason het niet langer als zijn project ziet, en zich vervreemd van de code omdat hij niet op zijn manier 'mag' coden, of de concepten die hij hanteert niet worden geaccepteerd door de community. In zo'n atmosfeer kan ik mij goed voorstellen dat de motivatie een stuk minder wordt om een belangrijk deel van je leven hieraan te besteden. Dit pessimistische scenario is toch ook niet wat jullie voor ogen hadden, mag ik aannemen? Dat Jason blijft werken aan het project zie ik als het belangrijke indicator voor de continuïteit van het project.

Mijn grotere reactie aan CurlyMo over het openen van het project ben ik met veel enthousiasme begonnen, maar ik moet eerlijk zeggen dat ook ik nu wat minder enthousiast ben. Ik moet nog aan Jason verslag uitbrengen, maar ik weet eigenlijk niet goed wat ik te melden heb. Het wordt ook voor mij iets te gecompliceerd als 'de geest uit de fles gaat' en opeens alles moet gaan veranderen. Het lijstje hierboven - misschien wat aangedikt maar toch.. - ga ik niet bij Jason inleveren. Ik wil Jason ondersteunen in zijn ambities, niet bestrijden.

Ik hoop vooral dat de positieve wegen worden bewandeld, zoals het beginnen met opbouw van community en mogelijk maken van contributie, zonder dat gelijk het project op zijn kop moet en Jason niet meer mag coden zoals hij gewend is. Ik wil best voorstellen die end-tags weg te halen, maar voor de rest: accepteer de stijl die ZFSguru aanhoudt. Als je je eigen stijl wilt aanhouden in addons is dat niet het probleem. Ook code aanleveren in een andere stijl niet; dan herschrijven Jason of ik het wel indien nodig. Dat is niet het probleem. Kortom, is het niet beter dat we ons concenteren op de zaken die in dit vroeg stadium van het project en gezien de omstandigheden wel positieve invloed kunnen hebben? Of anders gezegd, laten we ons concentreren op het laaghangend fruit.

[CurlyMo]

Verwijderd schreef op woensdag 08 januari 2014 @ 18:09:
Kortom, ZFSguru moet alles zijn wat het nu niet is. Het hele project moet op zijn kop, en dat allemaal om contributie mogelijk te maken, waarvan het nog maar de vraag is in hoeverre dat ook concreet wat oplevert in dit stadium van het project.

Even negatief gevraagd: Wat is het nu dan wel? Ik probeer daarin even de negatieve reacties samen te vatten:

1. Er ontstaat regelmatig discussie over ZFSguru, leeft het nog of niet.
2. Een reactie van Jason is elke keer weer groot nieuws
3. Meerdere malen blijkt dat mensen de koers niet zien zitten of er geen vertrouwen in hebben.
4. De code zit slecht of onbegrijpelijk in elkaar (e.g., het niet volgen van standaarden, beveiligingsproblemen, stijlverschillen) - versterker van punt 3.
5. Er komen nauwelijks updates.
6. Sommige zaken komen simpelweg amateuristisch over (e.g., www gebruiker volledige root rechten geven, toch niet volledig pkgng implementeren).
7. Er is geen documentatie en/of wiki.

Ik blijf van mening dat je beter z.s.m. over kunt stappen naar een community driven project dan op deze manier door blijven gaan, want hoe langer je doorgaat zo, hoe moeilijker het wordt. Daarbij komt dat er al van verscheidene kanten is aangegeven dat mensen willen bijdragen. Ik zou ook best een zooi van mijn eigen geschreven script willen implementeren, maar ja, dat is niet te doen.

Bang zijn voor het niet krijgen van contributies zou ik niet zijn. Al helemaal als je ziet hoe weinig werk het voor sommigen (zoals FireDrunk python en ik in C) kan zijn om bepaalde zaken wel goed te implementeren.

Verwijderd schreef op woensdag 08 januari 2014 @ 18:09:
Kortom, is het niet beter dat we ons concenteren op de zaken die in dit vroeg stadium van het project en gezien de omstandigheden wel positieve invloed kunnen hebben?

Het project is tenminste 3 jaar oud (denk ik zo) en nog steeds noem je het een vroeg stadium Kijk eens hoe snel en uitgebreid die Raspberry Pi projecten zijn sinds zijn uitkomst... (kuch, community).

• Om contributie mogelijk te maken dient een bugtracker ingericht te worden en dienen Jason en ik die ook allebei te gebruiken.
• Om contributie makkelijk te maken dient documentatie geschreven te worden.
• Om contributie makkelijk te maken dienen bepaalde concepten binnen ZFSguru afgebroken danwel aangepast te worden.
• Om contributie makkelijk te maken moet de code herschreven worden naar bepaalde standaarden.
• Om contributie makkelijk te maken dient ZFSguru een OSI-compliant license te hebben.

1. Is er al op github.
2. Kan de community doen.
3. Kan de community doen (als ze dat niet doen, verandert er niks).
4. "
5. Even alle bestanden een license header geven.

[ Voor 26% gewijzigd door CurlyMo op 08-01-2014 18:43 ]

[EnerQi]

Ik hoop vooral dat de positieve wegen worden bewandeld, zoals het beginnen met opbouw van community en mogelijk maken van contributie, zonder dat gelijk het project op zijn kop moet en Jason niet meer mag coden zoals hij gewend is. Ik wil best voorstellen die end-tags weg te halen, maar voor de rest: accepteer de stijl die ZFSguru aanhoudt. Als je je eigen stijl wilt aanhouden in addons is dat niet het probleem. Ook code aanleveren in een andere stijl niet; dan herschrijven Jason of ik het wel indien nodig. Dat is niet het probleem. Kortom, is het niet beter dat we ons concenteren op de zaken die in dit vroeg stadium van het project en gezien de omstandigheden wel positieve invloed kunnen hebben? Of anders gezegd, laten we ons concentreren op het laaghangend fruit.

Ik wil dit juist aandragen om te doen ipv de bovenstaande reactie van CurlyMo. Het project is niet mature genoeg om zelfstandig door het leven te gaan (lees zonder Jason) en eigenlijk moet je dit ook niet willen. Als dit project nu "community" wordt, vrees ik meer voor input van Jason/CiPHER (wat logisch is).

Ik denk dat je dit pas mag/kan vragen als versie 1.0 uitgebracht is. Vragen om het mogelijk zonder Jason verder te kunnen.

[FireDrunk]

@CiPHER, je voelt je veel te veel aangevallen, een bugtracker implementeren is absoluut niet rechtsomkeert maken. Je moet het juist zien als een ondersteuning voor je werk. Het zorgt er voor dat je duidelijk voor ogen hebt hoeveel er nog moet gebeuren en wanneer ( je kan immers ook sprints plannen in mijn Redmine Bugtracker ).

Zie het niet als een afslag naar een zandweg, zie het alsof je nu op een weg rechtdoor gaat richting je doel, maar op een 80KM weg. Zie het inrichten van een bugtracker als een afslag waarna je op de snelweg komt die dezelfde kant op gaat.

Voor de rest, ik geef er geen bal om of ZFSguru officeel een licentie heeft, je kan coden wat je wil en inleveren. Wel is documentatie over het minimale gebruik van bijvoorbeeld de template engine en de tabstructuur wel handig. De rest is niet persé nodig.

Documentatie daarover is door een kenner (Jason of jij) in een avondje geschreven met wat goede voorbeelden.

[ Voor 24% gewijzigd door FireDrunk op 08-01-2014 19:47 ]

[Verwijderd]

Ik moet er nog meer over nadenken...

Jullie hebben allemaal goede punten, daar niet van. Maar ik probeer dat ook te verenigen met de belangen/wensen van Jason; want sommige voorstellen gaan wel heel erg ver. Nou verwacht ik dat Jason ook best wat concessies wil doen. Maar sommige voorstellen komen neer op het einde van het project en dat kan ook niet de bedoeling zijn.

Ik heb liever dat ik straks met concrete en kleinere stappen naar Jason toe kan stappen om een begin te maken van de community, en zo ook Jason te overtuigen van de voordelen. Hij moet het ook als voordeel gaan zien dat ZFSguru baat kan hebben bij de community. Ook in deze fase van het project. Dit terwijl Jason eerst ZFSguru wilde afbouwen en daarna de infrastructuur van de community wilde ontwerpen. Misschien is een andere route beter waarbij de community al eerder betrokken wordt bij ZFSguru. Prima, daarin kan ik hem mogelijk wel overtuigen.

Daarnaast zal - hoe dan ook - de ontwikkeling blijven neerkomen op Jason. Zonder hem geen ZFSguru, of althans niet een project met een echte toekomst. Misschien dat sommige van jullie daar anders over denken, maar dit weet ik toch vrij zeker. Alle goedbedoelde adviezen ten spijt, als Jason er straks geen zin meer in heeft door alle gedoe over hoe hij mag coden en welke licentie het moet hebben enzo, dan is dat zeer letterlijk de doodsteek voor het project. Dan wordt het misschien voortgezet door enkele mensen die er nog een half maandje werk in steken, maar daarna dooft het langzaam uit, alsof het nooit heeft bestaan.

Accepteer de hoge ambities en plannen die er zijn. Enige scepsis is altijd gezond, maar te negatieve feedback heeft ook enkel een negatief resultaat. Kortom, je moet het project ook een kans kunnen geven. Accepteer dat ZFSguru een andere route volgt dan een doorsnee FOSS-project zoals Pilight pilight. Het blijft een eigenzinnig en rebels project. Als je daar niet sympathiek tegenover staat dan past ZFSguru denk ik ook niet bij je.

[SlaadjeBla]

Ik wil iedereen (maar CiPHERen Jason(?) vooral) graag een essay van Eric S Raymond aanraden: The cathedral and the bazaar. Het gaat over de lessen die hij geleerd heeft in grote open-source projecten en de omgang met de community. Ik denk dat jullie er veel aan zullen hebben.

[ Voor 10% gewijzigd door SlaadjeBla op 08-01-2014 20:02 ]

[CurlyMo]

Mijn mening is dat elk goed project zonder zijn oprichter kan. Het grootste voorbeeld hiervan is Lirc. Dat wordt al meer dan 10 jaar niet meer onderhouden door de oprichter, maar blijft nog steeds op en top levend en verder ontwikkeld.

XBian is ondertussen 3 keer van ontwikkelaar verandert, waarvan ik de 2de was. De opvolging werd gemotiveerd kwaliteit en vrije tijd.

[ Voor 22% gewijzigd door CurlyMo op 08-01-2014 20:06 ]

[Verwijderd]

@SlaadjeBla: gaan we doen!

@CurlyMo: maar ZFSguru is geen Lirc.

@FireDrunk:
Mee eens met wat je zegt. Mijn reactie hierboven gaat meer over de vergaande voorstellen omtrent het 'castreren' van ZFSguru. Dat zie ik niet zo zitten. Maar kleinere stappen (wiki/bugtracker/essentiële documentatie) zou wel kunnen. Uiteraard betekent dit ook dat Jason er mee moet kunnen gaan werken, want een bugtracker die de devs links laten liggen hebben we weinig aan. Maar ik verwacht ook wel dat Jason enige stappen wilt nemen, die misschien niet vanzelf gaan. Maar ik denk: houd het dan ook leuk dat ook hij het als voordeel ziet. Niet dat het voelt als het uit handen geven van zijn project aan een anonieme club die er mee vandoor gaat, die voortaan de toekomst bepalen van ZFSguru.

Het is uiteindelijk ook in jullie voordeel dat het project een succes wordt. En één ding staat vast, dat gaat niet gebeuren als Jason ermee stopt. Open source of niet, FOSS of niet, zonder Jason is het project dood. Bij andere projecten is het misschien heel anders, maar ZFSguru is een expressie van Jason. Dus ik zou zeggen tegen iedereen, stop met het bestrijden van Jason en start met het helpen; kortom constructieve feedback waar we wat mee kunnen.

Ik was juist enigszins enthousiast over CurlyMo's verhaal. Zou goed zijn als ik dat enthousiasme kan vasthouden. Als het alleen maar kritiek is en ZFSguru is slecht en amateurtistisch en volgt geen standaarden en blabla, dan krijg ik er ook minder zin in... Liever dan geen community dat gaat misschien nog sneller met coden ook. Ben nu ook al een week uit de running. Het zou toch jammer zijn als ik zo zou gaan denken?! Ik wil juist heel graag deze discussie succesvol afronden met concrete punten die er bereikt zijn. Misschien te weinig volgens sommigen, maar dat is dan wat erin zit. En daarmee ook voorlopig de knoop doorgehakt; maanden over blijven discussieren heb ik ook geen zin in. Want op sommige momenten klopt de originele titel 'bashing topic' toch wel aardig. Daarvoor is onze tijd te kostbaar.

[CurlyMo]

Dit pessimistische scenario is toch ook niet wat jullie voor ogen hadden, mag ik aannemen?

Eén ding moet duidelijk zijn, Ik gaf aan dat ik een pessimistische insteek pakte, dat zegt allerminst dat ik zelf zo pessimistisch ben over ZFSguru. Ik probeer vooral dingen aan te dragen om over na te denken, zodat CiPHER en Jason een goede overweging kunnen maken, of dat nu uiteindelijk voor of tegen FOSS is.

Wat ik nog niet gezegd had. De allergrootste meerwaarde van FOSS is voor mij de discussies die ik kan voeren over mijn projecten en de wegen die ik bewandel. Dat zijn precies die discussies die we hier hebben gehad over concrete invullingen van problemen zoals rechten beheer, webservers, codeer standaarden etc. Dat houdt je scherp en doet je nieuwe perspectieven zien voor problemen. Hetzelfde doe ik ook nog wel eens voor XBian waar ik inmiddels officieel gestopt ben. Zo nu en dan reageer op op github op nieuwe code op de nieuwe dev scherp te houden.

Daarnaast heb ik een schets gegeven voor wat er allemaal nodig is om een full-blown community project te draaien. De rest is aan jullie.

@SlaadjeBla, mooi essay. Ik pak even een paar mooie stukjes eruit:

Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging.

The power of this effect is easy to underestimate. In fact, pretty well all of us in the open-source world drastically underestimated how well it would scale up with number of users and against system complexity, until Linus Torvalds showed us differently.

Early and frequent releases are a critical part of the Linux development model.
[...]
If the overriding objective was for users to see as few bugs as possible, why then you'd only release a version every six months (or less often), and work like a dog on debugging between releases.
[...]
Release early. Release often. And listen to your customers.
[...]
Put that way, the question answers itself. Linus was keeping his hacker/users constantly stimulated and rewarded—stimulated by the prospect of having an ego-satisfying piece of the action, rewarded by the sight of constant (even daily) improvement in their work.
[...]
Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone.

One special feature of the Linux situation that clearly helps along the Delphi effect is the fact that the contributors for any given project are self-selected. An early respondent pointed out that contributions are received not from a random sample, but from people who are interested enough to use the software, learn about how it works, attempt to find solutions to problems they encounter, and actually produce an apparently reasonable fix. Anyone who passes all these filters is highly likely to have something useful to contribute.

I used the term "core developer"; this reflects a distinction between the project core (typically quite small; a single core developer is common, and one to three is typical) and the project halo of beta-testers and available contributors (which often numbers in the hundreds).

I said earlier that I'd decided to use this project to test my theory about what Linus Torvalds had done right. How (you may well ask) did I do that? In these ways:

I released early and often (almost never less often than every ten days; during periods of intense development, once a day).

I grew my beta list by adding to it everyone who contacted me about fetchmail.

I sent chatty announcements to the beta list whenever I released, encouraging people to participate.

And I listened to my beta-testers, polling them about design decisions and stroking them whenever they sent in patches and feedback.

[ Voor 57% gewijzigd door CurlyMo op 08-01-2014 20:31 ]

[EnerQi]

Daarnaast zal - hoe dan ook - de ontwikkeling blijven neerkomen op Jason. Zonder hem geen ZFSguru, of althans niet een project met een echte toekomst. Misschien dat sommige van jullie daar anders over denken, maar dit weet ik toch vrij zeker. Alle goedbedoelde adviezen ten spijt, als Jason er straks geen zin meer in heeft door alle gedoe over hoe hij mag coden en welke licentie het moet hebben enzo, dan is dat zeer letterlijk de doodsteek voor het project. Dan wordt het misschien voortgezet door enkele mensen die er nog een half maandje werk in steken, maar daarna dooft het langzaam uit, alsof het nooit heeft bestaan.

Die mening deel ik ook (al komt het in mijn eerdere reactie er niet echt uit ). Jason en CiPHER hebben genoeg te doen en ook willen doen. Nu is het afwachten op beta 9 en verdere stappen.

[CurlyMo]

Dit vat denk ik ook goed mijn betoog samen:
http://www.catb.org/~esr/...edral-bazaar/ar01s10.html

[Verwijderd]

Ik ben hem nu aan het lezen, ik lees langzamer dan ik schrijf, dus dat duurt even.
FireDrunk: wat ik schrijf zit al in mijn hoofd, het punt is assimileren van informatie. Daarnaast moet ik mijn gedachten temmen, anders schiet het niet op met lezen.

Ik kan alvast zeggen dat veel van wat ik lees wel degelijk in de strategie past die Jason voor ogen heeft. Alleen dan met een andere route dan de conventionele 'GitHub'-route.

[ Voor 67% gewijzigd door Verwijderd op 08-01-2014 21:05 ]

[FireDrunk]

Dus je lees niet wat je schrijft?

[DXaroth]

Verwijderd schreef op woensdag 08 januari 2014 @ 20:05:
Dus ik zou zeggen tegen iedereen, stop met het bestrijden van Jason en start met het helpen; kortom constructieve feedback waar we wat mee kunnen.

Dan is het wellicht handig dat Jason ook aan deze discussie mee doet, zodat er iets concreets is om constructieve feedback op te geven?

[Verwijderd]

Ik zou verslag uitbrengen aan Jason wat precies de wensen zijn van de community, voortkomende uit de discussie hier. Ik ben van plan nadat ik mijn reactie op CurlyMo heb afgerond een conceptreactie aan Jason te schrijven. Daar kunnen jullie dan nog eventueel feedback over geven en dan horen we van Jason hoe hij er over denkt. Kortom, de bal ligt nu nog bij 'ons'. En jullie bepalen ook min of meer wat er in 'ons' bericht aan Jason komt. Sommige dingen ga ik niet voorstellen, maar veel genoemde punten wel.

[FireDrunk]

Heb je hem al wel uitgehoord over een Python API Daemon?

[DXaroth]

Verwijderd schreef op woensdag 08 januari 2014 @ 21:30:
Ik zou verslag uitbrengen aan Jason wat precies de wensen zijn van de community, voortkomende uit de discussie hier. Ik ben van plan nadat ik mijn reactie op CurlyMo heb afgerond een conceptreactie aan Jason te schrijven. Daar kunnen jullie dan nog eventueel feedback over geven en dan horen we van Jason hoe hij er over denkt. Kortom, de bal ligt nu nog bij 'ons'. En jullie bepalen ook min of meer wat er in 'ons' bericht aan Jason komt. Sommige dingen ga ik niet voorstellen, maar veel genoemde punten wel.

Ik zat meer te denken aan posts van hem zelf (en mocht hij geen nederlands kunnen wil ik best moeite doen om zooi te vertalen naar het engels (en daarin verder te discusseren mocht nodig zijn)), maar bij gebrek daaraan moet dit ook meer dan voldoen.

[Verwijderd]

Je hebt zijn statement gelezen? 1e reactie in dit topic dus vlak na de startpost heb ik hem gepost.

[DXaroth]

Verwijderd schreef op woensdag 08 januari 2014 @ 21:39:
Je hebt zijn statement gelezen? 1e reactie in dit topic dus vlak na de startpost heb ik hem gepost.

Duidelijk gemist (nooit gezien dat na jouw muur aan spam text ook nog een update was )

[Verwijderd]

Zie je wel, jullie lezen simpelweg mijn proza niet, daarom begrijpen jullie mij verkeerd!
Het is allemaal jullie schuld!

[onox]

Je zou ook DBus kunnen gebruiken voor de Python daemon:

Python:

dbus_bus_name = "net.tweakers.onox.Test"
dbus_object_path = "/net/tweakers/onox/Test"
dbus_object_interface = dbus_bus_name

import glib
import dbus
import dbus.service

from dbus.mainloop.glib import DBusGMainLoop
DBusGMainLoop(set_as_default=True)

class TestDBusObject(dbus.service.Object):

    """A DBus object to do bla bla.

    """

    def __init__(self):

        bus = dbus.SessionBus()
        bus.request_name(dbus_bus_name)

        dbus.service.Object.__init__(self, bus, dbus_object_path)

    @dbus.service.method(dbus_interface=dbus_object_interface, out_signature="b")
    def TestOne(self):
        return True

    @dbus.service.method(dbus_interface=dbus_object_interface, out_signature="i")
    def TestTwo(self):
        return 2

    @dbus.service.method(dbus_interface=dbus_object_interface, out_signature="ai")
    def TestThree(self):
        return [1, 2, 3]

    @dbus.service.method(dbus_interface=dbus_object_interface, in_signature="s")
    def TestFour(self, four):
        assert four == "four"

        return True

glib.threads_init()
TestDBusObject()
glib.MainLoop().run()

Testen kan via het programma D-Feet, tabblad Session Bus.

[DXaroth]

onox schreef op donderdag 09 januari 2014 @ 00:10:
Je zou ook DBus kunnen gebruiken voor de Python daemon:

Het lijkt me handiger om KISS hier toe te passen.

DBus is een leuk systeem, don't get me wrong, maar als je je dan de volgende dingen realiseert:

+xmlrpclib is built-in in python, als je python hebt, heb je xmlrpclib
+xmlrpclib staat bovenop een breed gebruikt protocol (http), en kan dus in theorie vanaf elke taal aangeroepen worden.
+het is mogelijk om xmlrpc te combineren met bv json-rpc (ik heb dit ooit een keer gemaakt voor een van mijn eigen frameworks), zodat je vanuit 1 process 2 methodes van communicatie kan supporten -zonder- specifieke code te hoeven schrijven bij je modules (hiermee support je dus ook gelijk directe toegang vanaf een web-interface).

tegenover:

-DBus is gecompiled, en kan dus problemen geven bij het updaten van packages (waardoor het 'even' updaten van je omgeving meer testen vereist)
-DBus is een apart protocol; mocht om de een of andere reden <taal x> geen directe support er voor hebben, dan moet je een complete implementatie bouwen, in plaats van
-DBus is strongly typed, en de 3 talen waar ik zo snel van gok dat de communicatie mogelijk kan gaan gebeuren (python, php, javascript) zijn dat niet; dit zorgt voor onnodige complexiteit in je modules

Mocht je nu nog 5 plus punten vinden waarom DBus 'handiger' zou zijn dan xmlrpclib, dan is er eventueel nog een discussie nodig (en neen, authorisatie/authenticatie is niet deel van je protocol, dat is deel van je implementatie)..maar tot die tijd zou ik van mening zijn dat in dit geval het simpeler is om xmlrpc te gebruiken.

[CurlyMo]

Om CiPHER weer wat verder enthousiast te maken. Een van mijn moderatoren pakt nu de taak op (uit zichzelf) om mijn commits om te zetten in een lijst van nieuwe/aangepaste/verwijderde code. Zo hoef ik alleen maar te coderen en begrijpen gebruikers waarom bepaalde dingen niet meer werken zoals bij de vorige versie of of een probleem al is opgelost, en wat precies nieuwe functionaliteit inhoudt. Scheelt mij weer tijd.

http://wiki.pilight.org/doku.php/changes_features_fixes

[FireDrunk]

De eerste echte werkende pagina icm de API.


Design van de API momenteel (niet 100% geimplementeerd)

Ik zit er over te denken om bij api access van echt gevaarlijke dingen (zoals chmod_file) gewoon het root password (of een andere user) te vragen en direct mee te sturen... Iemand daar een idee over?

[ Voor 66% gewijzigd door FireDrunk op 09-01-2014 09:03 ]

[DXaroth]

FireDrunk schreef op donderdag 09 januari 2014 @ 08:27:
Ik zit er over te denken om bij api access van echt gevaarlijke dingen (zoals chmod_file) gewoon het root password (of een andere user) te vragen en direct mee te sturen... Iemand daar een idee over?

het zou sowieso handig zijn om authenticatie te implementeren.. aangezien je xmlrpc gebruikt, kan je handig gebruiken van de mogelijkheden van HTTP... namelijk, cookies

Wat mijn xmlrpc/jsonrpc systeem doet, is een sessie opbouwen met een ieder die calls uitvoert (mind, mijn rpc zit deels in mn front-end, dus die maakt gebruik van het request gedeelte van het framework, waardoor ik dus dit makkelijker kan doen).. en voegt de volgende calls toe:

<namespace>.login
<namespace>.logout
<namespace>.status

waarbij <namespace> dus de functie prefix is (dit is bij mij account , maar normaal wordt dit bij xmlrpc als system aangehouden).
Zodra iemand ingelogd is, wordt in zijn sessie dit bijgehouden, zodat bij volgende calls ik kan zien wie het is, en wat hij is.. added bonus voor mijn systeem is dat jsonrpc dit al automatisch doet, want het rpc gedeelte zit op hetzelfde domein als de front-end, dus hij stuurt netjes de sessie mee die de gebruiker heeft.

Dit heeft als voordeel dat je 1) niet met elke request een wachtwoord mee hoeft te sturen (dit hoeft enkel aan het begin van de 'sessie') .. als nadeel heeft het weer wel dat voor een enkele call, je dus 2 calls moet uitvoeren (of 3 als je met .status() wilt testen of je nog ingelogd bent).

Nu zal dit voor een stand-alone systeem wat lastiger te implementeren zijn, maar bied wel veel mogelijkheden.

[FireDrunk]

Ik ging er een beetje van uit dat de API session / stateless zou kunnen worden. Maar wat je zegt is zeker van waarde als we de API statefull gaan maken.

[DXaroth]

FireDrunk schreef op donderdag 09 januari 2014 @ 09:20:
Ik ging er een beetje van uit dat de API session / stateless zou kunnen worden. Maar wat je zegt is zeker van waarde als we de API statefull gaan maken.

je wilt hoe dan ook iets van statefulness hebben, want je bepaalde dingen afschermen voor 'onbevoegden'.
de overhead van sessions zou nagenoeg niets zijn tegenover de voordelen die je er van krijgt

[FireDrunk]

De API luistert in eerste instantie alleen op 127.0.0.1.

[roy.jacobs]

Verwijderd schreef op woensdag 08 januari 2014 @ 19:52:
Het blijft een eigenzinnig en rebels project.

Je kan niet werkelijk menen dat ZFSGuru straks een fantastisch systeem wordt met een volledig geintegreerde community als je nu al niet luistert naar wat een handjevol mensen probeert aan te geven.

[CurlyMo]

roy.jacobs schreef op donderdag 09 januari 2014 @ 10:46:
[...]

Je kan niet werkelijk menen dat ZFSGuru straks een fantastisch systeem wordt met een volledig geintegreerde community als je nu al niet luistert naar wat een handjevol mensen probeert aan te geven.

De verschillende meningen die hierover bestaan zijn volgens mij al genoeg gedeeld. Daarentegen blijft het een gratis product dat je niet hoeft te gebruiken.

[roy.jacobs]

Uiteraard! Maar mijn punt is: Ik zou *juist* nu in dit vroege stadium luisteren naar de community aangezien dit straks een van de grote spillen zal zijn waar het project omheen gaat draaien. Het project is nu nog op het punt dat er een koerswijziging kan optreden, dat kan straks niet meer, en dan is het misschien te laat.

Dat merk je nu ook al, er is maar minimale communicatie nodig om wat derden aan te sporen om wat te bouwen (hoe minimaal ook).

[CurlyMo]

roy.jacobs schreef op donderdag 09 januari 2014 @ 12:41:
Uiteraard! Maar mijn punt is: Ik zou *juist* nu in dit vroege stadium luisteren naar de community aangezien dit straks een van de grote spillen zal zijn waar het project omheen gaat draaien. Het project is nu nog op het punt dat er een koerswijziging kan optreden, dat kan straks niet meer, en dan is het misschien te laat.

Dat merk je nu ook al, er is maar minimale communicatie nodig om wat derden aan te sporen om wat te bouwen (hoe minimaal ook).

Ook dat is echt al meerdere malen aangegeven (o.a. door mij).

[roy.jacobs]

Prima, discussie klaar dan.

[EnerQi]

Wat is die koerswijziging dan? Voor mijn gevoel killen we het project (Jason en CiPHER lopen weg) en gaan van scratch af weer beginnen.

Het enige wat ik als punt zie, is het niet volgen van normale coding technieken waardoor hulp moeilijker is (niet onmogelijk). Het puntje van het ontbreken van wiki/bugtracker/site lijken mij minder pijnlijk voor het huidige project.

[CurlyMo]

EnerQi schreef op donderdag 09 januari 2014 @ 13:38:
Wat is die koerswijziging dan? Voor mijn gevoel killen we het project (Jason en CiPHER lopen weg) en gaan van scratch af weer beginnen.

Wacht gewoon rustig af tot hij met de "Grote Reactie op CurlyMo" komt

[Verwijderd]

roy.jacobs schreef op donderdag 09 januari 2014 @ 12:56:
Prima, discussie klaar dan.

Waarom de geïrriteerde reactie?
Waarom de veronderstelling dat er niets met alle voorstellen zou gebeuren?
Waarom zou een koerswijziging alleen nu mogelijk zijn en later niet meer?
Waarom zou ik niet luisteren; ik doe in dit topic weinig anders?
Waarom zo pessimistisch?

Ik ben er nog niet helemaal uit nee. Daarnaast voelt alsof mijn reactie naar CurlyMo, die mij juist op belangrijke punten heeft weten te overtuigen, wel een beetje mijn uiteindelijke positie wordt. Dus ik moet er nog eens goed overna denken en alles op een rijtje zetten voordat ik het definitief post.

Dat ik niets zou doen met alle voorstellen of dat het topic straks doodbloed zonder conclusie hoef je je echt geen zorgen om te maken. Nu al zie je wat wat het oplevert dat zelfs FireDrunk - die toch ook kritiek had op bijvoorbeeld de code van ZFSguru - bereid is om hier serieus aandacht aan te besteden. Ik kan het natuurlijk niet maken om hier niets mee te doen, maar dat ben ik ook helemaal niet van plan.

Kortom, spreek niet voor je beurt.

[roy.jacobs]

Nee hoor, ik wil niet in herhaling vallen als het meeste al gezegd is door anderen, dat is het enige. Zonder smileys kwam het wellicht wat geirriteerd over.

Ik hoop in ieder geval dat jullie wat met de input kunnen doen. Ik denk echt dat je nu op een soort van cruciaal punt staat qua community adoption en ik hoop dat het positief wordt. Er zijn maar weinig simpel te gebruiken alternatieven voor QNAP/Synology, tenslotte. Maar ik blijf nog voorzichtig bij mijn mening dat het op dit moment nog wat overambitieus is met te weinig buy in van de community, maar de beste manier voor jullie om dit te weerleggen is uiteraard het leveren van een fantastisch produkt dat ik dan met plezier ga gebruiken

[FireDrunk]

https://github.com/FireDrunk/guruapid

[DXaroth]

FireDrunk schreef op donderdag 09 januari 2014 @ 15:37:
https://github.com/FireDrunk/guruapid

Je wilt de volgende keer bij het maken van een repo in de dropdown selecteren dat het om een python project gaat; dan zal github automatisch je .gitignore goed zetten (.pyc automatisch negeren, etc etc)
voor de simpelheid kan je die van libopenttd overnemen .. scheelt een hoop opschoonwerk

.. Zal vanavond kijken naar je code, dus sta niet vreemd op te kijken als je issues/pull requests krijgt

[FireDrunk]

Graag zelfs

[DXaroth]

FireDrunk schreef op donderdag 09 januari 2014 @ 19:13:
Graag zelfs

compleet verbouwen mag ook? heb de code doorgekeken; er zit nog niet echt een logische structuur in.. of iig, niet in een vorm die op grotere schaal bruikbaar moet gaan worden... maar geen vrees, ik heb wat ideetjes.

[FireDrunk]

Hou het wel simpel, liever meer simpele plugins dan een paar ingewikkelde.

[DXaroth]

FireDrunk schreef op donderdag 09 januari 2014 @ 20:45:
Hou het wel simpel, liever meer simpele plugins dan een paar ingewikkelde.

Gaat me meer om het framework eromheen, dan de plugins

[Verwijderd]

FireDrunk, kun je misschien ook de aanpassingen aan ZFSguru doorgeven, die ene PKG pagina. Dan kan ik op basis hiervan een library maken aan ZFSguru zijde. Lijkt me leuk project voor na beta9. Beta10 zou misschien al je daemon kunnen draaien dan. Of we maken eerst een speciale beta die los valt te updaten, als het toch wat risicovoller zou blijken. Maar op tijd voor 0.2 final zou mooi zijn.

Een wildcard plugin is misschien ook handig, voor ontwikkeling en debugging.

[CurlyMo]

Zoals te lezen in dat essay is het sowieso goed om een soort van development branch te hebben waar vandaan mensen code kunnen testen.

[Verwijderd]

ZFSguru heeft nu een stable en experimental branch voor de web-interface. Maar omdat het nog voor 0.2 is, is er nog geen stable release. De stable branch nu is de vorige beta (beta7) en de experimental branch is de nieuwste beta (beta8). Zo werkt het op dit moment. Zodra 0.2 er is dan kan die stable worden en 0.3-beta de experimental.

[MikeVM]

wat ik mis zijn degelijk step-by-step tutorials van allerlei zaken.
en een degelijke FAQ zou ook niet misstaan,
nu moet ik telkens u (CiPHER) lastigvallen met mijn vragen.

vaak zijn de antwoorden onvolledig (voor mij) omdat mijn kennis niet zo ver rijkt als het gemiddelde hier..

waar ik mij het meeste zorgen om maak, is als het fout gaat, dan heb ik snel deglijke informatie nodig over hoe ik mijn data kan beschermen en mijn server weer up and running kan krijgen. al hoop ik dat ik dergelijke tutorials niet nodig zal hebben..

[ Voor 30% gewijzigd door MikeVM op 10-01-2014 08:00 ]

[FireDrunk]

@CiPHER, hoe wil je dat ik die lever, er is nog geen git. En een API library heb ik ook al gemaakt.

[EnerQi]

Iets waar ik net aan dacht. Is het mogelijk om een overzicht te maken met alle instellingen etc voor bugposting? Ik dacht aan hardware, services enabled, schijfindeling/pools/devs etc. Zodat gebruikers dat overzicht kunnen toevoegen in hun bugreport naar ZFSguru toe (of de bugtracker).

[FireDrunk]

Misschien moet 1 iemand even een bugreport tool maken welke informatie verzameld op je systeem en deze in een compressed log archive zet ofzo. (.gz ofzo)?

[FireDrunk]

@DXaroth, ik heb een nieuwe versie gecommit, dit is vast meer naar je zin

[DXaroth]

FireDrunk schreef op vrijdag 10 januari 2014 @ 11:12:
@DXaroth, ik heb een nieuwe versie gecommit, dit is vast meer naar je zin

Ik had mijn eigen branch al gemaakt op een fork.. en die 2 systemen al helemaal over de schop gegooid

Ik moet wel bekennen dat ik een dependency heb toegevoegd; cherrypy .. kwam er achter dat python's standaard implementatie van de xmlrpc server niet toestaat om 'makkelijk' acl toe te voegen (dus geen auth, geen ip-based checks of whatever) .. dus ik ben het opnieuw aan het opbouwen in cherrypy (wat, voor zover ik kon zien de meest light-weight oplossing is die moet doen wat nodig is).
Added bonus, voor zover ik kan zien kan ik met een paar regels json-rpc support toevoegen, dus dat ga ik er ook gelijk in sjeffen .. dat zal dan transparant moeten zijn voor de plugins, de dispatcher handelt dat allemaal af.

Ik heb een plugin registry gemaakt, op die manier kan je weg doen met je construct calls, dat gebeurt automagisch (ook wat basis checks, en de mogelijkheid om system calls te overschrijven)... daarnaast heb ik een base class gemaakt voor elke plugin (die PluginObject heet), met wat helper functies.

https://github.com/xaroth/guruapid/tree/rework

[DXaroth]

Ok, wat meer de dispatcher uitgewerkt.

Het starten van de dispatcher doe ik als volgt:

Python:

from guruapid.core.dispatcher import *
import cherrypy
cherrypy.quickstart(Dispatcher())

Daarmee is de daemon gestart (hij logged netjes naar je output, dus je ziet alle requests langs komen).

Alle classes (ook functies, maar met classes is het netter, en kan je later makkelijker ACL toepassen) met de @plugin decorator (zoals zichtbaar in system_plugins.py) worden geregistreerd, en zijn dan bruikbaar..
PluginObject classes hebben 3 functies die gebruikt kunnen worden om de call af te handelen:
PluginObject.run(rpc_type, *args, **kwargs) .. hierop komt de call binnen, als deze niet wordt overridden, dan stuurt hij hem door naar een van de volgende 2:
PluginObject.xml(*args, **kwargs) .. hierop komen enkel xml-rpc calls op binnen
PluginObject.json(*args, **kwargs) .. hierop koen enkel json-rpc calls op binnen.

Wat dan dus mogelijk is, is voor elke call een class te maken (zo kan je ook inheritance toepassen; als je 20 plugins hebt die elk een systeem call uitvoeren, is het zinloos om 20x dezelfde code te herhalen.. in plaats daarvan zet je het in 1, en gebruik je dat in de andere 19).

Ik zal waarschijnlijk vanavond wat gaan prutten om de plugin configureerbaar te maken (zodat het eventueel mogelijk is om nieuwe functies toe te voegen zonder dat het onderdeel is van de main API), en wellicht wat ACL of de huidige plugins ombouwen.

[FireDrunk]

Ok, ik heb zojuist command line argumenten ingebouwd (heel primitief, geen getopt enzo), maar het werkt.

Pull dus even, dan kunnen we afstemmen

Klinkt verder wel goed!

Ik zou het wel leuk vinden als de implementatie maken door basic users gedaan kan worden, dat houdt het makkelijk voor mensen om plugins te maken. Als zij zelf al reverse dependancy injection moeten doen om hun plugin werkend te krijgen zou natuurlijk jammer zijn

[ Voor 49% gewijzigd door FireDrunk op 10-01-2014 12:40 ]

[CurlyMo]

Kunnen jullie deze gesprekken niet beter op git voortzetten?

[FireDrunk]

offtopic:
Heb hem al een DM gestuurd en mijn Skype adres gegeven, maar hij reageert niet

Zeker, moet ook

[ikkeenjij36]

Hallo ik wil ook nog eens een keer reageren,jullie zijn allemaal een stuk in deze materie thuis als de huis tuin en keuken gebruiker zoals ik.
Ik weet alleen dat er bij op 1 of andere manier ergens iets mis gaat en dat ik dan weer een herinstalatie moet doen.
Erg lastig voor mij omdat alles weer opnieuw gedownload moet worden.
Daarom hoop ik dat er gauw de volgende release aankomt zoals cipher dus al 2 weken geleden liet weten,helaas is er nog niks te vinden en wacht ik met grote smart op de nwe release misschien dat het dan allemaal wat stabieler wordt en ik het gewoon kan laten draaien.
Nu wil ik er alleen de services sabnzbd erop zetten en plex zodat er in huis tenminste media gekeken kan worden.

[Verwijderd]

Beta9 is een dag vertraagd; zie het ZFSguru development forum; Jason heeft een update geplaatst.

Maar de functionaliteit die jij wilt zit pas in beta11; de migration manager. Dan wordt het makkelijker opnieuw te installeren omdat je je settings kunt meenemen. Nu kan dat nog niet of je moet het handmatig doen. Voor specifieke problemen kun je beter niet in dit topic posten; voorlopig is het ZFS topic daarvoor de aangewezen plaats. Of het ZFSguru forum natuurlijk.

[ikkeenjij36]

Verwijderd schreef op zaterdag 11 januari 2014 @ 20:00:
Beta9 is een dag vertraagd; zie het ZFSguru development forum; Jason heeft een update geplaatst.

Maar de functionaliteit die jij wilt zit pas in beta11; de migration manager. Dan wordt het makkelijker opnieuw te installeren omdat je je settings kunt meenemen. Nu kan dat nog niet of je moet het handmatig doen. Voor specifieke problemen kun je beter niet in dit topic posten; voorlopig is het ZFS topic daarvoor de aangewezen plaats. Of het ZFSguru forum natuurlijk.

Uiteraard snap ik dat dit geen bug report forum is,maar zoals al eerder aangegeven ook per pm zijn mijn bugs bekend bij jou cipher.
Kijk waar jij en firedunk en de rest van de zeer slimme mensen hier over praten hebben jullie het over dingen die ik totaal niet begrijp,misschien geldt dat voor meerdere gebruikers zoals ik,natuurlijk snap ik het idee dat jullie met zijn allen veel verder denken over het os en aanverwante dingen maar voor mij is het allemaal moeiliijk te volgen en aangezien het op het forum erg rustig is wat betreft support hou ik de 2 topics in de gaten.
Ik hoop dat je me het niet kwalijk neemt maar ik hoop dat er ook ruimte is voor de mensen die niet zo in het programeer gedeelte erg thuis zijn.
Ik heb ondertussen ook begrepen dat er ergens nog een bug in bsd zit en dat daardoor de release weer vertraging opgelopen heeft dus na en kleine uitstap naar een ander os gemaakt te hebben kom ik toch weer terug naar zfsguru wat toch voor een huis tuin en keuken gebruiker erg makkelijk werkt.

[Verwijderd]

Ik hoop dat je me het niet kwalijk neemt maar ik hoop dat er ook ruimte is voor de mensen die niet zo in het programeer gedeelte erg thuis zijn.

Zeer zeker wel, bij ZFSguru en ook in deze discussie. Maar problemen met Plex e.d. horen hier natuurlijk niet thuis, tenzij je het onderdeel van de discussie wilt maken.

Het forum is rustig ja, misschien straks met de nieuwe website een stuk drukker. Hoop ik dan. Beta9 gaat er komen, ik zou gokken op morgen of overmorgen. Kan nu niet lang meer duren.

Nu al is ZFSguru denk ik inderdaad het gemakkelijkste ZFS platform. Met beta9 komt daar een belangrijke schep bovenop met makkelijke Samba/NFS shares en permissies, en in komende releases wordt ZFSguru volwassener/uitgebouwd. Kortom, best een leuke toekomst.

[ikkeenjij36]

Uiteraard plaats ik hier geen probs met plex of een andere service,daar zijn andere forums voor.
Maar de problemen die ik heb is dat er regelmatig er services uitvallen door onbekende oorzaak,dat vindt ik zo jammer van zfsguru,ik wil hem gebruiken voor/als mediaserver en nog wat xtra dingen zoals eerder aangegeven in pm en ik weet dat jullie daarover nadenken.
Ik zou toch ook graag weten waar de problemen vandaan komen dat ineens services uitvallen of niet aan willen gaan.
Ook al een keer gehad na een clean install dat de service sabnzbdplus maar partial draaide.
Maar goed ik ga hem nu weer installeren en dat de nwe release makkelijk te upgraden is want ook dat is mij niet duidelijk want het enigste wat ik eens geprobeerd heb is systeem 10,0 instaleren en dat ook dan 9.2 er nog op staat en dat je dus 2 systemen heb draaien en bij allebei de services naar mijn inzicht weer moet instellen.

[EnerQi]

Wat ik als positief punt zie, is dat ZFSguru apart geinstalleerd kan worden. Ik heb 'm bijvoorbeeld op een aparte externe usb 3.0 harddisk staan. Mocht ZFSguru buggy worden (most unlikely) of ik ben weer instellingen aan het proberen (most likely) dan kan ik vrij snel ZFSguru opnieuw installeren ZONDER mijn data kwijt te zijn. I love it!

Ook al een keer gehad na een clean install dat de service sabnzbdplus maar partial draaide.

Dit gebeurd bij mij meestal met rebooten. De overige services van Sabnzbd (CouchPotato, Sickbeard, Headphones, etc ) starten niet automatisch.

[ikkeenjij36]

En we zijn een dag later,wordt het vandaag gereleased

[syl765]

@EnerQi

Dit kan (moet) zelfs bij FreeNAS, deze wil een aparte disk voor het OS.
Wat dan weer jammer is is het feit dat je er volgens mij geen pool van kan maken.

Maar ik zal FreeNAS weer eens moeten installeren.
Samba 4.1.3 zit nu ook in FreeNAS (nog niet gereleased) , en dat is wel erg mooi, Je eigen AD DS server zonder windows.
Als ik het goed begrijp komt samba 4.1.3 in FreeNAS 9.2.1

gr
Johan

[syl765]

@ Cipher

Zojuist zfsguru weer eens geinstalleerd.
De laatste versie gedownload
Download ZFSguru with FreeBSD 9.2 and ZFS v5000 (recommended)

Ten eerste kon zfsguru mijn ip niet achterhalen?
met ifconfig kon ik deze opzoeken en met de browser er naar toe.
Het ncurses scherm gaf aan http://0.0.0.0 (loop)

Wat ik onhandig vind aan de installer is dat ik MOET klikken op import pools voordat ik een pool kan maken.
De gui laat daarna pas de pagina zien waar ik een pool kan maken.
Maar als ik weet dat ik geen pools wil importeren, laat mij dan die keuze overslaan.

Dan de pool maken.
Drie opties..

Modern ZFS
Reduced ZFS version, compatible with older platforms
Choose your own version:

Ik kies voor Modern ZFS, maar als de pool gemaakt is heb ik SPA 28 ?? ik had feature 5000 verwacht..

code:

Pool name   SPA     Redundancy  Capacity    Used    Free    Status
zroot   28  RAID0 (no redundancy)   19.9G   1.02M   19.9G   ONLINE

Ik zou de opties een andere benaming geven iets in de trand van.
Latest version (5000)
Reduced version (28) compatible with older systems
Choose your own version:

Daarna de activering. Dan komt voor mij het vage gedeelte van de installatie.
Ik kom op het punt waar ik kan kiezen voor de webgui versie en de image.
Ik kies voor de recommended optie selecteer dan de nieuwe beta9 interface. Deze komt direct in beeld, maar dan is het heel lastig om te weten waar je bent in de installatie.

Ik weet dat ik de laatste GUI heb maar nu?

code:

Powered by ZFSguru version 0.2.0-beta9
Running official system image 9.2-001 featuring FreeBSD 9.2-RELEASE with ZFS v5000.
Running from the LiveCD - not installed yet!

Nu moet ik op de gok gaan klikken waar ik verder kan met de installatie.
Dit moet dus zijn system en dan het tabblad install en hier kan ik weer verder.
Het zou mooier zijn als de opties om te klikken beperkt blijft tot de install zolang er nog geen volledige install is gedaan.
Dus zolang er nog geen install is gedaan, alle andere opties niet beschikbaar maken en alleen de install optie weergeven.

Op de laatste pagina van de installatie kan ik niet selecteren lz4 compressie aangezien dit alleen voor v5000 geldig is.
Maar de optie modern had deze als 5000 moeten aanmaken.

Dit was even snel wat ik ervaar als ik ZFSguru installeer.

De GUI ziet er wel mooi uit BTW!

[ Voor 5% gewijzigd door syl765 op 14-01-2014 16:12 ]

[CurlyMo]

syl765 schreef op dinsdag 14 januari 2014 @ 16:08:
@ Cipher
Dit moet dus zijn system en dan het tabblad install en hier kan ik weer verder.
Het zou mooier zijn als de opties om te klikken beperkt blijft tot de install zolang er nog geen volledige install is gedaan.
Dus zolang er nog geen install is gedaan, alle andere opties niet beschikbaar maken en alleen de install optie weergeven.

Je vergeet dat dit niet alleen een installatie medium is zoals bij Windows meestal het geval, maar tevens een Live OS die je kan gebruiken als je problemen heb met je vaste installatie (zoals bij veel *nix varianten).

[Verwijderd]

syl765 schreef op dinsdag 14 januari 2014 @ 16:08:
Ten eerste kon zfsguru mijn ip niet achterhalen?
met ifconfig kon ik deze opzoeken en met de browser er naar toe.
Het ncurses scherm gaf aan http://0.0.0.0 (loop)

Dan heb je mogelijk een parallelle poort actief (plip0) die het IP 0.0.0.0 krijgt.

Wat ik onhandig vind aan de installer is dat ik MOET klikken op import pools voordat ik een pool kan maken.

Onhandig misschien dat je 1x extra moet klikken, maar het is natuurlijk ter beveiliging van user error. De installer wilt geen disks overschrijven waar al een ZFS pool op staat. Dus dat is een feature and 'works as intended'. Echte mannen slaan de Welcome Wizard natuurlijk over en hebben volledige controle.

Maar als ik weet dat ik geen pools wil importeren, laat mij dan die keuze overslaan.

De Welcome Wizard staat geen 'foot shooting permission' toe, wat in feite is wat jij wilt.

Je kunt ook sysctl geom.debugflags=0x10 instellen, dan krijg je ook rechten om in gebruik zijnde disks te formatteren. Als root mag je alles, maar wat is verstandig? Zeker omdat ZFSguru ook voor beginners gebruikt wordt, en de welcome wizard mag je aannemen dat je daar je handen niet snel aan kunt branden.

Ik kies voor Modern ZFS, maar als de pool gemaakt is heb ik SPA 28 ?? ik had feature 5000 verwacht..

Dat is expres op 28 gelaten. Als je LZ4 instelt, wordt de pool sowieso automatisch geupdate naar v5000. v28 is de beste en meest compatibele ZFS versie. Dat wordt als 'modern' gezien. v5000 als 'next gen' maar dus ook incompatible met Solaris ZFS.

Dan komt voor mij het vage gedeelte van de installatie.
Ik kom op het punt waar ik kan kiezen voor de webgui versie en de image.
Ik kies voor de recommended optie selecteer dan de nieuwe beta9 interface. Deze komt direct in beeld, maar dan is het heel lastig om te weten waar je bent in de installatie.

Waar heb je het hier over? Waar moet je kiezen tussen de WebGUI en de image? Bedoel je installatie stap 2, waar je de systeemversie selecteert? Wat bedoel je met kiezen tussen WebGUI en image dan?

Nu moet ik op de gok gaan klikken waar ik verder kan met de installatie.

Als je de welcome wizard hebt doorlopen krijg je op de laatste pagina een directe link naar de installatie. Als je die niet volgt of de wizard skipt, zul je handmatig naar System->Install moeten gaan.

Het zou mooier zijn als de opties om te klikken beperkt blijft tot de install zolang er nog geen volledige install is gedaan.

Absoluut niet! Dan zou je de LiveCD alleen als installer kunnen gebruiken en niet als diagnostics. Zo zijn er mensen die ZFSguru LiveCD gebruiken alleen om een SSD te TRIM-erasen, omdat dat onder Linux met zoveel ellende gepaard gaat, terwijl het in ZFSguru met 2 seconden gebeurd is.

Op de laatste pagina van de installatie kan ik niet selecteren lz4 compressie aangezien dit alleen voor v5000 geldig is.

Dat klopt inderdaad. Daar heb je misschien een punt. Stel je LZ4 compressie in via de Files pagina, dan wordt de pool automatisch geupgrade naar v5000. Op de installatiepagina gebeurt dit niet zo en kun je LZ4 niet selecteren als je pool niet v5000 is.

Dit was even snel wat ik ervaar als ik ZFSguru installeer.
De GUI ziet er wel mooi uit BTW!

Ondanks dat je sommige zaken als onhandig ervaart klopt het opzich wel. Enkele punten die je noemt kunnen wel verbeterd worden. De 0.0.0.0 bug vind ik dan nog het meest irritant/urgent. Maar draai dan ook geen parallelle poort; al die legacy zooi is alleen maar irritant.

[syl765]

Je vergeet dat dit niet alleen een installatie medium is zoals bij Windows meestal het geval, maar tevens een Live OS die je kan gebruiken als je problemen heb met je vaste installatie (zoals bij veel *nix varianten).

Dat is inderdaad waar, maar zodra ik met andere *nix varianten op de installer klik, dan kom ik in de installer, en dan kan ik netjes de stapjes volgen, nu kom ik opeens in een werkende GUI waar ik nog veel meer kan doen. Dat werkt verwarrend. Ik was bezig met de install, daar had ik voor gekozen, laat mij dan dit eerst afmaken voordat we ergens anders terecht komen.

[Verwijderd]

Kan verwarrend zijn omdat het afwijkend is; ZFSguru laat veel dingen toe waarvan mensen verwachten dat dat niet zou kunnen. Bijvoorbeeld een 2e installatie doen terwijl je op dezelfde disk draait. Hoef je bij Windows niet te proberen natuurlijk, en zelfs Linux ondersteunt dat niet. ZFSguru wel.

Ik was bezig met de install, daar had ik voor gekozen, laat mij dan dit eerst afmaken voordat we ergens anders terecht komen.

Je was bezig met de Welcome Wizard; dat is nog niet de installatie. Na het afronden van de welcome wizard krijg je een pagina met een grote link naar de installatiepagina. Misschien heb je die gemist of heb je vanaf dat moment op een andere link geklikt. Het is op die laatste pagina namelijk dat de tabbladen (status-network-disks-etc) zichtbaar worden; die zijn verborgen zodra je de welcome wizard nog draait. Als je de wizard skipt of doorlopen hebt, worden de tabs zichtbaar en mag je doen wat je wilt doen.

Toch juist goed zo? Je hebt mogelijk de link naar de installatiepagina gemist. Die staat echter wel vrij prominent op de laatste pagina van de Welcome Wizard.

[syl765]

Nog even een opmerking.

Aanmaken gebruikers, bij het wachtwoord invoeren zie ik mijn wachtwoord in beeld, het is mooier als deze voorzien worden van sterretjes of iets anders. Of een checkbox show password!

De pagina Disks en dan tabblad I/O monitor geeft een mooi overzicht.
Het filer is helaas niet normaal aan te passen aangezien je niet snel genoeg bent voordat de pagina opnieuw geladen word. Als je op de knop use Filter klikt, dan kom je op de pagina Disks / formatting uit ?

gr
Johan

[ Voor 3% gewijzigd door syl765 op 14-01-2014 16:54 ]

[CurlyMo]

Verwijderd schreef op dinsdag 14 januari 2014 @ 16:37:
Kan verwarrend zijn omdat het afwijkend is; ZFSguru laat veel dingen toe waarvan mensen verwachten dat dat niet zou kunnen. Bijvoorbeeld een 2e installatie doen terwijl je op dezelfde disk draait. Hoef je bij Windows niet te proberen natuurlijk, en zelfs Linux ondersteunt dat niet. ZFSguru wel.

Je kunt prima Ubuntu installeren terwijl je Windows draait (op dezelfde schijf)

Ik heb lang geleden al aangegeven dat ik graag een login prompt wil met daarna een shell GUI (net zoals ik bij XBian heb gedaan). Het is afwachten tot ik als gebruiker zulke dingen direct kan inbrengen. Wachtwoorden instellen als clear text vind ik ook raar.

[ Voor 21% gewijzigd door CurlyMo op 14-01-2014 16:40 ]