Welk Linux distro voor serieuze sofwarerelease ?

[kamiel299]

Wij zijn bezig een serieus commercieel software systeem on-top-of Linux/Fuse, op te zetten. Closed source Onze doelgroep bestaat uit grote installaties waar men serieus bezig is met Linux als backend (geen gehobby dus maar nagenoeg 'mission critical')

De ontwikkeling zijn we begonnen op Ubuntu 8.10 LTS zonder dat daar erg over nagedacht is. min of meer automatisch is dit dus nu het enige disto die we nu supporten, puur ondat we maar een disto willen/kunnen supporten. Nu merken we dat potentieele afnemens daar toch vaak moeite mee hebben. Ubuntu wordt toch veelal als 'speelgoed' gezien. Ontrecht IMHO, maar het is het marktgevoel.

We gaan dus porten naar een andere distro; vraag is WELKE ?

• CentOS/RedHAT ?
• Suse ?
• of toch BSD ?

Ik ben erg benieuwd naam onderbouwde meningen/ideeen welke disto nu :

• Mission critcal kan worden ingezet
• Long term support heeft
• Bij voorkeur een mogelijkheid tot betaalde support biedt
• andere issues die we over het hoofd zien maar die wel van belang zijn ?

Alvast dank voor iedere input

Kamiel

[Guru Evi]

Waarom kiezen? Gewoon uitbrengen voor alle platformen. Sinds je reeds bezig bent met Ubuntu kun je de software verpakken voor nagenoeg alle Debian distro's. Dan nog een RPM pakketje en je hebt Fedora/RedHat/CentOS/SuSE.

Als je het systeem gewoon open sourced kunnen anderen meewerken aan verpakken voor andere distro's of installeren op hun eigen systeem (zoals Slackware of Gentoo).

Je moet zien wat je klalnten gebruiken, zover ik kan zien heb je gewoon een slecht business model want je hebt blijkbaar geen idee hoe Linux werkt, wat je klanten verwachten, wie je potentiele klanten zijn en welke distro's tegenwoordig commercieel support hebben.

[ Voor 25% gewijzigd door Guru Evi op 08-05-2010 22:19 ]

[Anoniem: 187577]

FreeBSD (geen linux dus) wordt ook vaak bij mission critical systemen ingezet. Linux en FreeBSD zou ik allebei als zeer stabiel beschouwen.

Andere factoren zijn natuurlijk het filesystem en of je LVM (of ZFS in fbsd) wil gebruiken om het een en ander te gaan beheren. Ook of je dingen wil gaan virtualiseren, dan zijn freebsd jails bijvoorbeeld ideaal. In linux zou je dan kunnen kijken naar kvm of xen. Dit zou de beveiliging wel ten goede komen.

Ik weet niet of ZFS nog steeds ondersteuning krijgt, maar dat lijkt mij wel. Support kan je trouwens ook krijgen van andere bedrijven dan het bedrijf zelf (of community) achter het OS.

Zet software op een rij die je graag wil gaan gebruiken en zoek daarna uit welke kernel deze zaken het meest stabiel kan leveren.

@Guru Evi: ik denk dat die software dedicated gedraaid wordt op die server (als backend)
@Sallin: Ik had het erover dat linux stabiel is, de kernel zelf .

[ Voor 3% gewijzigd door Anoniem: 187577 op 08-05-2010 22:51 ]

[Sallin]

Ik heb het idee dat Redhat en Debian het meest gebruikt worden voor professionele toepassingen. Redhat biedt betaald service aan, Debian volgens mij niet. Verder is Debian nogal militant "free", dus dat lijkt mij niet per se een voordehand liggende doelgroep.

Verder sluit ik me redelijk aan bij Guru Evi.

@rutgerlak, de stabiliteit van "linux" hangt wat mij betreft nogal af van de distro. Bleeding edge distro's zou ik niet stabiel willen noemen, terwijl Debian stable toch wel een goede naam op dat gebied heeft (met zijn eigen nadelen).

[zordaz]

In de zakelijke wereld zie je vooral RedHat en in mindere mate Suse. RedHat is echter niet erg goedkoop. Ubuntu 8.10 is overigens geen LTS, 8.04 was dat wel. Een klant met enig verstand van zaken zou eerlijk gezegd moeten snappen dat een LTS van Ubuntu echt wel stabiel is (zeker als ie al twee jaar uit is). En als je een voorbeeld zoekt: heel Wikipedia.org draait op Ubuntu Server! Debian wordt uiteraard ook zakelijk gebruikt, maar daar hoor je niet zoveel over. Volgens mij gebuikt in NL o.a. Telegraaf Media Groep Debian.

Aangezien elke Ubuntu-release een fork is van Debian zou dat voor jullie normaal gesproken het eenvoudigste migratiepad zijn. Overigens neem ik aan dat je deb-jes maakt van jullie software. Er is best kans dat die gewoon al compatible zijn met Debian Stable. Betaalde support op Debian bestaat echter niet bij mijn weten.

Al met al denk ik dat het relatief eenvoudig is om debjes en rpms van jullie software te maken voor de meest gangbare Debian / Ubuntu en Redhat / CentOS releases. Wel moet je dan natuurlijk nadenken welke platform jullie voorkeur heeft qua support.

[ Voor 15% gewijzigd door zordaz op 09-05-2010 11:56 ]

[kamiel299]

Even wat korte aanvullingen/reacties

We werken aan een systeem voor een kleine, hoogs kritische doelgroep die tot heden proprietaty Unixen gebruikte. Linux is gevoelsmatig voor hen al een hele stap.

>> Waarom kiezen? Gewoon uitbrengen voor alle platformen
Omdat we maar een (zeer beperkt aantal) systeem(en) door en door gaan testen en garanderen.

>>Ubuntu 8.10 is overigens geen LTS, 8.04 was dat wel.
correct, we zoeken naar een distro met een langzame cyclus dus LTS stond op de wishlist. We draaien nu 8.10 (no LTS)

>>Als je het systeem gewoon open sourced kunnen anderen meewerken
Bij een zeer klein doelpubliek werkt Open Source m.i. niet. Er zijn te weinig stakeholders die er effort in gaan steken. Mission critical klanten willen ook niet afhankelijk zijn van de goodwill van een paar (verdwijnende) developpers die toevallig hun distro ondersteunen. Tevens is software die >gevoelige< zaken bevat (denk aan zaken die in het patent circuit zitten of militair van belang zijn) ook minder geschikt voor open source. Voor je het weet heb je wat noord korreaanse co-developpers.

>>ant je hebt blijkbaar geen idee hoe Linux werkt
Blijkbaar suggereer je dus dat jij dat wel weet dus leg het maar eens uit. En dan graag ff iets verder dan 'alles moet open source, anders wil ik niet met je $pelen". FYI: Software 'onTop of linux' valt niet onder GNU en kan closed source. In onze opinie dus gewoon een andere Unix variant.

>>@Guru Evi: ik denk dat die software dedicated gedraaid wordt op die server (als backend)
Correct

>>denk ik dat het relatief eenvoudig is om debjes en rpms van jullie software te maken voor de meest >>gangbare Debian / Ubuntu en Redhat / CentOS releases. Wel moet je dan natuurlijk nadenken welke
>> platform jullie voorkeur heeft qua support.
Portering is technisch niet zozeer de issue. Het gaat er meer om hoe we met zo min mogelijk versies (vanwege onderhoudbaarheid, qualifying trajecten en garanties) een zo breed mogelijke marktacceptatie krijgen. Ubuntu werkt prima maar sites die helemaal op RH zitten gaan niet een vreemde eend inzetten. Support technisch niet houdbaar.

Mijn eigen idee was om naar Radhat te gaan (voor hen die duur op de eerste rij willen zitten en ook commercieele support willen inkopen) en om een schaduwtraject (qua testing) op CentOS te laten lopen voor hen die gratis willen. Hiermee kunnen we met een (1) codebase/qualifying traject beide typen klanten bedienen.

benieuwd naar jullie gedachten.

Kamiel

[Cidolfas]

Persoonlijk zou ik voor RedHat en CentOS gaan inderdaad. Veel klanten willen support voor mission critical services, en daar bij is RH wel de industrie standaard.

[DeBolle]

Neem bij 'mission critical' ook de mogelijkheid van clustering in overweging voor klanten die daar op staan: je zult naar mijn mening (en het beetje marktinzicht dat ik op dat vlak heb) willen kijken naar Heartbeat en Serviceguard met de daarbij best passende filesystems.

[BHQ]

Hmm, met Ubuntu en Debian zet je al een goede stap. Daarnaast Red Hat en evt CentOS. In feite heb je dan 2 platformen om te supporten.

Ik weet niet of je afhankelijk bent van andere packages/libraries en of daar recente versies van nodig zijn? anders kan Debian Stable wellicht eens lastig worden, ivm. wat oudere packages en libraries in de repo's.

Daarnaast is iets als FreeBSD ook mooi om naar te porten ja. Op een of andere manier denk ik dat FreeBSD meer in de smaak zal vallen bij de Unix guru's, maar daar kan ik volledig naast zitten.

[JaQ]

/me Ik werk als Oracle manus van alles, derhalve is mijn mening / ervaring gekleurd !

Ik weet best dat je je pakket uiteindelijk op zo ongeveer alle linux distro's zou kunnen gaan draaien, maar wellicht is het verstandig om je aan te passen aan je omgeving. Een kort onderzoek onder je (potentiële) klanten lijkt me derhalve op zijn plaatst. Let hierbij ook op de keuze van software waarmee je moet interfacen. Denk dus na over wie je wat vraagt, antwoorden zijn immers over het algemeen egocentrisch opgesteld

In mijn ervaring zijn sites, die vanaf een commercieel Unix komen, allemaal naar RedHat gegaan. Bedrijven die software willen leveren die niet op RedHat draait, hebben per definitie pech (er wordt geen Debian toegelaten in een RedHat omgeving).

[Anoniem: 28958]

kamiel299 schreef op zondag 09 mei 2010 @ 13:15:
Even wat korte aanvullingen/reacties

We werken aan een systeem voor een kleine, hoogs kritische doelgroep die tot heden proprietaty Unixen gebruikte. Linux is gevoelsmatig voor hen al een hele stap.

Als het zo mission critical is, waarom ben jij er dan een onderdeel van? Als ik jouw klant zou zijn en ik zou bovenstaande zin zien, dan zou ik snel iemand opzoeken die wel kan spellen.

>> Waarom kiezen? Gewoon uitbrengen voor alle platformen

Omdat we maar een (zeer beperkt aantal) systeem(en) door en door gaan testen en garanderen.

Ik weet niet wat je onder testen verstaat, maar als het echt mission critical is kom je daar niet zo ver mee.

>>Ubuntu 8.10 is overigens geen LTS, 8.04 was dat wel.
correct, we zoeken naar een distro met een langzame cyclus dus LTS stond op de wishlist. We draaien nu 8.10 (no LTS)

Iedereen die gebruik maakt van "Linux" die een beetje geavanceerd bezig is wil zelf zijn kernel kunnen compilen.

>>Als je het systeem gewoon open sourced kunnen anderen meewerken
Bij een zeer klein doelpubliek werkt Open Source m.i. niet. Er zijn te weinig stakeholders die er effort in gaan steken. Mission critical klanten willen ook niet afhankelijk zijn van de goodwill van een paar (verdwijnende) developpers die toevallig hun distro ondersteunen. Tevens is software die >gevoelige< zaken bevat (denk aan zaken die in het patent circuit zitten of militair van belang zijn) ook minder geschikt voor open source. Voor je het weet heb je wat noord korreaanse co-developpers.

Wat jij denkt over Open Source heeft niets te maken met de werkelijkheid. Als jullie bedrijf achter de software gaat staan en contracten afsluit over ondersteuning is dat best mogelijk. Wat iets realistischer is, dan alles te open sourcen is alle afhankelijkheden goed documenteren en dan uitspraken te doen als "heb je versie X.Y.Z van bibliotheek Foo met compile opties A, B,C, dan beloven wij dat het werkt". Je kunt dit hetzelfde doen voor kernels natuurlijk. Alle Linux distros zijn nl. uiteindelijk nog gewoon "Linux". Voor mission-critical systemen moet je natuurlijk wel weten bijv. welke scheduler er gebruikt wordt en zo zijn er waarschijnlijk nog wel een paar honderd dingen waarop je voor een realistisch systeem moet testen (d.w.z. of de feature aanwezig is of niet). Als je het alleen voor kernels wilt doen moet je de software gewoon statisch compileren, maar ook dat heeft nadelen.

Wat betreft de Noord-Koreaanse ontwikkelaars kan ik zeggen dat niet alles van een geheim militair systeem ook daadwerkelijk geheim hoeft te zijn. Bepaalde data structuren zou je bijv. makkelijk kunnen open-sourcen. En je bent er natuurlijk altijd nog zelf bij of je de aanpassingen van derde partijen wilt accepteren of niet.

>>ant je hebt blijkbaar geen idee hoe Linux werkt
Blijkbaar suggereer je dus dat jij dat wel weet dus leg het maar eens uit. En dan graag ff iets verder dan 'alles moet open source, anders wil ik niet met je $pelen". FYI: Software 'onTop of linux' valt niet onder GNU en kan closed source. In onze opinie dus gewoon een andere Unix variant.

En dit kan ook gewoon, maar ik begrijp eigenlijk niet hoe je iets mission critical niet in kernel space wilt laten draaien, maar goed. Als je het in user-space laat draaien, kun je inderdaad de broncode gesloten houden.

>>@Guru Evi: ik denk dat die software dedicated gedraaid wordt op die server (als backend)
Correct

>>denk ik dat het relatief eenvoudig is om debjes en rpms van jullie software te maken voor de meest >>gangbare Debian / Ubuntu en Redhat / CentOS releases. Wel moet je dan natuurlijk nadenken welke
>> platform jullie voorkeur heeft qua support.
Portering is technisch niet zozeer de issue. Het gaat er meer om hoe we met zo min mogelijk versies (vanwege onderhoudbaarheid, qualifying trajecten en garanties) een zo breed mogelijke marktacceptatie krijgen. Ubuntu werkt prima maar sites die helemaal op RH zitten gaan niet een vreemde eend inzetten. Support technisch niet houdbaar.

Als je kijkt naar populaire Linux software zie je dat deze software zo ongeveer overal draait (d.w.z. ook op FreeBSD, Mac, en commerciele Unix distributies). Deze software is vaak van de hoogste kwaliteit, juist _omdat_ het op zoveel platformen werkt. Het is heel makkelijk een regel code te schrijven die alleen toevallig op dat platform werkt.

Mijn eigen idee was om naar Radhat te gaan (voor hen die duur op de eerste rij willen zitten en ook commercieele support willen inkopen) en om een schaduwtraject (qua testing) op CentOS te laten lopen voor hen die gratis willen. Hiermee kunnen we met een (1) codebase/qualifying traject beide typen klanten bedienen.

benieuwd naar jullie gedachten.

Zoals velen denk ik dat het concept om tegen je klanten te zeggen "we doen alleen versie X van Linux distro Y" resulteert in iets dat we EPIC FAIL noemen, maar je mag het best proberen en vertellen wat er van je bedrijf terecht is gekomen over een paar jaar.

[kamiel299]

Gezien de haast vijandige ondertoon in een aantal reacties stop ik met deze discussie.

Ik dacht dat we zo onderhand af waren van de opensource fanboy gevoeligheden. Ik dacht dat we leefden in een reële wereld waarin opensource toepassen als dat gunstig is voor alle partijen, maar waarin ook situaties voorkomen dat een commercieel model voldoet. Bijvoorbeeld door end-to-end systemen te ontwikkelen die gewoon betaald worden en waarmee klanten zeer content zijn. Wij doen dit al voordat menigeen zijn c64-tje had dus ja; die epic fail kunnen we hebben.

over en uit.

[JaQ]

Anoniem: 28958 schreef op zondag 09 mei 2010 @ 15:40:
Als het zo mission critical is, waarom ben jij er dan een onderdeel van? Als ik jouw klant zou zijn en ik zou bovenstaande zin zien, dan zou ik snel iemand opzoeken die wel kan spellen.

Doe eens normaal joh.

kamiel299 schreef op zondag 09 mei 2010 @ 16:55:
Gezien de haast vijandige ondertoon in een aantal reacties stop ik met deze discussie.

Je kan ook een beetje tussen de regels lezen en sommige reacties negeren. Zelf weten

[Stacheldraht]

Ik zou Suse Linux Enterprise Server en Red Hat Enterprise Linux kiezen. Beide distro's zie je voornamelijk in het zakelijke segment terug.

[vanaalten]

Daarnaast misschien proberen te meten hoeveel werk het is om je software voor een bepaalde distro klaar te maken.
Stel dat je je richt om Red Hat en Suse, maar een potentieele klant gebruikt Debian. Wil je dan 'nee' zeggen, of wil je 'm uitleggen dat er een meerprijs is om 'm voor Debian klaar te maken?

[Anoniem: 294759]

Ik vind dat TS een beetje licht gevoelig reageert.

Maar dat even terzijde.. Zoals Stacheldracht al zei, Red Hat & Suse Enterprise is aan te raden. Je kan ook Cent OS erbij pakken want dat is zowat 1:1 met RH enterprise.

vanaalten schreef op zondag 09 mei 2010 @ 19:05:
Daarnaast misschien proberen te meten hoeveel werk het is om je software voor een bepaalde distro klaar te maken.
Stel dat je je richt om Red Hat en Suse, maar een potentieele klant gebruikt Debian. Wil je dan 'nee' zeggen, of wil je 'm uitleggen dat er een meerprijs is om 'm voor Debian klaar te maken?

Het is maar net wat voor klant het is. De grote ondernemingen gebruiken Debian niet. Debian zal je eerder zien bij hosting en development. Maar absoluut niet bij andere soorten bedrijven tenzij het een aparte functie heeft.
Dus als er zo'n klant is die dat heeft is dat zeer sporadisch dus ja. Dat is een verlies die je als onderneming kan nemen.

[ Voor 63% gewijzigd door Anoniem: 294759 op 09-05-2010 19:10 ]

[Anoniem: 237999]

Anoniem: 28958 schreef op zondag 09 mei 2010 @ 15:40:
Zoals velen denk ik dat het concept om tegen je klanten te zeggen "we doen alleen versie X van Linux distro Y" resulteert in iets dat we EPIC FAIL noemen, maar je mag het best proberen en vertellen wat er van je bedrijf terecht is gekomen over een paar jaar.

Weleens geprobeerd om jouw product op alle Linux varianten (distros/versies) te testen? Durf jij je hand er voor in het vuur te steken dat jouw product op elke willekeurige Linux variant probleemloos werkt? Durf jij een SLA aan te gaan ongeacht het platform waarop jouw klanten het product gebruiken?

[Anoniem: 294759]

Er is zat software wat op ieder unix/Linux based Os draait. Alleen is het de vraag hoe lang het zal duren totdat je het allemaal kan afvangen. Alleen al het afvangen tussen RISC en CISC CPU's is la een hels werk laat staan compatible maken naar het OS.

[Anoniem: 237999]

Anoniem: 294759 schreef op zondag 09 mei 2010 @ 20:21:
Er is zat software wat op ieder unix/Linux based Os draait. Alleen is het de vraag hoe lang het zal duren totdat je het allemaal kan afvangen. Alleen al het afvangen tussen RISC en CISC CPU's is la een hels werk laat staan compatible maken naar het OS.

Er is een groot verschil tussen software die (in potentie) op ieder Unix/Linux based OS draait en het daadwerkelijk garanderen en ondersteunen van die software op elke willekeurige Unix/Linux variant. En met ondersteunen bedoel ik niet een helpdesk medewerker die vriendelijk de klaagzang van de klant aanhoort, maar het binnen een vooraf bepaalde tijd een oplossing aandragen voor het probleem. Dat wordt moeilijker en kostbaarder naarmate je meer platformen moet gaan ondersteunen. Dat de TS in zijn situatie ervoor kiest om slechts een beperkt aantal platformen te ondersteunen kan ik in zijn situatie goed voorstellen.

[himlims_]

Stacheldraht schreef op zondag 09 mei 2010 @ 18:44:
Ik zou Suse Linux Enterprise Server en Red Hat Enterprise Linux kiezen. Beide distro's zie je voornamelijk in het zakelijke segment terug.

dat sowieso - pest is dat al die verschillende versies vaak andere locaties/files/libs etc. hebben. sterkste blijft een universeel systeem, maar of dat zo gemakkelijk gaat. allemaal andere packetsysteempjes

[Anoniem: 8504]

Stacheldraht schreef op zondag 09 mei 2010 @ 18:44:
Ik zou Suse Linux Enterprise Server en Red Hat Enterprise Linux kiezen. Beide distro's zie je voornamelijk in het zakelijke segment terug.

Eens, ik doe veel in datacenters en dit zijn eigenlijk de enige 2 serieuze kandidaten in dit soort omgevingen. Overigens zou ik persoonlijk nooit een mission critical systeem op Linux laten draaien en dat standpunt is vooral uit ervaring gegroeid (werk zelf trouwens al bijna 9 jaar met linux).

[ Voor 4% gewijzigd door Anoniem: 8504 op 09-05-2010 21:55 ]

[kamiel299]

Anoniem: 237999 schreef op zondag 09 mei 2010 @ 20:39:
[...]


Er is een groot verschil tussen software die (in potentie) op ieder Unix/Linux based OS draait en het daadwerkelijk garanderen en ondersteunen van die software op elke willekeurige Unix/Linux variant. Dat de TS in zijn situatie ervoor kiest om slechts een beperkt aantal platformen te ondersteunen kan ik in zijn situatie goed voorstellen.

Probleem is ook nog eens keten afhankelijkheid; De I/O card builder wenst een (non tainted) kernel van een specifieke versie, de hardware boer heeft zo zijn beperkingen in distro keuzevrijheid etc etc. Voldoe je niet dan stopt alle support. En als systeem bouwer/software leverancier heb je daar maar aan te voldoen. End-to-end supported betekend dat al deze zaken door een klant gechecked worden omdat ie fingerpointing bij issues wil voorkomen.Ook deze is wijs geworden. Tja, het ligt wellicht ver van het open source ideaal (alles moet passen/werken/ en anders doe je het zelf) af maar dit is de realiteit waarin we ook soms verkeren.

>>Overigens zou ik persoonlijk nooit een mission critical systeem op Linux laten draaien

Mission critical wil niet zeggen fail-safe maar dat het op het kritieke pad van het normale proces ligt.; Het wil zeggen dat de normale gang van zaken (de 'mission') geen doorgang vindt als het (hele) systeem eruit ligt. Dat kan, maar hoeft geen probleem te zijn. In dit geval werken we in een 4 uit 5 situatie die alleen besturing doet. Het failsafe gedeelte is in relais logica ondervangen.

[ Voor 18% gewijzigd door kamiel299 op 09-05-2010 22:08 ]

[mOrPhie]

Anoniem: 294759 schreef op zondag 09 mei 2010 @ 20:21:
Er is zat software wat op ieder unix/Linux based Os draait. Alleen is het de vraag hoe lang het zal duren totdat je het allemaal kan afvangen. Alleen al het afvangen tussen RISC en CISC CPU's is la een hels werk laat staan compatible maken naar het OS.

Inderdaad. Kunnen draaien en garanderen zijn twee heel verschillende dingen. Als jij software bouwt en nadat het draait zegt "het werkt", dan zeg ik dat je liegt of niet weet waar je het over hebt. Software ontwikkelen is één ding. Quality Assurance is een heel ander ding. De TS geeft aan dat het om een niche-product gaat, waarbij niemand zit te wachten op een port in alle distro's. Alle distro's garanderen (let op: ik zeg niet "kunnen draaien") is zeer kostbaar en de baten zijn zeer laag. Niet ieder project heeft de luxe die bijvoorbeeld het apache httpd project heeft van honderden kernontwikkelaars en duizenden contribs. Hell, 90% van de open source projecten heeft slechts 1 ontwikkelaar en "hoopt" vooral dat het uberhaupt blijft draaien op het ontwikkel-OS. Als je met beperkte middelen zit, moet je dus niet proberen groot te zijn. Je bent het niet, leef ernaar.

Dat gezegd hebbende. TS: Laat je niet kennen. Ik denk inderdaad dat vooral de bekende enterprise distro's van belang zijn om te ondersteunen, suse en red hat dus. Maar waarom vragen jullie het je klanten en prospects niet? Zo'n onderzoekje hoeft niet veel tijd te kosten dacht ik zo.

[smokalot]

kamiel299 schreef op zondag 09 mei 2010 @ 13:15:
>>Als je het systeem gewoon open sourced kunnen anderen meewerken
Mission critical klanten willen ook niet afhankelijk zijn van de goodwill van een paar (verdwijnende) developpers die toevallig hun distro ondersteunen.

Die klanten zijn juist minder afhankelijk van anderen als ze de code ook in handen hebben. Hoewel ik het niet helemaal eens ben met de redenen die jij aangeeft, is het inderdaad zo dat het soms het beste voor je bedrijf kan zijn om de code niet te leveren onder een vrije licentie.

Het is me niet helemaal duidelijk hoe jullie je product nu leveren, is dat een compleet pakket van hardware en software, dus voorgeinstalleerd, of leveren jullie een CD oid?

Het is al eerder gezegd, maar waarom kiezen jullie niet zelf één populair platform, CentOS/RHEL, die jullie ondersteunen, en zeggen jullie erbij dat jullie natuurlijk ook in te huren zijn om het geschikt te maken voor een ander platform? Als je dat eenmaal hebt gedaan kun je de volgende klant weer een bredere keuze bieden...

[kamiel299]

mOrPhie schreef op zondag 09 mei 2010 @ 22:11:
[...]
Maar waarom vragen jullie het je klanten en prospects niet? Zo'n onderzoekje hoeft niet veel tijd te kosten dacht ik zo.

zoals eerder al opgemerkt door JaQ:
>>Denk dus na over wie je wat vraagt, antwoorden zijn immers over het algemeen egocentrisch opgesteld

Als je een groep Unix veteranen (UX, Solaris, SunOS!! of AIX) gaat vragen naar hun Linux opinies dan gaan zaken alle kanten op. Ook dit zijn fanboys die hun heilige grond zien verdwijnen dus vaak is een mening hier erg gekleurd/extreem. Vandaar de (erg open) vraag aan een (hopelijk) open minded community die meerder invalshoeken kan belichten.

K

[downtime]

kamiel299 schreef op zaterdag 08 mei 2010 @ 22:13:
Ik ben erg benieuwd naam onderbouwde meningen/ideeen welke disto nu :

• Mission critcal kan worden ingezet

Misschien kun je beter omschrijven wat je bedoelt met "mission critical". Ik heb de indruk dat daar verschillende zaken onder worden verstaan. Voor sommige mensen is dat misschien een pakket waar je een kerncentrale meer wilt aansturen. In de omgeving waar ik werk kan een pakket voor de financiele administratie al als "mission critical" worden omschreven (als in: als de server problemen heeft, zitten er 1.000 man duimen te draaien, en is de schade mogelijk miljoenen per dag).

[kamiel299]

De Wiki definitie is er een waar ik me wel in kan vinden:

The term mission critical (refers to any factor (equipment, process, procedure, software, etc.) which is essential to the core function of an organisation. That is, it is critical to the organisation's 'mission'.

Dat wil dus niet zeggen dat de boel per definitie instort als e.e.a niet meer werkt, maar veel meer dat de doelstelling van de organisatie niet (meer) gehaald wordt. De impact in proces afhankelijk; Een proces dat uitstel kan verdragen wordt wel uiteraard wel beïnvloed maar veroorzaak geen rampen. Andere processen zijn wel (tijd)kritisch en kunnen wel rampzalig worden.

[downtime]

kamiel299 schreef op zondag 09 mei 2010 @ 13:15:
Omdat we maar een (zeer beperkt aantal) systeem(en) door en door gaan testen en garanderen.

Door en door testen is prima. Ondersteunen ook. Garanderen is een ander punt. Geen enkele klant gaat een systeem precies zo configureren als jij in je testlab hebt gedaan en je kunt daardoor nooit garanderen dat de boel werkt. Elke omgeving heeft nu eenmaal z'n bijzonderheden en er is altijd risico dat daardoor bij de klant iets niet werkt. Als je garanties gaat afgeven dan zie ik jullie bedrijf snel failliet gaan door schadeclaims van teleurgestelde klanten.

Ik zou het ruimer formuleren: Je levert een pakket, kunt de klant vertellen dat het uitvoerig getest is op distro X en distro Y, en dat je hem ondersteunt met zijn problemen mits hij distro X of distro Y gebruikt. Ga niet proberen om te garanderen dat het pakket werkt want een schadeclaim zit in een klein hoekje (tenzij de kosten van schadeclaims meegenomen zijn in de prijs van het pakket).

[Anoniem: 8504]

kamiel299 schreef op maandag 10 mei 2010 @ 01:00:
De Wiki definitie is er een waar ik me wel in kan vinden:

The term mission critical (refers to any factor (equipment, process, procedure, software, etc.) which is essential to the core function of an organisation. That is, it is critical to the organisation's 'mission'.

Dat wil dus niet zeggen dat de boel per definitie instort als e.e.a niet meer werkt, maar veel meer dat de doelstelling van de organisatie niet (meer) gehaald wordt. De impact in proces afhankelijk; Een proces dat uitstel kan verdragen wordt wel uiteraard wel beïnvloed maar veroorzaak geen rampen. Andere processen zijn wel (tijd)kritisch en kunnen wel rampzalig worden.

Vind ik ook een goede omschrijving.. Het ligt er inderdaad aan wat de "Mission" van een bedrijf is en wat eventuele business consequenties zijn van de downtime van het systeem. Als je voor onbepaalde tijd zonder je MC systemen kan, is Linux prima op zijn plaats. Maar ik zal je topic niet verder vervuilen..

[igmar]

De opmerking 'draait op elke linux / unix variant' is een nobel streven, maar niet erg reeel. Je zit alleen al op userspace met een 6 tal glibc varianten, en dan neem ik de rest van de libraries dan niet eens mee.
Helemaal vervelend wordt het als leveranciers dingen gaan backporten, waardoor dezelfde versie library op verschillende linux versies andere dingen doet.

Commercieel is het vooral RedHat en SuSE Enterprise wat veelgebruikt wordt. Aan het ondersteunen van die versies heb je denk ik je handen al vol, maar eea is ook afhankelijk wat precies het doel van de applicatie is.

Cross-platform ontwikkelen betekend echter dat je toch dingen zal moeten aanpassen voor elk platform specifiek, en ook dat kost tijd / geld.

[DutchNutcase]

Het bedrijf waar ik stage heb gelopen ondersteunt bepaalde kernel versies ipv een bepaalde distro. Dat zou je eventueel ook kunnen doen. Desnoods met aanvullende eisen erbij. Dan is iedere distro die pakketten X, Y en Z gebruikt in versies a.b.c goed genoeg.

[Greyfox]

kamiel299 schreef op zaterdag 08 mei 2010 @ 22:13:
Nu merken we dat potentieele afnemens daar toch vaak moeite mee hebben. Ubuntu wordt toch veelal als 'speelgoed' gezien. Ontrecht IMHO, maar het is het marktgevoel.

Ik vind dit een interessante discussie maar volgens mij ben je aan de verkeerde kant van de markt aan het vragen.
Je zegt dat potentiele afnemers moeite met Ubuntu hebben, zou je dan niet willen weten wat wel geaccepteerd is?
Anders port je straks je product naar een platform waar 'potentiele afnemers' nog steeds moeite mee hebben.
Een stuk marktonderzoek helpt je verder dan het forum hier denk ik.

[Anoniem: 28958]

Anoniem: 237999 schreef op zondag 09 mei 2010 @ 20:05:
[...]


Weleens geprobeerd om jouw product op alle Linux varianten (distros/versies) te testen? Durf jij je hand er voor in het vuur te steken dat jouw product op elke willekeurige Linux variant probleemloos werkt? Durf jij een SLA aan te gaan ongeacht het platform waarop jouw klanten het product gebruiken?

Voor user-space code durf ik zeker te zeggen dat mensen het mogen proberen en als het niet werkt dat ik zorg dat het werkt, ja.

Compile time garanties zijn niet mogelijk op Linux voor dingen die afhangen van een "omgeving", maar als het echt nodig is, kun je in principe best een embedded OS gebruiken dat deze garanties wel kent. En dat is ook wat bepaalde bedrijven doen; geen probleem in theorie. Ik heb dat specifiek nog nooit gedaan, maar ik weet wel hoe het zou moeten.

[Anoniem: 28958]

JaQ schreef op zondag 09 mei 2010 @ 17:20:
Doe eens normaal joh.

Ik betaal niet voor incompetentie. Dat u dat wel wilt doen, moet u zelf weten.

[Anoniem: 294759]

kamiel299 schreef op maandag 10 mei 2010 @ 00:12:
[...]


zoals eerder al opgemerkt door JaQ:
>>Denk dus na over wie je wat vraagt, antwoorden zijn immers over het algemeen egocentrisch opgesteld

Als je een groep Unix veteranen (UX, Solaris, SunOS!! of AIX) gaat vragen naar hun Linux opinies dan gaan zaken alle kanten op. Ook dit zijn fanboys die hun heilige grond zien verdwijnen dus vaak is een mening hier erg gekleurd/extreem. Vandaar de (erg open) vraag aan een (hopelijk) open minded community die meerder invalshoeken kan belichten.

K

Een volledig open-mind verwachten van unix veteranen is net zoiets als van de paus verwachten dat hij condooms uitdeelt in Afrika. Dit zal eenvoudig niet gebeuren simpelweg omdat iedere Unix veteraan zijn eigen voorkeuren heeft en deze voorkeuren dan ook als oplossingen zal voorschrijven. Het enige wat je kan doen is zelf je onderzoek doen en daaruit je eigen conclusies trekken.

Wat ik overigens niet snap is dat jullie niet de onderzoeken van externe partijen raadplegen voor het beantwoorden van deze vraag. Het lijkt mij dat bijvoorbeeld Gartner die dit soort vragen kunnen beantwoorden dmv hun eigen onderzoeken(En deze worden ook ieder jaar uitgegeven) iets voor jullie kunnen betekenen. Als jullie het echt willen weten dan is een minimale investering(want zo'n onderzoekresultaat wordt niet gratis weggegeven) dik de moeite waard.

[Anoniem: 28958]

Anoniem: 294759 schreef op maandag 10 mei 2010 @ 16:46:
[...]


Een volledig open-mind verwachten van unix veteranen is net zoiets als van de paus verwachten dat hij condooms uitdeelt in Afrika. Dit zal eenvoudig niet gebeuren simpelweg omdat iedere Unix veteraan zijn eigen voorkeuren heeft en deze voorkeuren dan ook als oplossingen zal voorschrijven. Het enige wat je kan doen is zelf je onderzoek doen en daaruit je eigen conclusies trekken.

Wat ik overigens niet snap is dat jullie niet de onderzoeken van externe partijen raadplegen voor het beantwoorden van deze vraag. Het lijkt mij dat bijvoorbeeld Gartner die dit soort vragen kunnen beantwoorden dmv hun eigen onderzoeken(En deze worden ook ieder jaar uitgegeven) iets voor jullie kunnen betekenen. Als jullie het echt willen weten dan is een minimale investering(want zo'n onderzoekresultaat wordt niet gratis weggegeven) dik de moeite waard.

Uh, Gartner?

Ik dacht dat iedereen dacht dat zij een grote grap waren, maar goed.

[Anoniem: 294759]

Anoniem: 28958 schreef op maandag 10 mei 2010 @ 16:55:
[...]

Uh, Gartner?

Ik dacht dat iedereen dacht dat zij een grote grap waren, maar goed.

Zolang grotere ondernemingen de onderzoeken van Gartner serieus blijven nemen, lijkt het mij dat Gartner serieuzer genomen kan worden dan jouw veronderstelling over hun.

[ Voor 8% gewijzigd door Anoniem: 294759 op 10-05-2010 17:07 ]

[u_nix_we_all]

Anoniem: 28958 schreef op maandag 10 mei 2010 @ 16:42:
[...]

Voor user-space code durf ik zeker te zeggen dat mensen het mogen proberen en als het niet werkt dat ik zorg dat het werkt, ja.

Compile time garanties zijn niet mogelijk op Linux voor dingen die afhangen van een "omgeving", maar als het echt nodig is, kun je in principe best een embedded OS gebruiken dat deze garanties wel kent. En dat is ook wat bepaalde bedrijven doen; geen probleem in theorie. Ik heb dat specifiek nog nooit gedaan, maar ik weet wel hoe het zou moeten.

Het staat er een beetje tegenstrijdig, maar het idee is misschien niet eens zo gek; als de applicatie toch stand-alone mag/moet draaien, waarom dan niet het hele systeem als "appliance" verkopen, dus hardware + OS + Software ( + support op alles). Kunnen jullie je beperken tot slechts één versie die uitgebreid getest wordt, en de klant heeft vaak meer vertrouwen in een "black-box appliance" dan een linux server met software. (Wat feitelijk hetzelfde is)

[lordgandalf]

with u_nix_we_all ^

verkoop het als een complete doos appliances zijn hot op het moment en dan weet je altijd dat je 100% jouw software draait.
Daarnaast geef je de kopende partij alleen beheer mogelijkheden en het gevaarlijk root account kun je voor remote beheer houden.
Een eigen repository met van te voren geteste packeten enz.
nieuwe versie kun je zelf eerst intern testen en dan op de repository server dumpen en iedereen krijgt de nieuwste versie

[Sypher]

Maakt het voor de klant überhaupt uit waar het op draait?
Ik zou als afnemer meer waarde hechten aan het product zelf dan op welk OS die draait.

We draaien zelf ook een behoorlijke hoeveelheid Debian en Ubuntu servers voor "mission critical".
Reden is dat het er zo een beetje is ingegroeid en omdat je het beste een basis kunt pakken waarmee je zelf goed uit de voeten kan.

[downtime]

Sypher schreef op maandag 10 mei 2010 @ 18:46:
Maakt het voor de klant überhaupt uit waar het op draait?

Sommige klanten kijken puur naar de applicatie en halen het bijbehorende OS dan ook wel in huis. Ik heb jaren geleden eens in de serverruimte van een bedrijf rondgelopen waar zeker 10 verschillende server-OS'en draaiden (HP-UX, SunOS, Tru64, OS/2, meerdere Windows versies, MacOS, etc). Het was nog niet eens een erg groot bedrijf ook.
Maar veel klanten willen juist standaardiseren op een bepaald OS en een specifieke versie daarvan omdat dat simpeler en goedkoper is en risico's verminderd.

[JaQ]

Anoniem: 28958 schreef op maandag 10 mei 2010 @ 16:45:
Ik betaal niet voor incompetentie. Dat u dat wel wilt doen, moet u zelf weten.

Volgens mij betaal je helemaal niet om hier te mogen posten

Op de man spelen (zelfs schofferen) omdat iemand een andere mening heeft dan jij, is naar mijn mening verre van fraai. Nu zal mijn mening je niet veel kunnen schelen, toch wil ik je aanraden om op zijn minst normale omgangsvormen te gebruiken. Dat zorgt er in ieder geval voor dat dit forum op de langere termijn ook een leuke plek blijft om informatie te zoeken.

Anoniem: 28958 schreef op maandag 10 mei 2010 @ 16:55:
Uh, Gartner?

Ik dacht dat iedereen dacht dat zij een grote grap waren, maar goed.

Dat denken veel techneuten, maar de mensen die beslissen (ook wel spreadsheetrakkers genoemd) lezen dat soort rapporten wel

u_nix_we_all schreef op maandag 10 mei 2010 @ 17:16:
Het staat er een beetje tegenstrijdig, maar het idee is misschien niet eens zo gek; als de applicatie toch stand-alone mag/moet draaien, waarom dan niet het hele systeem als "appliance" verkopen, dus hardware + OS + Software ( + support op alles). Kunnen jullie je beperken tot slechts één versie die uitgebreid getest wordt, en de klant heeft vaak meer vertrouwen in een "black-box appliance" dan een linux server met software. (Wat feitelijk hetzelfde is)

Volgens mij is dit erg afhankelijk van wat de appliance doet. Voor sommige zaken worden appliances geaccepteerd, maar ik zie ook regelmatig situaties waarin een appliance per definitie afvalt (bijvoorbeeld omdat de lokale beheerclub er geen fiducie in heeft).

[Anoniem: 237999]

Anoniem: 28958 schreef op maandag 10 mei 2010 @ 16:42:
[...]
Voor user-space code durf ik zeker te zeggen dat mensen het mogen proberen en als het niet werkt dat ik zorg dat het werkt, ja.

Of te wel: de klant mag voor tester spelen.

Nu ken ik het wereldje van van de TS niet, maar ik kan je verzekeren dat je dit soort geintjes lang niet overal kan flikken. Garanderen wat anders dan 'laat me maar weten als het niet werkt, dan fix ik het wel'. Je hebt gewoon jouw product te testen op de platformen waarvan jij garandeert dat het werkt, en hoe meer platformen jij beweert te ondersteunen des te meer test werk zal je hebben. Komt de klant er achter dat dat zij een hoop tijd (=geld) hebben verbrand omdat jij loze beweringen doet, dan is het niet denkbeeldig dat je binnen no-time buiten ligt met een voetafdruk in je derrière. En dan ben je niet alleen die klant kwijt maar heb je ook nog eens een forse reputatieschade, iets wat indien je in een klein wereldje (niche) opereert verstrekkende gevolgen voor jouw bedrijf kan hebben.

Compile time garanties zijn niet mogelijk op Linux voor dingen die afhangen van een "omgeving", maar als het echt nodig is, kun je in principe best een embedded OS gebruiken dat deze garanties wel kent. En dat is ook wat bepaalde bedrijven doen; geen probleem in theorie. Ik heb dat specifiek nog nooit gedaan, maar ik weet wel hoe het zou moeten.

Afgaande op het verhaal van de TS lijkt een embedded OS geen optie, immers als dat wel een optie zou zijn waarom zou de klant dan zich druk maken over welk OS ondersteund wordt? Overigens is een embedded OS wel helemaal aan de andere kant van het spectrum van wat jij eerder voorstelde.

[Anoniem: 28958]

Anoniem: 237999 schreef op maandag 10 mei 2010 @ 23:45:
[Overigens is een embedded OS wel helemaal aan de andere kant van het spectrum van wat jij eerder voorstelde.

Het punt is dan ook dat "garanties" niets anders dan een illusie zijn totdat je het hele traditionele software-ontwikkelingsproces op de schop neemt (wat ik daar eigenlijk zeg).

Ook maar de meest simpele eigenschap van een hello world programma _garanderen_ modulo hardware fouten op Linux is al niet te doen. Ik vraag me sowieso af of er iemand in de wereld is die voor derde partijen software ontwikkeld en per gevonden bug 100miljoen euro betaald. Dat is even kort voor "garanderen". Sowieso is het onrealistisch om software te ontwikkelen zonder te testen, omdat vaak niet eens bekend is wat wel en niet werkt (van dingen als GUIs kun je niet met een stellingenbewijzer bewijzen dat deze "gebruiksvriendelijk" is). Software waarvan er exacte specificaties zijn (die ook nog eens leesbaar zijn!) is zeer zeldzaam.

[ Voor 5% gewijzigd door Anoniem: 28958 op 11-05-2010 12:25 ]

[Anoniem: 28958]

JaQ schreef op maandag 10 mei 2010 @ 19:46:
Volgens mij betaal je helemaal niet om hier te mogen posten

Dat heb ik nooit gezegd.

Op de man spelen (zelfs schofferen) omdat iemand een andere mening heeft dan jij, is naar mijn mening verre van fraai. Nu zal mijn mening je niet veel kunnen schelen, toch wil ik je aanraden om op zijn minst normale omgangsvormen te gebruiken. Dat zorgt er in ieder geval voor dat dit forum op de langere termijn ook een leuke plek blijft om informatie te zoeken.

Ik geef de beste man gratis advies. Vaak worden dit soort mensen gewoon genegeerd. Hij mag blij zijn dat ik het heb gezegd.

Dat denken veel techneuten, maar de mensen die beslissen (ook wel spreadsheetrakkers genoemd) lezen dat soort rapporten wel

Dat die mensen het lezen wil niet zeggen dat ze er ook iets van begrijpen. Ik heb er zelf een aantal gelezen, en ik vond het maar drie keer niks. Rapporten geschreven door bijv. de Amerikaanse strijdkrachten (bijv. gelekt door wikileaks) zijn een stuk professioneler.

[CAPSLOCK2000]

Anoniem: 28958 schreef op dinsdag 11 mei 2010 @ 12:00:
[...]

Het punt is dan ook dat "garanties" niets anders dan een illusie zijn totdat je het hele traditionele software-ontwikkelingsproces op de schop neemt (wat ik daar eigenlijk zeg).

Ook maar de meest simpele eigenschap van een hello world programma _garanderen_ modulo hardware fouten op Linux is al niet te doen. Ik vraag me sowieso af of er iemand in de wereld is die voor derde partijen software ontwikkeld en per gevonden bug 100miljoen euro betaald.

Je moet "garantie" niet te letterlijk nemen. Garantie op je auto betekent ook niet dat dat ding nooit stuk zal gaan. Het betekent dat de fabrikant de problemen die ontstaan zal verhelpen en eventuele schade vergoedt
.
Je gaat er als fabrikant van uit dat slechs een minderheid van je klanten gebruik maakt van de garantie, zo blijft het betaalbaar. Om te voorkomen dat ze failliet gaan als er een keer iets echt grondig mis gaat sluiten ze een verzekering af. Dat kan ieder software bedrijf ook doen.

Het zou mij zelfs heel gezond lijken. Een verzekering wordt namelijk goedkoper als jij bewijst dat je er alles aan doet om te zorgen dat je die verzekering niet nodig hebt. Waar een normale klant bij gebrek aan expertise het werk van een softwarehuis niet kan controleren kan een verzekeraar dat wel.

[Q]

kamiel299 schreef op zaterdag 08 mei 2010 @ 22:13:
Wij zijn bezig een serieus commercieel software systeem on-top-of Linux/Fuse, op te zetten. Closed source Onze doelgroep bestaat uit grote installaties waar men serieus bezig is met Linux als backend (geen gehobby dus maar nagenoeg 'mission critical')

De ontwikkeling zijn we begonnen op Ubuntu 8.10 LTS zonder dat daar erg over nagedacht is. min of meer automatisch is dit dus nu het enige disto die we nu supporten, puur ondat we maar een disto willen/kunnen supporten. Nu merken we dat potentieele afnemens daar toch vaak moeite mee hebben. Ubuntu wordt toch veelal als 'speelgoed' gezien. Ontrecht IMHO, maar het is het marktgevoel.

We gaan dus porten naar een andere distro; vraag is WELKE ?

Is het geen optie om jullie systeem als een 'appliance' aan te leveren? Dan lever je gewoon een black box en wat in die box zit gaat de klant geen moer aan. Het is dan jouw verantwoordelijkheid om het ding up-to-date te houden en te interfacen met de rest van de omgeving. Ik werk ergens waar we dat ook zo doen. We draaien gewoon Debian.

Dan inhoudelijk:

Red Hat is in het perspectief van de klant altijd goed. Of het nu ergens op slaat of niet, dus als dat perspectief erg belangrijk is dan sowieso Red Hat.

Een BSD zou ik persoonlijk nooit doen. Heb je veel te veel werk aan, hardware support is een aandachtspunt, community vind ik te klein.

Ubuntu LTS is bijna nog beter dan Debian stable, omdat debian in de praktijk vereist dat je iedere 3 jaar moet upgraden omdat old-stable dan niet meer wordt gesupport qua security.

Als je bereid bent om door beeldvorming heen te prikken is Ubuntu LTS geen issue. Zorg voor een goed verhaal.

Maar eigenlijk boeit het hele OS niet. Wat boeit is dat jij een product kunt leveren dat aan de wensen van de klant voldoet. En als jij hen weet te overtuigen waarom Windows 3.11 als platform moet dienen, dan is dat prima. Als het maar een bewuste keuze is

[dion_b]

Tja, dat laatste klopt, maar hoe hard je moet werken om iemand te overtuigen dat iets aan alle wensen (incl veiligheid en stabiliteit) voldoet verschilt sterk per OS en per bedrijf. Ik ken geen competente toko waar je anno 2010 met een Win3.11 app aan zou kunnen kopen, hoe mooi je verkooppraat ook is

Fundamentele vraag is idd wie de server die de app draait beheert. Als de klant dat doet, moet de klant dat ook kunnen en willen. Een Redhat-toko wil niet opeens met een Debian bak knutselen, evenmin als dat een Debian-toko een Redhat server wil. Je bent in zo'n geval dus sterk afhankelijk van de nukken van de IT-afdeling van de klant, en je kunt zelfs de situatie krijgen dat een potentiele klant afziet van jullie product omdat het niet "gegarandeerd" draait op hun OS keuze. Dat is IMHO dus de moeilijke weg.

Concreet voorbeeld is het bedrijf waar m'n vriendin ontwikkelaar is. Zij hebben een CMS/DMS product (open-source core met proprietary extensions, grotendeels op basis van PHP) dat dus op servers van de klant draait. Ze werken zelf met RedHat, CentOS en Windows Server 2003, maar ik heb verhalen gehoord van een klant die hun product draaide die ging migreren van een Darwin/PPC omgeving naar een OpenSolaris/SPARC en toen dat mislukte (PHP plugins niet werkend te krijgen) het als noodoplossing op CentOS/AMD64 gegooid werd. Je wil niet weten hoeveel ellende dat allemaal met zich meebracht

Verschil is dat bovenstaande lol niet een mission-critical systeem betrof. Zij konden het verkopen aan $bedrijf met exotische platform met de melding dat ze geen garanties konden bieden, maar in geval van problemen iig (tegen uurtarief uiteraard ) zouden doen wat ze konden. Met mission-critical meuk was dit dus geen sale geweest

Alternatief is zelf beheer van de servers te doen. Dat gaat al snel richting de genoemde "appliance" situatie. Of dat voor jullie klanten acceptabel is, kunnen wij niet zeggen (zonder te weten wat voor klanten het dan exact betreft). Ook voor jullie betekent dat een andere werkwijze dan puur de software verkopen - je moet dan ook zelf de kennis, kunde en vooral de handjes in huis hebben om dat werk te doen. Dat heeft eveneens gevolgen voor het kostenmodel en -plaatje. Hou daar ook rekening mee...

[Q]

Hoe moeilijk en hoeveel werk is het om voor zowel Debian/Ubuntu als voor RedHat te developen? Als je beetje handig script en automatiseerd en een goede deployment / test omgeving hebt, dan zou je het eigenlijk niet meer eens hoeven merken.