mboost-dp1
unknown
Det er spændende at se hvor populært PHP er blevet. Vi har sgu fostret nogle kloge hoveder her i lille DK, bl.a. Bjarne Stoustrup (C++), Anders Hejlsberg (Turbo Pascal / C#) og så Rasmus Lerdorf (PHP)
Man må dog ikke glemme at det var Andi Gutmans and Zeev Suraski fra Zend som har gjort PHP til det, det er i dag.
Det er bare en stor skam, at mange webhoteller endnu ikke har fået opgraderet til version 5.1.
Man må dog ikke glemme at det var Andi Gutmans and Zeev Suraski fra Zend som har gjort PHP til det, det er i dag.
Det er bare en stor skam, at mange webhoteller endnu ikke har fået opgraderet til version 5.1.
...det populære fortolkningssprog PHP...
PHP er et sprog og et API, men om det fortolkes eller kompiles kommer da helt an på deployment miljøet. Udover at PHP rent faktisk bliver kompileret til bytekode (modsat f.eks. JavaScript, Ruby og Pearl), så findes der Turck MMCache til at cache kompileringerne og Roadend til at lave stand-alone apps, for ikke at glemme PHP-GTK. Hvorfor bliver indsendte nyhedstekster så ofte skrevet om med introducerede fejl i? :/
Grænserne mellem fortolket og compilet er blevet noget
udvisket de senere år.
Men hvis man f.eks. definerer at oversættelse fra tekst
til byte code ikke er en en rigtig compilering, men at det
først er ved JIT compilering af byte koden at man dropper
at kalde det fortolket, så er formuleringen vel rigtig nok.
Jeg synes ikke at den er slem set ud fra et korrektheds
synspunkt.
Men det ligner en uheldig oversættelse af fra engelsk
scripting language.
Hvor jeg absolut synes, at man skulle have beholdt det
engelske udtryk.
Fordi man igen kan begynde at diskutere hvorvidt et script
sprog og er fortolket sprog er det samme.
udvisket de senere år.
Men hvis man f.eks. definerer at oversættelse fra tekst
til byte code ikke er en en rigtig compilering, men at det
først er ved JIT compilering af byte koden at man dropper
at kalde det fortolket, så er formuleringen vel rigtig nok.
Jeg synes ikke at den er slem set ud fra et korrektheds
synspunkt.
Men det ligner en uheldig oversættelse af fra engelsk
scripting language.
Hvor jeg absolut synes, at man skulle have beholdt det
engelske udtryk.
Fordi man igen kan begynde at diskutere hvorvidt et script
sprog og er fortolket sprog er det samme.
#7 Du har ret i at det er blevet sværere at skilne. Men hvis man efter sin lexer, parser og AST-optimizer ender med at genere kode (maskinkode eller byte-kode/P-code) så har man vel kompileret? At der så findes et lag der konverterer CISC instruktioner til RISC (P6-arkitekturen), eller byte-kode til maskinkode (Java/CLR JIT) er vel bare et abstraktionslag.
Hvis din definition skal gælde, hvad vil du så kalde "rigtig" fortolket scripting så som JavaScript? Non-native kompileret fortolkning?
Hvis din definition skal gælde, hvad vil du så kalde "rigtig" fortolket scripting så som JavaScript? Non-native kompileret fortolkning?
Jeg er meget konservativ på det område. Kun 2 kategorier:
C++, Delphi, Java med JIT VM, .NET etc. som compileret
PHP, JS, Python, Java med classic VM etc. som fortolket
Nogle af sprogene i fortolket kategorien er iøvrigt meget vanskelige
at compile til native kode.
Umiddelbart er det mit indtryk at PHP i den sammenhæng er i
en mellem kategori - nemmere at compile til native end Python
men sværere at compile end Java.
C++, Delphi, Java med JIT VM, .NET etc. som compileret
PHP, JS, Python, Java med classic VM etc. som fortolket
Nogle af sprogene i fortolket kategorien er iøvrigt meget vanskelige
at compile til native kode.
Umiddelbart er det mit indtryk at PHP i den sammenhæng er i
en mellem kategori - nemmere at compile til native end Python
men sværere at compile end Java.
Og inden nogen tror at jeg er inkarneret anti-script mand må
jeg hellere pointere, at det typisk er de samme egenskaber
ved script sprog som gør dem vanskelige at compile til native
kode der giver høj produktivitet hos udviklerne.
Sådan lidt plat, så kan CPU'er godt lide klassiske compilede
sprog mens den menneskelige hjerne godt kan lide fortolkede script sprog.
jeg hellere pointere, at det typisk er de samme egenskaber
ved script sprog som gør dem vanskelige at compile til native
kode der giver høj produktivitet hos udviklerne.
Sådan lidt plat, så kan CPU'er godt lide klassiske compilede
sprog mens den menneskelige hjerne godt kan lide fortolkede script sprog.
Det eneste der mangler i PHP lige nu (imo), er Threads! Det er godt nok provokerende, at man mangler det, når man skal programmere PHP-GTK. Der er selvfølgelig forking, men det virker jo pt kun på Linux :(
Jeg synes selv, at det er sejt, at man kan efterlade halvdelen af sin kode åbent (f.eks. bestemte klasser eller funktionssæt), mens resten er bytecode-compilet.
Jeg lagde også lige mærke til, at ingen af jer har nævnt "bcompiler", som også er en bytecode-compiler til PHP. Den står endda beskrevet på PHP's egen hjemmeside:
http://dk.php.net/bcompiler
Noget andet der også gøre PHP virkelig unikt, er at folkende har taget Java til sig. Det er derfor muligt at arbejde med alle klasser fra Java - selv dem man selv har skrevet.
http://dk2.php.net/java
Og så ikke at forglemme DotNet og COM (det kan alle sprog til Windows vel?):
http://dk2.php.net/com
http://dk2.php.net/dotnet
Det bliver sku fryd, hvis Mono får DotNet-klassen til at virke identisk på Linux også :)
Glæder mig virkelig til at høre interviewet, når jeg kommer i skole :)
Og lige et spørgsmål mht. Java. arne_v nævner at Java kan compileres ligesom C++. Jeg troede kun, at det var muligt at bytecode-compile Java. Kan andre lige give et link til noget dokumentation om Java-compiling (ikke bytecode).
Godmorgen alle sammen.
Jeg synes selv, at det er sejt, at man kan efterlade halvdelen af sin kode åbent (f.eks. bestemte klasser eller funktionssæt), mens resten er bytecode-compilet.
Jeg lagde også lige mærke til, at ingen af jer har nævnt "bcompiler", som også er en bytecode-compiler til PHP. Den står endda beskrevet på PHP's egen hjemmeside:
http://dk.php.net/bcompiler
Noget andet der også gøre PHP virkelig unikt, er at folkende har taget Java til sig. Det er derfor muligt at arbejde med alle klasser fra Java - selv dem man selv har skrevet.
http://dk2.php.net/java
Og så ikke at forglemme DotNet og COM (det kan alle sprog til Windows vel?):
http://dk2.php.net/com
http://dk2.php.net/dotnet
Det bliver sku fryd, hvis Mono får DotNet-klassen til at virke identisk på Linux også :)
Glæder mig virkelig til at høre interviewet, når jeg kommer i skole :)
Og lige et spørgsmål mht. Java. arne_v nævner at Java kan compileres ligesom C++. Jeg troede kun, at det var muligt at bytecode-compile Java. Kan andre lige give et link til noget dokumentation om Java-compiling (ikke bytecode).
Godmorgen alle sammen.
#12: U r teh n0000b!1!1!oneoneone!11
omgomglololol.
lidt mere seriøst: => http://gcc.gnu.org/java/
faktisk kompilerer den nyeste version af azureus med GCJ, hvilket betyder den ikke behøver ligge og bolle dine ram
omgomglololol.
lidt mere seriøst: => http://gcc.gnu.org/java/
faktisk kompilerer den nyeste version af azureus med GCJ, hvilket betyder den ikke behøver ligge og bolle dine ram
#12
javac compiler Java source til Java byte code.
En classic JVM fortolker bare den byte code.
En JIT JVM compiler den byte code til native code i memory
som eksekveres.
Eller for at være mere præcis - den JIT compiler den kode som
den mener det er umagen værd at JIT compile.
D.v.s. at den reelle optimizing compiler ligger i java ikke i javac.
Og i nyere Java versioner er det faktisk ret effektivt.
javac compiler Java source til Java byte code.
En classic JVM fortolker bare den byte code.
En JIT JVM compiler den byte code til native code i memory
som eksekveres.
Eller for at være mere præcis - den JIT compiler den kode som
den mener det er umagen værd at JIT compile.
D.v.s. at den reelle optimizing compiler ligger i java ikke i javac.
Og i nyere Java versioner er det faktisk ret effektivt.
jow jow, Lerdorf er stadig genial nok.
I skulle næsten læse foredraget fra OSCON, det er ret morsomt, og lærer en en del.
http://talks.php.net/show/oscon06/1
Han arbejder jo for Yahoo! for tiden. Yahoo! er 90% php og 10% C/C++ ifølge Sara Golemon som også arbejder der :)
I skulle næsten læse foredraget fra OSCON, det er ret morsomt, og lærer en en del.
http://talks.php.net/show/oscon06/1
Han arbejder jo for Yahoo! for tiden. Yahoo! er 90% php og 10% C/C++ ifølge Sara Golemon som også arbejder der :)
Quittede vidst lige http://gcc.gnu.org/java/ lidt for hurtigt efter jeg så "bytecode".
Der stod også:
"...or directly to native machine code..."
Der stod også:
"...or directly to native machine code..."
PHP6 info fra Paris mødet (gammelt, men stadigvæk aktulelt)
http://www.php.net/~derick/meeting-notes.html
Kan kort opsummeres "dårlig kode virker nu ikke mere, og php kan ikke sættes op til at køre dårlig kode mere"
Dødstøddet til joomla,phpbb,phpnuke,oscommerce osv. =)
http://www.php.net/~derick/meeting-notes.html
Kan kort opsummeres "dårlig kode virker nu ikke mere, og php kan ikke sættes op til at køre dårlig kode mere"
Dødstøddet til joomla,phpbb,phpnuke,oscommerce osv. =)
#25
Ikke forstået.
Den bemeldte type produkt oversætter fra java byte code til
native exe.
Det er ikke obfuscating i klassisk forstand.
Hvis obfuscating gør det 5 gange så dyrt at reverse engineere
koden, så gør konvertering til native det 50 gange dyrere
ar reverse engineere koden.
I tilfælde hvor koden indeholder kritiske algoritmer eller
lignende ses det derfor at man konverterer til native.
Iøvrigt så kører de fleste Java obfuscatorer på byte code og
ikke på source code.
Formentlig er det nemmere.
Ikke forstået.
Den bemeldte type produkt oversætter fra java byte code til
native exe.
Det er ikke obfuscating i klassisk forstand.
Hvis obfuscating gør det 5 gange så dyrt at reverse engineere
koden, så gør konvertering til native det 50 gange dyrere
ar reverse engineere koden.
I tilfælde hvor koden indeholder kritiske algoritmer eller
lignende ses det derfor at man konverterer til native.
Iøvrigt så kører de fleste Java obfuscatorer på byte code og
ikke på source code.
Formentlig er det nemmere.
Nu var jeg nu mere ude efter, den forkerte brug af ordet beskytte. Ikke min hensigt at starte en diskussion om, hvordan man mest effektivt holder brugerne hjælpeløse, hvilket er den hensigt jeg væmmes over.
Enhver software bruger, skal da have både retten og midlerne til at ændre det han har brug for, i den software han bruger.
Enhver software bruger, skal da have både retten og midlerne til at ændre det han har brug for, i den software han bruger.
sKIDROw: "Enhver software bruger, skal da have både retten og midlerne til at ændre det han har brug for, i den software han bruger."
Mange der koder PHP kommercielt (for at holde mig til topic), giver netop brugeren den mulighed, i og med at PHP som standard ikke kan laves til bytecode.
Jeg driver et lille webfirma hvor de fleste af vores kunder er nystartede selvstændige, som ikke har råd til at have en dedikeret server stående, eller købe de dyre shared hosting faciliteter. Derfor bruger vi som regel alm. webhoteller. Det fungerer vældig fint, men jeg ved også, at har kunden en smule forstand på at uploade via FTP, tage backup af en database osv. Jamen så kan han/hun nemt skifte leverandør, hvis der skulle være utilfredsheder med vores samarbejde.
Den nye leverandør - vores konkurrent - kan så leve højt på den programmering, vi har lavet. På det tidspunkt har vi fået vores penge og rettighederne er overdraget til kunden. Men lad os sige at vi har lavet en eller anden sindsyg søgealgoritme i Googleklassen. Den ligger nu til direkte aflæsning* i koden og haps, så snupper vores konkurrent lige den. Det kan godt ske, man har loven på sin side, men det kan være hamrende svært, specielt med serverside-kode at finde ud af, om der er blevet "lånt" nogle steder.
Derfor vil man mange gange, f.eks hvis man laver webshop-løsninger, vælge at host'e løsningen selv, fordi koden så er udenfor folks rækkevidde.
*) Dette var et tænkt eksempel. Man vil selvfølgelig vælge at lave alle mulige sikkerhedsforanstaltninger, når man laver større løsninger, der skal leveres direkte til kunden. Man kan vælge at obfuscate, men det besværliggør kun reverse engineering, det gør det ikke umuligt
Mange der koder PHP kommercielt (for at holde mig til topic), giver netop brugeren den mulighed, i og med at PHP som standard ikke kan laves til bytecode.
Jeg driver et lille webfirma hvor de fleste af vores kunder er nystartede selvstændige, som ikke har råd til at have en dedikeret server stående, eller købe de dyre shared hosting faciliteter. Derfor bruger vi som regel alm. webhoteller. Det fungerer vældig fint, men jeg ved også, at har kunden en smule forstand på at uploade via FTP, tage backup af en database osv. Jamen så kan han/hun nemt skifte leverandør, hvis der skulle være utilfredsheder med vores samarbejde.
Den nye leverandør - vores konkurrent - kan så leve højt på den programmering, vi har lavet. På det tidspunkt har vi fået vores penge og rettighederne er overdraget til kunden. Men lad os sige at vi har lavet en eller anden sindsyg søgealgoritme i Googleklassen. Den ligger nu til direkte aflæsning* i koden og haps, så snupper vores konkurrent lige den. Det kan godt ske, man har loven på sin side, men det kan være hamrende svært, specielt med serverside-kode at finde ud af, om der er blevet "lånt" nogle steder.
Derfor vil man mange gange, f.eks hvis man laver webshop-løsninger, vælge at host'e løsningen selv, fordi koden så er udenfor folks rækkevidde.
*) Dette var et tænkt eksempel. Man vil selvfølgelig vælge at lave alle mulige sikkerhedsforanstaltninger, når man laver større løsninger, der skal leveres direkte til kunden. Man kan vælge at obfuscate, men det besværliggør kun reverse engineering, det gør det ikke umuligt
#28 Simm
Nu vil jeg ikke gøre mig til talsmand, for afskaffelsen af kompiere... ;) Kompiling af ting kan være nyttigt og eller nødvendigt. Selvom du for performance, kompilere scripts til bytekode eller native. Så ændre det intet, i at brugere stadig kan få brug for koden, og derfor bør kunne få den.
At folk let og smertefrit kan skifte leverandør, er da kun ret og rimeligt. Det kan lige så godt være dig, til gavn som til skade. Jo nemmere folk kan skifte, jo mere incitament har leverandører i at sørge for at folk gerne vil blive.
Okay nu forstår jeg ikke problemmet. I har modtaget betalingen, og rettighederne er overdraget. Hvori består problemmet?.
Men hvis eksemplet er lig det tidligere, så er i blevet betalt og rettighederne overdraget?. Og hvis det var så fantastisk, så har regningen vel afspejlet dette?. Så stadig mangler jeg, at se hvor problemmet er?.
Jeg syntes også du ser problemmer, hvor der ikke er nogen. Hvis du bliver betalt, og kan leve af det. Så syntes jeg vi begge, kan sove roligt om natten... ;)
Igen udfra bruger synspunktet, er det stadig grundlæggende forkert. Og det synpunkt, bliver ikke mindre relevant, på grund af de andres teoretiske ulemper.
Jeg syntes nu det er trist, at se den slags behandling af kunder , betragtet som en selvfølge.
Det er da for så vidt også skidt nok.
Mange der koder PHP kommercielt (for at holde mig til topic), giver netop brugeren den mulighed, i og med at PHP som standard ikke kan laves til bytecode.
Nu vil jeg ikke gøre mig til talsmand, for afskaffelsen af kompiere... ;) Kompiling af ting kan være nyttigt og eller nødvendigt. Selvom du for performance, kompilere scripts til bytekode eller native. Så ændre det intet, i at brugere stadig kan få brug for koden, og derfor bør kunne få den.
Jeg driver et lille webfirma hvor de fleste af vores kunder er nystartede selvstændige, som ikke har råd til at have en dedikeret server stående, eller købe de dyre shared hosting faciliteter. Derfor bruger vi som regel alm. webhoteller. Det fungerer vældig fint, men jeg ved også, at har kunden en smule forstand på at uploade via FTP, tage backup af en database osv. Jamen så kan han/hun nemt skifte leverandør, hvis der skulle være utilfredsheder med vores samarbejde.
At folk let og smertefrit kan skifte leverandør, er da kun ret og rimeligt. Det kan lige så godt være dig, til gavn som til skade. Jo nemmere folk kan skifte, jo mere incitament har leverandører i at sørge for at folk gerne vil blive.
Den nye leverandør - vores konkurrent - kan så leve højt på den programmering, vi har lavet. På det tidspunkt har vi fået vores penge og rettighederne er overdraget til kunden.
Okay nu forstår jeg ikke problemmet. I har modtaget betalingen, og rettighederne er overdraget. Hvori består problemmet?.
Men lad os sige at vi har lavet en eller anden sindsyg søgealgoritme i Googleklassen. Den ligger nu til direkte aflæsning* i koden og haps, så snupper vores konkurrent lige den.
Men hvis eksemplet er lig det tidligere, så er i blevet betalt og rettighederne overdraget?. Og hvis det var så fantastisk, så har regningen vel afspejlet dette?. Så stadig mangler jeg, at se hvor problemmet er?.
Det kan godt ske, man har loven på sin side, men det kan være hamrende svært, specielt med serverside-kode at finde ud af, om der er blevet "lånt" nogle steder.
Jeg syntes også du ser problemmer, hvor der ikke er nogen. Hvis du bliver betalt, og kan leve af det. Så syntes jeg vi begge, kan sove roligt om natten... ;)
Derfor vil man mange gange, f.eks hvis man laver webshop-løsninger, vælge at host'e løsningen selv, fordi koden så er udenfor folks rækkevidde.
Igen udfra bruger synspunktet, er det stadig grundlæggende forkert. Og det synpunkt, bliver ikke mindre relevant, på grund af de andres teoretiske ulemper.
*) Dette var et tænkt eksempel. Man vil selvfølgelig vælge at lave alle mulige sikkerhedsforanstaltninger, når man laver større løsninger, der skal leveres direkte til kunden.
Jeg syntes nu det er trist, at se den slags behandling af kunder , betragtet som en selvfølge.
Man kan vælge at obfuscate, men det besværliggør kun reverse engineering, det gør det ikke umuligt.
Det er da for så vidt også skidt nok.
#29:
Hehe, jeg kan ikke helt leve af det jeg laver endnu, men jeg håber det kommer med tiden.
Jeg forstår udemærket din argumentation, hvis jeg ser det fra et brugerperspektiv. Men tager jeg erhvervskasketten på, så er sagen noget anderledes. Det handler om at yde god service til ens kunder, det kan der aldrig blive tvivl om. Men ved at gøre din kode tilgængelig for en konkurrent, så medvirker du måske til, i yderste konsekvens at konkurrenten udraderer dig i sidste ende.
Jo selvfølgelig afspejler regningen altid det, udviklingen af et produkt nu koster. Men som programmør udvikler du også internt i dit firma kode, som kan effektivisere dit arbejde, og optimere dine produkter. Det er kode, som du egentlig ikke tjener penge på, men som kunderne alligevel får glæde af. Igen, hvorfor skal en konkurrent, på ingen tid kunne snuppe det du har brugt måneder og dage på at lave?
Når det så er sagt, så er der intet til hindring for at lukke nogle dele, og holde andre dele af et produkt åbent, men er det tilfredsstillende nok?
Hehe, jeg kan ikke helt leve af det jeg laver endnu, men jeg håber det kommer med tiden.
Jeg forstår udemærket din argumentation, hvis jeg ser det fra et brugerperspektiv. Men tager jeg erhvervskasketten på, så er sagen noget anderledes. Det handler om at yde god service til ens kunder, det kan der aldrig blive tvivl om. Men ved at gøre din kode tilgængelig for en konkurrent, så medvirker du måske til, i yderste konsekvens at konkurrenten udraderer dig i sidste ende.
Jo selvfølgelig afspejler regningen altid det, udviklingen af et produkt nu koster. Men som programmør udvikler du også internt i dit firma kode, som kan effektivisere dit arbejde, og optimere dine produkter. Det er kode, som du egentlig ikke tjener penge på, men som kunderne alligevel får glæde af. Igen, hvorfor skal en konkurrent, på ingen tid kunne snuppe det du har brugt måneder og dage på at lave?
Når det så er sagt, så er der intet til hindring for at lukke nogle dele, og holde andre dele af et produkt åbent, men er det tilfredsstillende nok?
#30 Simm
Alle nystartede firmaer kræver en del tid og kræfter, at få løbet i gang. Det er meget normalt...
Det burde det ikke være. Du behøver ikke blive selvisk, og komplet ligeglad med brugernes interesser, blive fordi du skal tænke på forretningen.
Det var da en overdrivelse som vil frem... ;P
Jeg må indrømmet at jeg ser meget lidt basis, for den påstand.
Enten har kunden betalt for udviklingen, eller også har de ikke. Det er eonget uldent noget, du har gang i der. Hvis kunderne ikke betaler for det som bliver udviklet, så syntes jeg du skal revurdere din udregning af priser. Men hvis de i sandelighed, betaler for det arbejde i har udført for ham, så kan jeg altså ikke forstå al den klagesang.
Det er jo op til kunden, som købte og betalte for det pågældende arbejde. Når regningen er betalt, rager det da ikke længere dig, hvad de gør med det pågældende. Hvis jeg beder en entreprenør bygge mig en carport, så er den min når regningen er betalt. Og så var jeg sandelig blevet tosset, hvis han ville bestemme hvordan jeg brugte den.
Det spørgsmål kan besvares ret enkelt, afhængigt af situationen. I hvilket omfang påvirker de pågældende ting, kundens dagligdag og forretning. Hvis det gør, så skal det naturligvis være åbent. Hvis det omvendt er intern infrastruktur, som kunden aldrig direkte mærker for bedre eller værre. Så kan du jo for så vidt, sagtens holde det for jer selv. Har dog også her, svært ved at se jeres fordel i det. Mange har særligt her, haft fordel af at udvikle den slags i samarbejde med lignende parter verden over.
#31
Der er mere i det end det.
At kunderne er tilfredse med hvad de bliver budt, giver jeg ikke nødvendigvis ret meget for. De har jo aldrig, været særligt godt vante. Det er det som der skal gøres op med. Folk tro på at sådan skal det nok bare være, så det kan vi jo ikke ændre alligevel. Naturligvis kan vi det. Vi kan, skal og har så småt allerede gjort det.
#32
Fri software udviklere er sjældent så ivrige efter, absolut at give den slags datoer. Når tingene er klar så er de klar... ;)
At tvinge folk til at give en dato, kommer der aldrig noget godt ud af... *HOST* Vista *HOST*
Hehe, jeg kan ikke helt leve af det jeg laver endnu, men jeg håber det kommer med tiden.
Alle nystartede firmaer kræver en del tid og kræfter, at få løbet i gang. Det er meget normalt...
Jeg forstår udemærket din argumentation, hvis jeg ser det fra et brugerperspektiv. Men tager jeg erhvervskasketten på, så er sagen noget anderledes.
Det burde det ikke være. Du behøver ikke blive selvisk, og komplet ligeglad med brugernes interesser, blive fordi du skal tænke på forretningen.
Det handler om at yde god service til ens kunder, det kan der aldrig blive tvivl om. Men ved at gøre din kode tilgængelig for en konkurrent, så medvirker du måske til, i yderste konsekvens at konkurrenten udraderer dig i sidste ende.
Det var da en overdrivelse som vil frem... ;P
Jeg må indrømmet at jeg ser meget lidt basis, for den påstand.
Jo selvfølgelig afspejler regningen altid det, udviklingen af et produkt nu koster. Men som programmør udvikler du også internt i dit firma kode, som kan effektivisere dit arbejde, og optimere dine produkter. Det er kode, som du egentlig ikke tjener penge på, men som kunderne alligevel får glæde af.
Enten har kunden betalt for udviklingen, eller også har de ikke. Det er eonget uldent noget, du har gang i der. Hvis kunderne ikke betaler for det som bliver udviklet, så syntes jeg du skal revurdere din udregning af priser. Men hvis de i sandelighed, betaler for det arbejde i har udført for ham, så kan jeg altså ikke forstå al den klagesang.
Igen, hvorfor skal en konkurrent, på ingen tid kunne snuppe det du har brugt måneder og dage på at lave?
Det er jo op til kunden, som købte og betalte for det pågældende arbejde. Når regningen er betalt, rager det da ikke længere dig, hvad de gør med det pågældende. Hvis jeg beder en entreprenør bygge mig en carport, så er den min når regningen er betalt. Og så var jeg sandelig blevet tosset, hvis han ville bestemme hvordan jeg brugte den.
Når det så er sagt, så er der intet til hindring for at lukke nogle dele, og holde andre dele af et produkt åbent, men er det tilfredsstillende nok?
Det spørgsmål kan besvares ret enkelt, afhængigt af situationen. I hvilket omfang påvirker de pågældende ting, kundens dagligdag og forretning. Hvis det gør, så skal det naturligvis være åbent. Hvis det omvendt er intern infrastruktur, som kunden aldrig direkte mærker for bedre eller værre. Så kan du jo for så vidt, sagtens holde det for jer selv. Har dog også her, svært ved at se jeres fordel i det. Mange har særligt her, haft fordel af at udvikle den slags i samarbejde med lignende parter verden over.
#31
For kunden? Sikkert. For sKIDROw? Nej.
Der er mere i det end det.
At kunderne er tilfredse med hvad de bliver budt, giver jeg ikke nødvendigvis ret meget for. De har jo aldrig, været særligt godt vante. Det er det som der skal gøres op med. Folk tro på at sådan skal det nok bare være, så det kan vi jo ikke ændre alligevel. Naturligvis kan vi det. Vi kan, skal og har så småt allerede gjort det.
#32
Fri software udviklere er sjældent så ivrige efter, absolut at give den slags datoer. Når tingene er klar så er de klar... ;)
At tvinge folk til at give en dato, kommer der aldrig noget godt ud af... *HOST* Vista *HOST*
#alle
De fleste som koder php rigtig commencielt, arbejder jo for et firma direkte, der er utrolig få som leverer kode til en bruger, hvor det så ville være optimalt at compile for at skjule source.
Hvis i kigger på f.eks. et dansk firma www.golden-planet.dk så sælger de en modificeret oscommerce, så er en værre omgang skrammel kode, af et open source project (som altid har været elendigt).
Der er slet ikke værd at skjule den kode.. den er simplenhen for elendig til nogen gider kopierer den.
De fleste som koder php rigtig commencielt, arbejder jo for et firma direkte, der er utrolig få som leverer kode til en bruger, hvor det så ville være optimalt at compile for at skjule source.
Hvis i kigger på f.eks. et dansk firma www.golden-planet.dk så sælger de en modificeret oscommerce, så er en værre omgang skrammel kode, af et open source project (som altid har været elendigt).
Der er slet ikke værd at skjule den kode.. den er simplenhen for elendig til nogen gider kopierer den.
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Nyheder
Gå til bund