|
|
Voordelen ARM omschrijven
| Naam |
Bericht |
bolbuyk
|
In het kader van een afstudeeronderzoek wil ik graag mijn keuze voor een ARM verdedigen, maar ik krijg niet echt overzichtelijke informatie wat daar nu de technische voordelen van izjn. Wel is me duidelijk dat het in vrijwel alle embedded systemen wordt toegepast en is me de werking ook redelijk duidelijk.
Een van de argumenten is natuurlijk omdat het zoveel gebruikt wordt de vervangbaarheid gegarandeerd is en er veel software op de markt is om zo'n ding te programmeren.
Maar ik ben eigenlijk nog op zoek naar een echt technisch argument voor een ARM.
Of bestaat die eigenlijk niet en is het simpelweg een gangbaar type?
|
RedTiger
|
Als je het technisch bekijkt is 1 voordeel dat ie 32 bits is.
|
Arco
|
Welke processor voor welk doel kan worden gebruikt kan eigenlijk alleen zinvol worden beantwoord als je weet wat 'ie precies moet gaan doen. Meestal is het een afweging tussen mogelijkheden, snelheid, kosten, en beschikbare hulpmiddelen zoals compilers, demoboards, enz...
Arco
|
Roland van Leusden
|
quote: Wel is me duidelijk dat het in vrijwel alle embedded systemen wordt toegepast en is me de werking ook redelijk duidelijk.
Denk 't niet, de 8051 kom je veel meer tegen, als je het over embedded systemen met een OS hebt, heb je waarschijnlijk wel gelijk.
Echte hobbyisten gebruiken ARM of FPGA ook voor een knipperledje ...
|
jan lietaer
|
Misschien aanhalen dat ARM een soort "standaard" is, in de zin dat hij heel veel gebruikt wordt?
jan
|
bolbuyk
|
kHeb nu in ieder geval als argument genoemd dat de RISC-architectuur minder geheugenruimte nodig heeft voor het opslaan van de instructieset tov de CISC-architectuur. Binnen RISC is ARM volgens mij de meest voorkomende standaard.
|
Roland van Leusden
|
Echte hobbyisten gebruiken ARM of FPGA ook voor een knipperledje ...
|
bprosman
|
quote: wil ik graag mijn keuze voor een ARM verdedigen
Als je zegt dat je je keuze wil verdedigen betekend dat niet dat je op basis van (toetsbare) criteria tot deze keuze gekomen bent ?. Welke criteria waren dit ?. En om nog maar een knuppel in t hoenderhok te gooien, ZIJN ze wel verdedigbaar  .
quote: Een van de argumenten is natuurlijk omdat het zoveel gebruikt wordt de vervangbaarheid gegarandeerd is en er veel software op de markt is om zo'n ding te programmeren.
Dit kan ik ook ophangen voor de 8051, de AVR, en de PIC.
Bekijk inderdaad deze thread eens :
http://www.circuitsonline.net/forum/view/48371
En dan met name het commentaar van Free_Electron.
Groeten, Bram [Bericht gewijzigd door bprosman op 24 juni 2008 17:17:15]
De jongere generatie loopt veel te vaak zijn PIC achterna.
|
Wouter van Ooijen
|
quote:
Als eens echt wil lachen om een bulk onzin moet je dat inderdaad lezen.
bprosman: waarom heb je eigenlijk voor een ARM gekozen? wee niet te beschaamd om gewoon je reden te geven, iets als "we hadden het liggen" of "ik kende de tools al" kunnen prima argumenten zijn.
Wouter van Ooijen: VOTI webwinkel, docent HvU (informatica/electrotechniek)
|
bolbuyk
|
quote: Als je zegt dat je je keuze wil verdedigen betekend dat niet dat je op basis van (toetsbare) criteria tot deze keuze gekomen bent ?.
Tja, dat is op zich wel waar, maar in de praktijk lopen die processen soms een beetje impliciet. Je ziet dat iets gangbaar is, je bekijkt wat referentieschema's, een collega geeft je een advies en voor je het weet....
Maar de vergelijking met bijvoorbeeld de PIC gaat een beetje mank, omdat er toch een vrij zware toepassing nodig is, met onder andere een aantal internettoepassingen (LON over IP bijvoorbeeld). Redelijk zware tools ontkomen we toch niet aan, dus argumenten van de kostprijs van die tools, JTAG ed spelen geen rol.
Wat voor mij nog een beetje onduidelijk blijft waarin nu het voordeel zit van RISC boven CISC. Het nadeel van een beperkte instructieset voor RISC is wel helder, maar uiteindelijk werk je er naar toe zo snel mogelijk uit je machinetaal-niveau te klimmen, waarbij je verder programmeert op basis van je libraries. Die beperkte instructieset heeft juist weer als voordeel dat je ze uit kan printen en voor je neus kan ophangen, zonder dat je meteen een hele muur behangen hebt . Maar hoe dat nu precies zit met snelheid, geheugenruimte, foutgevoeligheid, energieverbruik, enz. ik krijg dat niet echt helder.
Verder krijg ik tijdens mijn zoektocht de indruk dat in de meeste gevallen geldt RISC = Harvard en CISC = von Neumann.
In de argumenten zal het inderdaad met name neerkomen op de gangbaarheid, levering in de toekomst, ed.. Maar een technisch argument is toch altijd wel fraai. Iets is toch niet zonder reden gangbaar geworden, denk ik dan.
|
flipflop
|
quote:
Nou, een ARM tegen dit rijtje is wel heel makkelijk te beargumenteren. Je noemt wel een heel andere klasse CPU's hier.
- ARM "matched" beter op hogere programmeertalen (bv C)
- Is vele malen sneller, met name door z'n 32 bit architectuur
- Professionele tools
- Debuggers
- JTAG
[edit] oh sht, ik zie dat bb al een aantal argumenten noemde. Nou ja, bevestigd dan. [Bericht gewijzigd door flipflop op 24 juni 2008 20:36:38]
if (rst='1') then d <= '1' elsif (clk'event and clk='1') then d <= data end if;
|
Wouter van Ooijen
|
quote: Op 24 juni 2008 19:04:48 schreef bolbuyk:
Tja, dat is op zich wel waar, maar in de praktijk lopen die processen soms een beetje impliciet. Je ziet dat iets gangbaar is, je bekijkt wat referentieschema's, een collega geeft je een advies en voor je het weet....
Als dat je manier van beslissen is geweest moet je dat ook opschrijven.
quote:
Het zou je verbazen door wat voor soort oorzaken iets populair kan worden.
Voor de ARM is een van de oorzaken dat het op het moment dat batterij-apparaten (PDA's en vooral GSMetjes) opkwamen een beschikbare energie-zuininge architectuur was.
PIC was een van de eerste hoobyist-vriendelijke flash uController, en de fabrikant heeft een goede reputatie wat betreft leverbaarheid. (De CPU architectuur is echter prut (12 en 14 bit cores))
AVR heeft (in vergelijking met PIC) een veel mooiere architectuur, en er is een gratis GCC compiler. (Maar de fabrikant heeft een slechtere naam qua leverbaarheid)
8051 is beschikbaar van ontzettend veel fabrikanten, er is dus vrijwel altijd een chip beschikbaar met de juiste mix aan peripherals, snelheid, etc. (Maar de CPU architectuur is bagger.)
De Pentium chip die je overal tegenkomt is de lang uitgerekte uitontwikkeling van een slechte architectuur (8008, 8080/8085, 8088/8086, 286 (echt bagger), 386 (redelijk)). Maar er zit zovel engineering in dat die chip beter presteerd dan vrijwel alle alternatieven.
of iets populair wordt hangt vnl van toeval af, en als het eenmaal populair is dan is dat vaak voldoende reden om populair te blijven.
Wouter van Ooijen: VOTI webwinkel, docent HvU (informatica/electrotechniek)
|
free_electron
|
quote: Op 24 juni 2008 16:54:22 schreef bolbuyk:
kHeb nu in ieder geval als argument genoemd dat de RISC-architectuur minder geheugenruimte nodig heeft voor het opslaan van de instructieset tov de CISC-architectuur. Binnen RISC is ARM volgens mij de meest voorkomende standaard.
Puur in volume gezien zou dat wel eens de MIPs architectuur kunnen zijn.
en dat van die geheugenruimte klopt ook niet. je hebt vaak meer instructies nodig om iets simpel te doen wat op een cisc met 1 instructie kan.
enne @ 'meneer van Ooien' : geef dan eens aan wat er zo mis is met dat verhaal van mij in dat andere topic ?
Ik ben niet rap in mijn gat gebeten maar deze keer nu toch wel.
Ik blijf bij mijn statements uit dat topic.
een ARM is goed als
- je horsepower en lage powerconsumptie nodig hebt
- deftige devtools hebt. (en kom niet af met open sores / broken source braakballen zoals gcc (alleen al de legal rotzooi als je iets maakt wat toevallig een of andere gpl of lgpl lib gebruikt ..) of zelf in elkaar te frutselen toolchains .. Ik ben nu vrij tevreden over de IAR toolcain. De code die eruit komt is vrij compact en clean. ik moet slechts zelden hand-optimisen)
Arm is trouwens nooit ontwikkeld als embedded processor maar eerder als SOC core of application processor. voor echt embedded werkt is hij op verschillnede punten een ramp (interrupt afhandeling en latency , maar 2 prioriies voor interrupt handeling , en je moet telkens geweldig veel cycles verspillen aan context swap (arm7 en 9 , cortex is stukken beter).
Als je veel toeters en bellen nodig hebt ( grafisch display met een GUI , networking , usb , storage : go for een ARM. Er zijn Os-sen te kust en te keur.
Als het om echt controlewerk gaat (snel reageren en snel i/o sturen) vergeet arm , behalve als je hem gebruikt in combinatie met veel andere hardware om hem te ondersteunen (zoals in een ASIC of in combinatie met een FPGA als custom coprocessor)
Der zijn ook veel te weining turn-key arm chips verkrijgbaar. Philips heeft er een paar , ST ook , Atmel ook een of 2 , Atmel ook een paar geloof ik , en luminary micro en dat is het dan wel weer... [Bericht gewijzigd door free_electron op 25 juni 2008 06:24:23]
Professioneel ElectronenTemmer - 8 April 08 : 7.355.303
|
KaRaMBa
|
quote: Wat voor mij nog een beetje onduidelijk blijft waarin nu het voordeel zit van RISC boven CISC. Het nadeel van een beperkte instructieset voor RISC is wel helder, maar uiteindelijk werk je er naar toe zo snel mogelijk uit je machinetaal-niveau te klimmen, waarbij je verder programmeert op basis van je libraries. Die beperkte instructieset heeft juist weer als voordeel dat je ze uit kan printen en voor je neus kan ophangen, zonder dat je meteen een hele muur behangen hebt . Maar hoe dat nu precies zit met snelheid, geheugenruimte, foutgevoeligheid, energieverbruik, enz. ik krijg dat niet echt helder.
Verder krijg ik tijdens mijn zoektocht de indruk dat in de meeste gevallen geldt RISC = Harvard en CISC = von Neumann.
Het idee van RISC (Reduced Instruction Set Computer) is dat de instructieset bestaat uit een zeer beperkte set basisinstructies. Je zal eigenlijk voor alles wat je wil doen meerdere instructies moeten gebruiken. Het voordeel van de kleine simpele instructieset is echter dat de processor heel klein (= energie zuinig) kan zijn, en dat de instructies zelf relatief snel kunnen worden geprocessed.
Bij een CISC processor (Complex Instruction Set Computer) bestaat de instructieset juist een een enorme lijst met complexe instructies. Voor bijna alles wat je wil doen is er wel een instructie (denk aan x86; honderden instructies voor de meest wazige berekeningen). De processor is echter wel vrij groot (duur & niet zo energiezuinig), maar het schrijven van programma's is een stuk makkelijker.
In principe is "RISC = Harvard en CISC = von Neumann" niet persee waar (al zou het in prectijk wel zo kunnen zijn). Bij mijn weten is het grote verschil tussen Harvard en von Neumann, dat bij een Harvard architectuur er losse geheugens zijn voor data en voor code (eigenlijk alle DSP's zijn Harvard). Bij een von Neumann architectuur is er slechts 1 geheugen.
Trouwens, een echt zuivere schijding is er niet echt meer tussen RISC en CISC: de meeste RISC processoren hebben wel iets meer instructies dan strict noodzakelijk, en moderne CISC processoren hebben intern ook een RISC-achtige architectuur (denk aan de pentium, die vertaalt intern de CISC instructies naar een RISC microcode).
Volgens mij zijn de meeste embedded processoren (voornamelijk) RISC, omdat ze (in het algemeen) goedkoper en zuiniger zijn.
(PS. Dit is wat ik nog paraat had; het kan wel eens niet 100% correct zijn  )
|
free_electron
|
in praktijk er zijn weinig von neuman machines ...
alles van intel is (modified) harvard (ja ook de x86 !)
alle dsp zijn harvard (eigenlijk meestal princeton architectures)
bij harvard is er code en data memory.
bij modified harvard is er ene extra pad wat toestaat data op te halen uit code ( code kan niet opgehaald worden uit data )
De pc is een gemodificeerde 'modifed harvard' . Door toevoeging van extra hardware is dat pad er wel. zo kan je dynamisch programa's laden.
In een echte harvard draait code uit ene volledig apart geheugen (eigenlijk ROM) een harvard machiene heeft geen instructies om te schrijven naar code memory.
Een harvard heeft dan meestal nog een apart memory voor ineterne registers en controle , en een dedicated i/o bereik ( met aparte instructies. ook de x86 heeft dat. er is een aparte iord en iowr die niks vandoen heeft met normaal geheugen)
Bij ene von neumann is alles uniform. een von neumann kan zijn eigen programma overschrijven met data of omgekeerd.
Voordelen van harvard
- gesplit memory : gene corruptie of cross pollination tussne data en code mogelijk (een weglopende stack of programma kan geen schade aan software toebrengen.)
- dubbel data pad : sneller
Nadelen harvard
- meer 'bedrading'
- gene mogelijkheid om software dynamisch te laden.
Voordelen von neumann
- uniform data. eenvoudiger interfacing met memory en minder instructies voor memory toegang ( harvard heeft aparte instructies afhankelijk van welk memory )
- nadelen : von nuemann heeft meer cycles nodig. een om instructie op te halen , een om data op te halen. een harvard doet dat simultaan
ik geloof dat alleen motorola en sommige ti echte von neumanns zijn.
princeton is eigenlijk ook harvard , maar bij princeton zit stack en io in het datapad.
code:
elke cpu heeft accumulator , b register en controle bits
harvard kan extra registerbanken hebben, om snel context swap te doen
princeton harvard
_____ _____
| cpu | | cpu |_(register bank)
|_____| |_____|
| | | | |
code data code | data
+ I/O
I/O
mod.harvard
______
| cpu |--+-- code
| | |
| | \|/
| | |
| |--+-- data
| |
| |-- i/o
|_______|
von neumann
___
|cpu|--memory
|___|
ARM is noch mossel noch vis. men gebruikt de eerst aantal bits van een datawoord om de instructie te stockeren. dus dat kan je zien als dedicated code memory. als de resterende bits niet genoeg zijn om de data op te slan gebruikt men een extra woord. Het voordeel is dat op dat ogenblik de instructie wel al gedecodeerd is
je hebt dus harvard mechanismes ( code en data simultaan ophalen ) , maar het komt uit een von neumann memory pool. |
flipflop
|
quote:
Ten dele waar. Bij CISC zijn de instructies vaak langer, meer dan 1 byte. Immers, je kunt "maar" 256 opcodes kwijt in 1 byte. Da's veel te weinig als je nog verschillende addresseermethodes hebt voor alle memory related instructies. RISC is m.i. vooral handig als het om kleine, dicht-bij-de-hardware uC's hebt (zoals PIC).
if (rst='1') then d <= '1' elsif (clk'event and clk='1') then d <= data end if;
|
OGL
|
De beschikbaarheidt van opensource tooling kan best een pro zijn als je low-budget aan de gang wilt en het niet erg vind om wat meer tijd te steken in de configuratie van sommige tools.
De electro en embedded wereld kan wel wat open-source enthousiasme gebruiken want ze liggen op dat gebiedt nog iets achter 
Maar het is gewoon een goed buisiness model dus er zit zeker toekomst in
Er is voor ARM veel opensource tooling beschikbaar, niet alleen voor windows ... [Bericht gewijzigd door OGL op 25 juni 2008 21:30:14]
|
free_electron
|
quote: Op 25 juni 2008 21:29:14 schreef OGL:
De beschikbaarheidt van opensource tooling kan best een pro zijn als je low-budget aan de gang wilt en het niet erg vind om wat meer tijd te steken in de configuratie van sommige tools.
De electro en embedded wereld kan wel wat open-source enthousiasme gebruiken want ze liggen op dat gebiedt nog iets achter
de pro wereld was vrij enthousiast wat open sores betreft maar komt veelal van een kale reis terug ....
- geen of slechte support: .. je moet je vraag op het web gooien en hoopen dat iemand erachter gaat om het probleem op te lossen. aangezien er geen geld mee gebonden is ( ontikkelaars verdienen er niks aan , en de tool wordt ook niet verkocht : slechte tool is gene verkoop speelt gene rol bij open source .. ) het kan soms verschrikkelijk lang duren tegen dat je een oplossing krijgt.
En je moet zoveel prijsgeven dat je eigenlijk productontwerp al gekend is wat anderen in gang kan jagen.
Het product waar aan gewerkt wordt moet de deur uit. Als ik een probleem heb als paying user met een cadence , keil , iar , altium tool bel ik de hotline. ofewel hebben ze al ene workaround , ofwel zetten ze er iemand op en meestal is binnen de 24 uur het probleem gefikst. anders lopen ze het risico dat ik overstap op iemand anders en ze mijn 10K dollar per jaar aan hun neus zien voorbijgaan.. dat geefft iets meer 'armslag' ...
Voro open source stuff is er geen tijdsdruk. het is niet : die bug moet gefikst zijn tegen dan , of die kernel versie moet dan de deur uit. Het wordt gereleased wanneer klaar.. met hardware lukt dat niet. het moet DAN af zijn en DAN in productie gaan. anders haat de klant af en koopt hij iets van de concurrentie. Diegene die eerst op de markt is verkoopt , de anderen mogen kleine graantjes meepikken ...
En ik ben geen tool ontwikkelaar. das niet mijn expertise en ik heb daar ook geen zin in. Aankopen is in the long run veel goedkoper dan zelf het warm water uitvinden.
Daar knelt de schoen. Er stond vorige maand nog een artikel in EDN over het gebruik van linux als embedded os ... 4 jaar terug vond dat een geweldige opgang. nu is het haast verdwenen... iedereen haakt af of heeft afgehaakt. het aantal ports voor verschillende architecturen is geweldig gekrompen. de laatste kernels worden niet meer beschikbaar gemaakt voor cross architectuur.
een ander probleem van de open source wereld is de GPL en LGPL en andere licentie vormen . Die zijn veeeeel te restrictief.
Bij vele bedrijven is het VERBODEN om een blok code in een product te stoppen wat aan GPL of LPGL onderhavig is. gewoonweg omdat het een juridisch wespennest is. je moet het beschibaar stellen aan eendertwie jouw product gebruikt , als je iets wijzigt of toevoegt aan die lib moet je ook dat weer publiek maken. als er revieisei zijn van je libs moet je al die varianten gaan beheren. daar kruipt veel tijd , geld in. Bovendien kan het zo restrictief worden dat je op bepaalde dingen geen patent kan aanvragen , net omdat er teveel open source in zit.. en dan is er sprake van prior art ...
Het wordt dus ook moeilijker om je product en ip te beschermen ( net dat staat al haaks op het idee achter open source ... )
Waar ik werk is het uitdrukkelijk verboden om code te gebruiken die van buitenaf komt en die onderhavig is aan GPL of LGPL. Gewoon omdat ons spul opduikt in zoveel applicaties dat ze geen risico willen op lawsuits vanuit de FSF.
Wij mogen wel zelf code schrijven en die publiek maken onder GPL of LGPL. maar der mag niks van buitenaf komen.
Trouwens heel veel van onze code is alleen verkrijgbaar onder NDA's. Voor sommige blokken is alleen de binary of bitstream verkrijgbaar onder NDA. De source komt nooit het bedrijf uit.
Ook bij onze klanten werkt dat zo. Voor vele projecten zijn er cross-nda's in plaats. Sommige teams komen zelfs niet in elkaar met andere teams. Gewoon omdat we een gelijkaardige chip hebben voor 2 concurrenten. Bepaalde technologie is alleen beschikbaar voor B , en die mag niet in handen van A vallen en omgekeerd.
opensource is een heel idealistisch , haast communistisch en socialistisch denkbeeld ( we werken allemaal 'samen' aan een 'betere' oplossing voor 'iedereen'.
Dat valt eenmaal niet te rijmen met een competitie gedreven embedded/hardware wereld.
Voor software kan je nog geld verdienen aan support. ( bugfixes , trainingen , cursus, das hetgeen red-hat en suse hun boterham mee verdienen )
Voor hardware is dergelijke structuur niet mogelijk.
Support bij hardware is reparatie of vervanging...
Software ontwikkeling is ook vele goedkoper dan hardware ontwikkeling. om software te ontwikkelen heb je ene pc nodig.
om hardware te intwikkelen een serieus machienepark ( meetapparatuur , assemblagelijnen , soldeerbout ) en dat zijn serieuze investeringen die software boeren niet hebben...
dus je kan leven van gratis ontwikkeling en betalende support.
Als hardware developer lukt dat niet. Je kosten zijn veel te hoog. die moet je recupereren : dus beschermen van je ontwerp.
Want als mijn hardware door iedereen gratis kan gebruikt worden .. hoe ga ik dan het zout in mijn pap nog verdienen ...
Professioneel ElectronenTemmer - 8 April 08 : 7.355.303
|
Wouter van Ooijen
|
quote:
Verwar jezelf niet met "de pro wereld". *JIJ* en/of je bedrijf hebben blijkbaar een slechte ervaring met OS spul gehad, sneu voor jullie. Misschien verstandig dat jullie het niet meer gebruiken. Maar ik heb wel eens slechte ervaring met betaalde software gehad. betekent dat dat ik dus nooit meer betaalde software zou moeten gebruiken?
Wouter van Ooijen: VOTI webwinkel, docent HvU (informatica/electrotechniek)
|
djoveld
|
Ik denk dat je de plank volledig mis slaat als je denkt dat de embedded versies van OS operating systemen niet meer gebruikt worden, je komt het in allerlei apparatuur tegen tot in routers en fotolijstjes aan toe. Door de uitgebreidere hardware is het nu ook zeer wel mogelijk om de normale versie van een operating systeem te gebruiken, gebeurt veel in kassa's, muzieksystemen en dergelijke. Voor een embedded systeem hoef je niet aan de grote klok te hangen dat je open source software gebruikt hebt...
Mijn Philips flatscreen heeft ook open source software, ik kan de sources downloaden en er lekker zelf aan gaan programmeren als ik daar zin in heb
Overigens is het zo dat als je open source software gebruikt en je daar wijzigingen op aanbrengt, op de open source software zelf dus, bijvoorbeeld op Linux ofzo je de klanten de sources daarvan moet doorgeven. Je eigen software die je erop laat lopen mag je zo gesloten en geheim houden als je maar wilt en je mag daar ook het geld voor vragen wat je wilt. Wijzig je de open source software niet en houd je eigen software gesloten dan hoef je je klanten niets te geven. Als je een embedded product wilt maken hoef je dus zeker niet de sources daarvan vrij te geven. Behalve misschien als je het niet voor elkaar kunt krijgen en bij anderen te rade moet met je sources. [Bericht gewijzigd door djoveld op 26 juni 2008 08:58:27]
|
bprosman
|
quote: ik kan de sources downloaden en er lekker zelf aan gaan programmeren als ik daar zin in heb
Dan ben ik toch wel heel benieuwd waar...
Groeten, Bram
De jongere generatie loopt veel te vaak zijn PIC achterna.
|
djoveld
|
@bprosman:
quote: Dan ben ik toch wel heel benieuwd waar...
Gewoon bij Philips op de support site, bij de Manuals en de Firmware zoals het hoort
Zit overigens ook een Linux GNU Licence op...
http://www.p4c.philips.com/cgi-bin/dcbint/cpindex.pl?slg=ENG...k_Software [Bericht gewijzigd door djoveld op 26 juni 2008 11:25:48]
|
OGL
|
@free_electron
quote:
opensource is een heel idealistisch , haast communistisch en socialistisch denkbeeld ( we werken allemaal 'samen' aan een 'betere' oplossing voor 'iedereen'.
Dit is, kort door de bocht, een beetje de denkwijze van de ..
quote:
... lawsuits vanuit de FSF.
Opensource als term komt idd van FSF (Richard Stallman en cornuiten), maar is niet uitgevonden door de FSF. Voordat bedrijven als MS bedachten dat ze ook geld konden vragen voor software en software konden zien als 'intellectueel' eigendom - het oude Unix tijdperk, was het heel gebruikelijk om code mee te leveren en software te delen.
(zijdelings: http://www.blinkenlights.com/classiccmp/gateswhine.html)
De filosofie achter de FSF foundation is een fundamenteel andere ('information wants to be free') dan het huidige opensource buisiness model ('collaborative development').
Bijvoorbeeld, ergens zeg je dat je geen tool-ontwikkelaar bent, dus je wilt daar geen tijd/geld in steken. Maar je hebt wel tools nodig dus je zult wel moeten - Of tijd of geld.
Gebruik een levendig opensource project en grote kans dat je daar alsnog wat tijd in moet steken. Maar als je zorgt dat de wijzigingen die je maakt weer terug gestopt worden in het project dan weet je zeker dat het meegenomen en ondersteund wordt door volgende versies. Als je opensource tooling pakket grooter/volwassener en beter bekend wordt zullen meer bedrijven investeren en voordat je 't weet doet het niet meer onder voor commerciele pakketten.
Voor voorbeelden kijk naar Linux (je kunt geen router/externe hd of idd fotolijstje meer kopen ..), Open Office, Firefox, etc...
Voor een bedrijf dat investeerd in Opensource producten is het dus interresant dat andere bedrijven dit ook doen, daarom weet je dat er vaak wel release schema's, bug-tracking en een zekere vorm van support zal zijn.
Draai je de boel op windows dat kun je MS hotline bellen, draai je de boel op Linux, dan mag je kiezen bij wie je support inkoopt...
quote:
een ander probleem van de open source wereld is de GPL en LGPL en andere licentie vormen . Die zijn veeeeel te restrictief.
Dat hangt er allemaal vanaf wat je restrictief noemt, Ik vind een licentie restrictief wanneer ik eerst duizenden euro's moet neerleggen voordat ik ook maar bij de binaries mag komen
Daarnaast raad ik je aan eens zo'n GPL, BSD er bij te pakken, en eens te kijken naar wat andere groote bedrijven gebruiken (de EPL die IBM geloof ik aan eclipse geplakt heeft, het framework waarin bijv. lotus notes nu gebouwd is .. ). Restrictief is niet het juiste woordt [Bericht gewijzigd door OGL op 26 juni 2008 14:24:28]
|
free_electron
|
quote:
Ook de klanten waar ik voor werk ... zelfde verhaal.
We hebben trouwens een product wat linux loopt en in massaproductie is. Daar is serieus werk aan gedaan om er voor te zorgen dat er niks van ons in zit wat onder GPL/LPGL onderhavig is/zou kunnen zijn. Onze eindklant wil vermijden dat er iets zou uitlekken (door middel van verplicht source ter beschikking stellen) van bepaalde technologie .
Er zijn voldoende experimenten gedaan binnen het bedrijf om red-hat te draaien op de desktop.. na een 3 jaar durende poging lopen we allemaal terug op solaris ....
de reden : je moet veel te veel updates doen van de desktops , sommige updates breken functionaliteit, en de Linux port voor de software die wij gebruiken is later beschikbaar dan de sun versie , en of heeft minder mogelijkheden ... en de 'beancounters' kwamen terug met een 40 % hoger kostenplaatje voor red hat op pc tegen solaris op sun ...
@ogl. Als ik een soldeerbout nodig heb koop ik er een , als ik een schroevendraaier nodig heb koop ik er een , als ik een compiler/simulator/cad pakket nodig heb koop ik er een. We gaan toch niet alles zelf gaan maken ?
Als die soldeerbout vele te warm blijkt te staan ga ik bij de fabrikant klagen en die is dan verplicht het probleem op te lossen. Ditto voor software vendors.
Met free software / open source ... probeer dit eens , probeer dat eens .. fix het zelf en post het zodat wij het ook kunnen gebruiken , je hebt de source ...
sorry jongens.... da's mijn vakdomein niet. in een klein bedrijfje waar je manusje van alles bent kan dat. in een bedrijf waar je met 100 of 200 man op een project zit waar 2 of 3 aan gwerkt wordt en wat achteraf 6 jaar productie draait .. no way. time is money. Koop support en tools. (en red-hat is kostelijker dan sun of microsoft support ...). we gaan niet zelf maken wat we kunnen kopen. das verloren tijd ( en geld ).
quote: Draai je de boel op windows dat kun je MS hotline bellen, draai je de boel op Linux, dan mag je kiezen bij wie je support inkoopt...
Das een non-statement : probeer bij red-hat maar eens support te krijgen voor een suse of ibm installatie ... of vice versa... je bent even hard gebonden als bij microsoft of sun of ibm...
Ik ga proberen dat artikel terug te vinden. Het stond ofwel in EDN of in embedded World. Een studie gedaan bij 50 grote hardware bedrijven. Hoeveel linux/open source 2 jaar terug , en hoeveel nu . 60% verminderd ...Ze stappen af. De meest voorkomende reden was slechte support , veel te veel projectvertraging daardoor en op het einde een veel hoger kostenplaatje ondanks het aanlokkelijke 'free' . 'free' betekent niet noodzakelijk 'gratis'.. En net DAAR zit de grote misvatting !
Professioneel ElectronenTemmer - 8 April 08 : 7.355.303
|
alex278
|
Nah, grote softwarebedrijven hebben het zich helemaal zelf onmogelijk gemaakt, doordat de prijzen voor software midden jaren 90 de pan uit stegen (1500 gulden voor 'n single-user versie van wordperfect, of het latere office, die dan ook nog geen problemen had om je scriptie op te vreten als er teveel plaatjes in stonden. En referenties goed bijhouden? Muahahahahaha. Vergelijk dat, in die tijd, maar eens met de gratis verkrijgbare versies van TeX en LaTeX. Maar goed)
Daarnaast, anno nu:het is ontzettend prettig als je van libraries de sourcecode hebt. Met name bij allerlei microsoft-zut loop je d'r keer op keer tegenaan dat je merkt dat 't grafische userinterface een schil om de structuur en datamodellen van het onderliggende programma is, en dat je hier en daar dingen zou willen kunnen scripten of toegang willen krijgen op de onderliggende datastructuren. En dat lukt dus niet, omdat je de sourcecode niet hebt.
Het gevolg: als je meer wilt dan wat de GUI je aanbiedt, dan moet je *helemaal vanaf de grond af aan* iets opnieuw gaan schrijven.
Niet dat OS zo'n verbetering is hoor. Het voordeel van OS is dat je de sourcecode kunt bijwerken, mocht je dat willen. Het nadeel van OS: je moet jezelf verdiepen in andermans bagger. Het genot van het doorploegen van 20+ Mb GTK of KDE sourcecode, waar enthousiast getemplated wordt, al dan niet van een configuratiesysteem wat 'veel beter' is dan 'n simpele makefile...die beker laat ik graag aan me voorbijgaan.
Maar d'r zijn gevallen waarin 't wel degelijk prettig is om de sourcecode wel te hebben, ook omdat de onderliggende code best te doen is. Neem iets als django of dojo bijvoorbeeld... [Bericht gewijzigd door alex278 op 26 juni 2008 21:00:17]
|
|
|
