---

Hej gruppe.

Som nævnt i subj - Findes der noget profiling tool til Linux?

Det jeg er ude efter er et tool, der kan fortælle hvor jeg brænder CPU af.

Situationen er, at jeg tilsyneladende, et eller andet sted, i en eller anden
tråd har fået lavet et infinite loop - en gang imellem.

Indtil videre, er det lidt på prototype stadiet, og jeg ved godt jeg skal
have kigget min kode efter med lup, men hvis man kunne finde et hint, ville
det være nemmere ;)

Konceptet er, at jeg har
En daemon -> Master thread -> Listener thread -> X antal worker threads.
Worker thread's har, ud over sig selv, et (via inifil angivet) antal shared
libraries.

2 gang i de sidste par uger har jeg observeret (via top) at processen bruger
~ 100% cpu - men spørgsmålet er så hvor?

Der er tale om NPTL threads, så der kun den ene pid i top.

Samtidig er (den viste) memory comsumption oppe i omegnen af 95%.

For at gøre det rigtig 'sjovt' bruger jeg også
PRAGMA temp_store = MEMORY;
mod SQLite <http://www.sqlite.org/pragma.html>

Nu er det stadig lidt på R&D stadie, så jeg ved ikke om det er en god idé.

Det jeg er ude efter er basalt set at finde ud af i hvilket library loopet
opstår - eller måske i Kernel pga. for lidt available memory?

Der er tale om en slags webserver, der kører på min linie, så det er noget
der opstår 'af sig selv'.

I princippet kan det være hvad som helst, også DDoS attack (men det er det
er det nu ikke), men jeg har ikke umiddlebart en idé til at genskabe
situationen.


--
Med venlig hilsen
Stig Johansen

---

---

Michael Rasmussen wrote:

> On Sat, 17 May 2008 19:03:59 +0200
> Stig Johansen <wopr.dk@gmaill.com> wrote:
>
>>
>> Som nævnt i subj - Findes der noget profiling tool til Linux?
>>
> valgrind?
> http://valgrind.org/

Valgrind - var der ikke noget med valgrind og OpenSSH?

Nej spøg tilside.

Jeg kiggede efter den, og den er tilsyneladende dependent af bla. perl.
Den maskine jeg kører på er baseret på denne her:
<http://www.minimalinux.org/ttylinux/>

Så der ser ud til at medføre en masse ekstra installationer, som jeg ikke er
interesseret i.

Jeg må også lige huske at nævne, at det ikke er lavet i C(++) med dennes
debug info, men i Borlands Kylix (pascal) med deres (formentlig anderledes)
debug info.


--
Med venlig hilsen
Stig Johansen

---

Stig Johansen skrev den 17-05-2008 20:07:

> Jeg må også lige huske at nævne, at det ikke er lavet i C(++) med dennes
> debug info, men i Borlands Kylix (pascal) med deres (formentlig anderledes)
> debug info.

Så ville det være oplagt at se hvad Borland/Codegear anbefaler som
profiler til Kylix.

--
Thorbjørn Ravn Andersen "... plus... Tubular Bells!"

---

Thorbjørn Ravn Andersen wrote:

> Stig Johansen skrev den 17-05-2008 20:07:
>
>> Jeg må også lige huske at nævne, at det ikke er lavet i C(++) med dennes
>> debug info, men i Borlands Kylix (pascal) med deres (formentlig
>> anderledes) debug info.
>
> Så ville det være oplagt at se hvad Borland/Codegear anbefaler som
> profiler til Kylix.

Det er en lidt kedelig en.
Kylix var et forsøgt på at lave RAD værktøjer til Linux.
Desværre ser det ud til, at alt vedr Linux opfattes som mere eller mindre
gratis, så der var ikke det forventede salg i produktet, og kommer muligvis
aldrig.

Det (Kylix) er ikke udviklet (færdiggjort) siden hmm. vistnok 2002 - 2003.
Det betyder at selve værktøjet (incl debugger) ikke rigtig kan køre på nyere
distributioner(Manglende bagudkompatibilitet).

Jeg benytter derfor Delphi (windows) til udvikling, debugging og kompilering
til en windows service version, og kompilerer efterfølgende koden på Linux
til en daemon.

Så jeg er lidt på herrens mark mht. værktøjer fra
Borland/Codegear/Embarcadero.

Der ser heller ikke ud til, at der er nogle af hajerne ovre i Borland
grupperne der gider Linux, så der er ikke rigtig nogen at spørge der.

Jeg kunne godt bare holde mig til windows, men NPTL gør at performance
sparker r*v i forhold til windows.
Med den gamle threading model, var det nogenlunde fifty-fifty, men
umiddelbart ser det ud til NPTL performer mange gange bedre.


--
Med venlig hilsen
Stig Johansen

---

Stig Johansen skrev den 17-05-2008 21:35:

> Det (Kylix) er ikke udviklet (færdiggjort) siden hmm. vistnok 2002 - 2003.
> Det betyder at selve værktøjet (incl debugger) ikke rigtig kan køre på nyere
> distributioner(Manglende bagudkompatibilitet).

Oh, the joy of closed source.

Jeg vil foreslå dig at udvikle og teste på en understøttet distribution.

--
Thorbjørn Ravn Andersen "... plus... Tubular Bells!"

---

Thorbjørn Ravn Andersen wrote:

> Stig Johansen skrev den 17-05-2008 21:35:
>
>> Det (Kylix) er ikke udviklet (færdiggjort) siden hmm. vistnok 2002 -
>> 2003. Det betyder at selve værktøjet (incl debugger) ikke rigtig kan køre
>> på nyere distributioner(Manglende bagudkompatibilitet).
>
> Oh, the joy of closed source.

He - religious we are?

Det er i virkeligheden Qt(open source) der er synderen.
En opdatering af Kylix vil kræve fornyet, formentlig meget dyr, licens fra
Trolltech.

> Jeg vil foreslå dig at udvikle og teste på en understøttet distribution.

Det gør jeg på en måde også, nemlig Delphi/Windows.
Der kan jeg teste, single steppe, sætte breakpoints, watches, CPU stack,
osv.

Så programmerne _er_ aftestet inden jeg kompilerer dem på Linux, dvs. så
godt jeg nu kan.

Man (mig i hvertfald) kan ikke rigtig debugge eks. 100 samtidige tråde.

Der er heller ikke tale om en åbenlys fejl for serveren kører 24/7 og virker
fint.

Udfordringen er, at jeg har, ud over serveren selv, p.t. 8 plugins, der hver
især indeholder en del funktioner.

Hvis jeg bare kunne finde ud af hvilken af disse libraries, eller
hovedprogramemt selv, der looper, så er jeg tilfreds.

Jeg havde forestillet mig, der var noget tool, der kunne finde ud af hvor
CPU'en ligger og brænder cycles af, og kombinere adresserne med en eller
anden load table i kernel, og derfra navnet på filen.

Men der er noget der tyder på jeg må kigge mine koder igennem.
Så er det da heldigt der kun er 20K+ LOCs.....

--
Med venlig hilsen
Stig Johansen

---

Stig Johansen skrev den 17-05-2008 23:00:

> Jeg havde forestillet mig, der var noget tool, der kunne finde ud af hvor
> CPU'en ligger og brænder cycles af, og kombinere adresserne med en eller
> anden load table i kernel, og derfra navnet på filen.

Det er der da, men spørgsmålet er hvor anvendeligt det er i din situation.

Har du spurgt google om "Linux profiler"?

--
Thorbjørn Ravn Andersen "... plus... Tubular Bells!"

---

Thorbjørn Ravn Andersen wrote:

> Det er der da, men spørgsmålet er hvor anvendeligt det er i din situation.

Ja, umiddelbart linger det kæmpe apparater, der skal installeret, incl. X
m.m.

Jeg har med vilje bygget en lille server af en kasseret PII 200 Mhz, og
96MB, netop for at afprøve grænsetilfælde og grænseværdier.

Valgrind, f.eks. skriver at man skal forvente 20 gange langsommere
performance.
Det kunne tyde på, at processen kontunuerligt kører under CPU debugging
interrupt.

Men netop det, at den bliver langsom modvirker formålet.
Altså lidt med at måleværktøjet i sig selv ødelægger resultatet.

Jeg ved ikke hvordan BorGear gør det i Delphi, men der kan jeg lave en 'run
to cursor' direkte i IDE'et, og når det pågældende statement optræder,
stopper processen med alt tilgængeligt. Inklusive ændringer af variable
m.m.

Forskellen er, at indtil breakpointet, kører processen, selvom det er under
IDE'en, med stort set fuld skrue.

> Har du spurgt google om "Linux profiler"?

~330.000 pages found.

Du skal have in mente, at jeg er Mainframe/COBOL + Windows Server/PC - mand.

Jeg har prøvet at promovere Linux til middleware ting til mine kunder, men
svaret er det samme:
De (it direktører m.v.) _tør_ ikke pga af manglende _garanti_ for support.

Hvad vil jeg så sige med det? Jo, jeg aner simpelthen ikke hvad jeg skal
kigge efter blandt de ~330.000 sider fra Google.

Jeg tror jeg bruger 'fattigmandsdebuggeren' med at lægge strategiske
udskrifter ind i stedet.

En af de ting jeg har liggende er en ren rekompilering af nogle (prototype)
kalenderfunktioner fra sidste årtusinde.

Det jeg ikke lige havde tænkt over er, at søgemaskinerne følger links, så i
og med der på hver side er link til sidste år, og næste år, så Google nu på
vej ud i år 2246 Og Yahoo er nede i 1700 tallet.

Det er næsten dømt til at gå i kage over tid, så det er nok tid til en
ekstra iteration over diverse funktioner, så jeg udskyder 'profiler
projektet' til jeg selv synes jeg baglandet i orden.

--
Med venlig hilsen
Stig Johansen

---

Stig Johansen skrev den 18-05-2008 08:05:
> Thorbjørn Ravn Andersen wrote:
>
>> Det er der da, men spørgsmålet er hvor anvendeligt det er i din situation.
>
> Ja, umiddelbart linger det kæmpe apparater, der skal installeret, incl. X
> m.m.
>
> Jeg har med vilje bygget en lille server af en kasseret PII 200 Mhz, og
> 96MB, netop for at afprøve grænsetilfælde og grænseværdier.
>
> Valgrind, f.eks. skriver at man skal forvente 20 gange langsommere
> performance.
> Det kunne tyde på, at processen kontunuerligt kører under CPU debugging
> interrupt.
>
> Men netop det, at den bliver langsom modvirker formålet.
> Altså lidt med at måleværktøjet i sig selv ødelægger resultatet.
>
> Jeg ved ikke hvordan BorGear gør det i Delphi, men der kan jeg lave en 'run
> to cursor' direkte i IDE'et, og når det pågældende statement optræder,
> stopper processen med alt tilgængeligt. Inklusive ændringer af variable
> m.m.
>
> Forskellen er, at indtil breakpointet, kører processen, selvom det er under
> IDE'en, med stort set fuld skrue.
>
>> Har du spurgt google om "Linux profiler"?
>
> ~330.000 pages found.

Du er blevet foreslået valgrind. Du kan også bare køre under gdb og så
stoppe den når du har situationen, så kan du se hvor den cykler rundt
henne. Du kan få et fint stacktrace.

Eller du kan fremprovokere et coredump og gdb'e det.


> Du skal have in mente, at jeg er Mainframe/COBOL + Windows Server/PC - mand.

Jojo, så du er i ukendt terræn - det er altid sjov.

>
> Jeg har prøvet at promovere Linux til middleware ting til mine kunder, men
> svaret er det samme:
> De (it direktører m.v.) _tør_ ikke pga af manglende _garanti_ for support.

Hvad har det med noget at gøre? Det vigtigste er at skidtet virker, og
der er en vis fornuft i at sige - vi køber det her, og så har det bare
at virke. Eneste grund til at folk er interesserede i Linux er fordi de
har fået bekræftet gennem praktisk brug at det kan løse en given opgave.
Hvis møget gik ned hele tiden så var folk jo ligeglade.

> Hvad vil jeg så sige med det? Jo, jeg aner simpelthen ikke hvad jeg skal
> kigge efter blandt de ~330.000 sider fra Google.

Hurra. Bedre end ingen hits. Jeg roder pt med noget hvor der kommer
5-10 hits i Google, og det er som regel fra andre med samme slags
problemer. IBM's dokumentationsstil kræver tilvænning.




> Det jeg ikke lige havde tænkt over er, at søgemaskinerne følger links, så i

Du skal nok overveje en "robots.txt" i din webserver.

--
Thorbjørn Ravn Andersen "... plus... Tubular Bells!"

---

Thorbjørn Ravn Andersen wrote:

> Stig Johansen skrev den 18-05-2008 08:05:
>> Jeg har prøvet at promovere Linux til middleware ting til mine kunder,
>> men svaret er det samme:
>> De (it direktører m.v.) _tør_ ikke pga af manglende _garanti_ for
>> support.
>
> Hvad har det med noget at gøre? Det vigtigste er at skidtet virker, og
> der er en vis fornuft i at sige - vi køber det her, og så har det bare
> at virke.

Don't shoot the messenger.
Jeg refererer bare hvad jeg får at vide på 'de bonede gulve'.

--
Med venlig hilsen
Stig Johansen

---

Stig Johansen <wopr.dk@gmaill.com> writes:

> Thorbjørn Ravn Andersen wrote:

>> Hvad har det med noget at gøre? Det vigtigste er at skidtet
>> virker, og der er en vis fornuft i at sige - vi køber det her, og
>> så har det bare at virke.

> Don't shoot the messenger. Jeg refererer bare hvad jeg får at vide
> på 'de bonede gulve'.

Oversat til dansk betyder det at sælgerne skyder på alt hvad der
bevæger sig, når de skal finde på en god grund til at de ikke fik
ordren i hus.

Been there, done that, set firmaet gå praktisk taget konkurs på et
uovervejet skift til Windows som serverplatform :(

--
// Wegge
<http://blog.wegge.dk> - Her hænger jeg også ud.
<http://geowiki.wegge.dk/wiki/Forside> - Alt om geocaching.
Bruger du den gratis spamfighther ser jeg kun dine indlæg *EN* gang.

---

Anders Wegge Jakobsen wrote:

> Stig Johansen <wopr.dk@gmaill.com> writes:
>> Don't shoot the messenger. Jeg refererer bare hvad jeg får at vide
>> på 'de bonede gulve'.
>
> Oversat til dansk betyder det at sælgerne skyder på alt hvad der
> bevæger sig, når de skal finde på en god grund til at de ikke fik
> ordren i hus.

Nu gør jeg ikke i, at sælge hverken Windows eller Linux servere, blot noget
jeg har nævnt når vi alligevel snakker systemer og sammenhænge.

Jeg har indtrykket at det mere upper management, der ønsker 'tryghed' - man
bliver ikke fyret for at købe IB^H^HMicrosoft.

De har i forvejen en masse Windows servere til sidesystemer m.m. og et par
folk, der kan 'peg og klik' konfigurere.

De ser det som en omkostning - og en risiko - at kaste sig ud i Linux.

Jeg vil jo nok mene, at hvis man er interesseret, burde det ikke være den
helt store ledvogtereksamen, at sætte et par samba servere op til at
begynde med.

Derudover kommer følgespørgsmålet:
Hvem skal jeg ringe til når det går ned?

> Been there, done that, set firmaet gå praktisk taget konkurs på et
> uovervejet skift til Windows som serverplatform :(

Forhåbentlig ikke de operationelle systemer?

--
Med venlig hilsen
Stig Johansen

---

Stig Johansen skrev den 18-05-2008 18:35:

> Derudover kommer følgespørgsmålet:
> Hvem skal jeg ringe til når det går ned?

Det er præcis det jeg henviste til før, med hensyn til tro på at ting
kører tilfredsstillende eller ej.

Der er ganske enkelt en forventning om at skramlet ikke virker
ordentligt, formentligt udledt af en kombination af tidligere
købeprodukter samt det forventningsniveau Microsoft har indpodet i folk.
Det er dog heldigvis blevet bedre de senere år.
--
Thorbjørn Ravn Andersen "... plus... Tubular Bells!"

---

Thorbjørn Ravn Andersen wrote:

> Stig Johansen skrev den 18-05-2008 18:35:
>
>> Derudover kommer følgespørgsmålet:
>> Hvem skal jeg ringe til når det går ned?
>
> Det er præcis det jeg henviste til før, med hensyn til tro på at ting
> kører tilfredsstillende eller ej.

Den fangede jeg nok ikke.

> Der er ganske enkelt en forventning om at skramlet ikke virker
> ordentligt, formentligt udledt af en kombination af tidligere
> købeprodukter samt det forventningsniveau Microsoft har indpodet i folk.

Nu ved jeg ikke hvad du mener med 'købeprodukter'.
I min optik er Linux kun blevet hvad det er, fordi firmaer som HP har stærk
interesse i det, og ikke fordi det er gratis.
Hvis du eksempelvis kigger på specs for Itanium processorerne, og hvilke
ting, der skal til for at lave en compiler, burde det være åbenlyst hvem
der står bag udviklingen.
Hvis du så sammenholder det med, at HP erklærede engang, at 'vi er hardware
firma og ikke software firma', så har jeg en stærk tro på, at HP arbejder
henimod at få aflivet deres egen HP-UX, og dermed spare
vedligeholdelsesbyrden.

Det samme gør sig formentlig gældende for IBM med at få Linux til at køre på
deres 'store jern'

At tro det er frivillige kræfter der står bag, er naivt.

--
Med venlig hilsen
Stig Johansen

---

Stig Johansen skrev den 18-05-2008 19:22:

> I min optik er Linux kun blevet hvad det er, fordi firmaer som HP har stærk
> interesse i det, og ikke fordi det er gratis.

Det er jeg ikke enig i. Linux er blevet hvad det er fordi produktet i
sig selv er godt og fordi det kunne løse nok opgaver til at opnå kritisk
masse.

Der er så også et spørgsmål om filosofi og udviklingsmodel som jeg tror
både folk og virksomheder kan se fornuften i, nemlig at man yder til en
fælles pulje og er garanteret at kunne få udbytte heraf. Dette i
sammenligning med BSD's udvikling som jo ikke har slået lige så grundigt an.

Linux er populært hos ikke-x86 virksomheder, fordi det er billigt.
Billigt at portere i tid og penge, og billigt at bruge. Prisen for at
levere et produkt er ganske enkelt lavest her. Bare se på alle de
trådløse routere der oversvømmer markedet - de billigste kører Linux
alle sammen fordi det gør dem fri til at snuppe en eller andet embedded
cpu fra fx Broadcom eller lignende og få i luften.

Er programmer først porteret til Linux, er det sædvanligvis yderst
beskedent arbejdsmæssigt at oversætte det til en anden arkitektur. Dvs
ved at portere Linux til en given platform har man pludselig en
GIGANTISK samling software. Det er også penge værd.

> Hvis du eksempelvis kigger på specs for Itanium processorerne, og hvilke
> ting, der skal til for at lave en compiler, burde det være åbenlyst hvem
> der står bag udviklingen.

Jeg har ikke sat mig ind i Itanium, men mener at have hørt at den er
bygget så compileren skal hoppe på tungen for at lave højtydende kode.
Det er naturligvis en fordel fordi så behøver man ikke lave DET i selve
CPU'en.

> Hvis du så sammenholder det med, at HP erklærede engang, at 'vi er hardware
> firma og ikke software firma', så har jeg en stærk tro på, at HP arbejder
> henimod at få aflivet deres egen HP-UX, og dermed spare
> vedligeholdelsesbyrden.

Det er dyrt at lave operativsystemer. Enhver med sans for penge burde
indse at det kan betale sig at slå pjalterne sammen med andre med mindre
at man virkelig har monopol på et eller andet marked, så man ikke
behøver bekymre sig.


>
> Det samme gør sig formentlig gældende for IBM med at få Linux til at køre på
> deres 'store jern'

På den IBM platform jeg arbejder med, har IBM faktisk lavet det sådan at
der er et AIX-emuleringsmodul såldes at man kan køre AIXprogrammer i
maven på en ikke-Unix. Det er RET smart.

Man kan selvfølgelig også køre Linux, men hvorfor skulle man det?


> At tro det er frivillige kræfter der står bag, er naivt.

Det er en kombination. I vore dage er de dygtigste udviklere hyret af
firmaer, men det ændrer ikke på at de sædvanligvis er hyret til at lave
det de gjorde i forvejen.


--
Thorbjørn Ravn Andersen "... plus... Tubular Bells!"

---

Thorbjørn Ravn Andersen wrote:

> Stig Johansen skrev den 18-05-2008 19:22:
>
>> I min optik er Linux kun blevet hvad det er, fordi firmaer som HP har
>> stærk interesse i det, og ikke fordi det er gratis.
>
> Det er jeg ikke enig i.

He - hvis vi er enige, bliver verden så kedelig.

> Linux er blevet hvad det er fordi produktet i
> sig selv er godt og fordi det kunne løse nok opgaver til at opnå kritisk
> masse.

Vi er enige om, at sådan er det nu, men jeg tror ikke på det er hjemmehøkere
der har stået for performanceoptimering og kvalitetssikring.

> Linux er populært hos ikke-x86 virksomheder, fordi det er billigt.
> Billigt at portere i tid og penge, og billigt at bruge. Prisen for at
> levere et produkt er ganske enkelt lavest her. Bare se på alle de
> trådløse routere der oversvømmer markedet - de billigste kører Linux
> alle sammen fordi det gør dem fri til at snuppe en eller andet embedded
> cpu fra fx Broadcom eller lignende og få i luften.

Der er også den mulighed, at det kun er Linux, der er så 'ren', at den kan
køre på de små CPU'er/RAM.

Jeg er nu stadig overbevist om, at det er ting som HP's ønske om at køre på
de største 'sataner', hvor der netop er behov for at spare på, ja næsten
hver eneste bit.

> Er programmer først porteret til Linux, er det sædvanligvis yderst
> beskedent arbejdsmæssigt at oversætte det til en anden arkitektur.

Lige bortset fra GUI'en. Man (Borland) lavede muligheden for at bruge Qt
under windows, men det er absolut ikke anbefalelsesværdigt.

> Dvs
> ved at portere Linux til en given platform har man pludselig en
> GIGANTISK samling software. Det er også penge værd.

Fuldstændig enig.

>
>> Hvis du eksempelvis kigger på specs for Itanium processorerne, og hvilke
>> ting, der skal til for at lave en compiler, burde det være åbenlyst hvem
>> der står bag udviklingen.
>
> Jeg har ikke sat mig ind i Itanium, men mener at have hørt at den er
> bygget så compileren skal hoppe på tungen for at lave højtydende kode.
> Det er naturligvis en fordel fordi så behøver man ikke lave DET i selve
> CPU'en.

Jeg vil ikke sige jeg har sat mig ind i Itanium, mere fået den præsenteret.
Her er lidt historie fra det virkelige liv, der foregår i slut 90'erne
(husker ikke årstallet).

Men HP holdt et præsentations seminar 'about things to come' for de største
kunder i DK.
Præsentationen blev afholdt af en af de højeste fra Silicon Valley.
Her fortale de, at de var i gang med et samarbejde med Intel om udviklingen
af kommende processorer til afløsning af deres Risc processorer.
Samarbejdet gik ud på, at HP har viden om processorer, og Intel har
faciliteter til massefremstilling.
Jeg tror han sagde noget med at det var lettere at bruge Intel, frem for
selv at bygge en fabrik.
Men klausulen var, at multiprocessor systemer var HP's domaine, og at Intel
max måtte fabrikere 2 processor bundkort.
Samtidig fortalte han, at HP havde udlånt 470 Systemprogrammører til
Microsoft, alene med det formål at få Windows servere til at køre på
'Mercedes', som nu hedder Itanium.

Lur mig om ikke de samme har en finger med i spillet på Linux også.

> Det er dyrt at lave operativsystemer. Enhver med sans for penge burde
> indse at det kan betale sig at slå pjalterne sammen med andre med mindre
> at man virkelig har monopol på et eller andet marked, så man ikke
> behøver bekymre sig.

Nu har jeg faktisk også solgt store HP systemer for 27-28 år siden, og der
var det netop Operativsystemet/Hardwaren, der var konkurrenceparameteren.

> På den IBM platform jeg arbejder med, har IBM faktisk lavet det sådan at
> der er et AIX-emuleringsmodul såldes at man kan køre AIXprogrammer i
> maven på en ikke-Unix. Det er RET smart.
>
> Man kan selvfølgelig også køre Linux, men hvorfor skulle man det?

Jeg kender ikke AIX og forskelle på den og Linux.
Umiddelbart forestiller jeg mig Yet Another Unixvariant?

> Det er en kombination. I vore dage er de dygtigste udviklere hyret af
> firmaer, men det ændrer ikke på at de sædvanligvis er hyret til at lave
> det de gjorde i forvejen.

Mig ikke rigtig forstå.
De dygtigste udviklere har da altid været hyret af firmaer eller ?

--
Med venlig hilsen
Stig Johansen

---

Stig Johansen skrev den 18-05-2008 21:34:

>>> I min optik er Linux kun blevet hvad det er, fordi firmaer som HP har
>>> stærk interesse i det, og ikke fordi det er gratis.
>> Det er jeg ikke enig i.
>
> He - hvis vi er enige, bliver verden så kedelig.

Nejda, bare vi er enige om at det er mine synspunkter vi er enige om.


>> Linux er blevet hvad det er fordi produktet i
>> sig selv er godt og fordi det kunne løse nok opgaver til at opnå kritisk
>> masse.
>
> Vi er enige om, at sådan er det nu, men jeg tror ikke på det er hjemmehøkere
> der har stået for performanceoptimering og kvalitetssikring.

Ikke? Jeg tror faktisk du undervurderer hvor mange gennem tiden der har
rodet med det fordi de synes det er sjovt.

Husk også at Linux er kernen og så er der alle distributionerne. Debian
fx er vist stadigvæk rent drevet af hobbyfolk/amatører/whatever.

Bemærk også hvor ekstremt hurtigt Ubuntu blev populær. Jeg tror den
altafgørende faktor var at Canonical sagde at der var EN distribution,
som var beregnet til almindelige mennesker, i stedet for en Enterprise
og en discount-gratis til at lokke kunderne ind i folden.

Jeg håber bare at Ubuntu og Debian finder fælles fodslaw igen, så det er
en sand synergi.

Debian er iøvrigt den distribution der kan køre på min bette router som
den eneste.

> Der er også den mulighed, at det kun er Linux, der er så 'ren', at den kan
> køre på de små CPU'er/RAM.

Nejda. Kig på hvor mange håndholdte der kører en Windowsvariant. Se på
kravene til NT 4.0 (som iøvrigt nok var den reneste variant og som
fandtes til Alpha, x86 og vistnok også PowerPC).

Men det er naturligvis relevant at den grundlæggende model er så simpel
at der stilles begrænsede krav til hardwaren.

> Jeg er nu stadig overbevist om, at det er ting som HP's ønske om at køre på
> de største 'sataner', hvor der netop er behov for at spare på, ja næsten
> hver eneste bit.

Ahva? De største maskiner har da de største resourcer.


>> Er programmer først porteret til Linux, er det sædvanligvis yderst
>> beskedent arbejdsmæssigt at oversætte det til en anden arkitektur.
>
> Lige bortset fra GUI'en. Man (Borland) lavede muligheden for at bruge Qt
> under windows, men det er absolut ikke anbefalelsesværdigt.

Du misforstår. Jeg snakker om en anden CPU-arkitektur.


> Jeg tror han sagde noget med at det var lettere at bruge Intel, frem for
> selv at bygge en fabrik.

Det er det også. Der er fordele og ulemper ved alting. IBM laver også
Cell processorer til Sony.


> Lur mig om ikke de samme har en finger med i spillet på Linux også.

Selvfølgelig har de da det. Ellers ville de da være godt dumme. Men
ser du, det er ikke dem der styrer det - som jeg har forstået det er
HP's kernerettelser ikke finere eller bedre end alle andres - Linus
skulle være en ret hård dommer desangående.

>> Det er dyrt at lave operativsystemer. Enhver med sans for penge burde
>> indse at det kan betale sig at slå pjalterne sammen med andre med mindre
>> at man virkelig har monopol på et eller andet marked, så man ikke
>> behøver bekymre sig.
>
> Nu har jeg faktisk også solgt store HP systemer for 27-28 år siden, og der
> var det netop Operativsystemet/Hardwaren, der var konkurrenceparameteren.

Det var så HP/UX. Verden har ændret sig siden - i dag kan man tage en
hyldepc og smide en Linux/whatever på og have en højtydende server. Det
kunne man ikke dengang.

> Jeg kender ikke AIX og forskelle på den og Linux.
> Umiddelbart forestiller jeg mig Yet Another Unixvariant?

Korrekt. AIX er IBM's Unix, ligesom HP/UX er HP's Unix.

Sammenlign det med at Linuxprogrammer kunne køre direkte i en CMD.EXE
under Windows.

>> Det er en kombination. I vore dage er de dygtigste udviklere hyret af
>> firmaer, men det ændrer ikke på at de sædvanligvis er hyret til at lave
>> det de gjorde i forvejen.
>
> Mig ikke rigtig forstå.
> De dygtigste udviklere har da altid været hyret af firmaer eller ?

Der er rigtigt mange der har arbejdet med Linux for sjov, og hvor
firmaer har vurderet at deres arbejde var så meget værd for dem at de
ville betale dem for at gøre det fuldtids.

Altså at arbejdet med Linux var kvalifikationen, ikke den opgave der var
fundet til dem.


--
Thorbjørn Ravn Andersen "... plus... Tubular Bells!"

---

Thorbjørn Ravn Andersen wrote:

> Stig Johansen skrev den 18-05-2008 21:34:
>
> Ikke? Jeg tror faktisk du undervurderer hvor mange gennem tiden der har
> rodet med det fordi de synes det er sjovt.

Jeg er sikker på, der er _rigtig_ mange, der har rodet med det for sjov.
Men jeg tror også, at rigtig meget af det bliver til slamkode.

> Husk også at Linux er kernen og så er der alle distributionerne. Debian
> fx er vist stadigvæk rent drevet af hobbyfolk/amatører/whatever.

Det er jeg med på, og det er også kun serverdelen jeg interesserer mig for.

> Bemærk også hvor ekstremt hurtigt Ubuntu blev populær. Jeg tror den
> altafgørende faktor var at Canonical sagde at der var EN distribution,
> som var beregnet til almindelige mennesker, i stedet for en Enterprise
> og en discount-gratis til at lokke kunderne ind i folden.
>
> Jeg håber bare at Ubuntu og Debian finder fælles fodslaw igen, så det er
> en sand synergi.

Jeg håber de alle sammen finder fælles fodslag. Alene det at have KDE og
Gnome ting på samme maskine er, rent ud sagt irriterende.

Jeg kører selv SuSE - why? Det ved jeg faktisk ikke.
Så vidt jeg husker startede jeg med Mandrake, men det var noget knald.
SuSE var nok den første dist, der _ikke_ fejlede i tide og utide.

> Debian er iøvrigt den distribution der kan køre på min bette router som
> den eneste.

Til min bette server, i det her projekt bruger jeg
<http://www.minimalinux.org/ttylinux/>
Det foresvæver mig den er bygget på Debian, men jeg kan ikke lige finde
noget om det.

Det er lidt et forsøg på at se hvor meget man kan presse ud af hvor lidt, så
det er derfor jeg vægrer mig ved at installere noget somhelst (unødigt).

Det eneste jeg har tilføjet er SQLite, som er en imponerende størrrelse.
Hele moletjavsen i en 335KB lib fil.

> Nejda. Kig på hvor mange håndholdte der kører en Windowsvariant.

Jeg bruger ikke håndholdte.
Enten skal de laves med en 19" skærm, eller også skal jeg have kraftigere
briller. Men hvis du tænker på PDA'er, så fandtes der vel ikke et reelt
grafisk alternativ til Windows.

> Se på
> kravene til NT 4.0 (som iøvrigt nok var den reneste variant og som
> fandtes til Alpha, x86 og vistnok også PowerPC).

Så vidt jeg husker, var NT 4.0 blot en shell upgrade til 3.51, så den fik
samme brugerflade som Windows 95.

>> Jeg er nu stadig overbevist om, at det er ting som HP's ønske om at køre
>> på de største 'sataner', hvor der netop er behov for at spare på, ja
>> næsten hver eneste bit.
>
> Ahva? De største maskiner har da de største resourcer.

Ja, men der er 2 måder at lave de største (=hurtigste) maskiner.
1) At bygge det største jern.
2) At bygge det mindst ressourcekrævende OS.

Hvis man gerne vil lege i det her område:
<http://www.linuxhpc.org/stories.php?story=07/11/21/6521500>

tror jeg begge dele er lige vigtige.

> Du misforstår. Jeg snakker om en anden CPU-arkitektur.

Ok, my mistake.

>> Lur mig om ikke de samme har en finger med i spillet på Linux også.
>
> Selvfølgelig har de da det. Ellers ville de da være godt dumme. Men
> ser du, det er ikke dem der styrer det - som jeg har forstået det er
> HP's kernerettelser ikke finere eller bedre end alle andres - Linus
> skulle være en ret hård dommer desangående.

Det var nu ikke ment som at de var finere eller bedre, men at virksomheder
har enorme ressoucrser til at sætte 100 vis af folk på fulltime.

IBM - kan du huske denne her:
<http://www.news.com/2100-1001_3-249750.html>

Jeg er rimelig sikker på der stod rundt omkring, at HP ville investere
tilsvarende, dog i form af manpower, og ikke med beløb på.
Men jeg kan ikke finde det på Google.

>> Nu har jeg faktisk også solgt store HP systemer for 27-28 år siden, og
>> der var det netop Operativsystemet/Hardwaren, der var
>> konkurrenceparameteren.
>
> Det var så HP/UX. Verden har ændret sig siden - i dag kan man tage en
> hyldepc og smide en Linux/whatever på og have en højtydende server. Det
> kunne man ikke dengang.

Det var det nu ikke, men MPE:
<http://en.wikipedia.org/wiki/HP_3000>

(HP's tekniske OS hed i øvrigt RTE dengang)

Hmm. kommer i tanke om dengang, hvor alle HP's computere var minicomputere,
og alle IBM's var mainframes.

For HP's vedkommende var det markedsføring, for de ville være verdens
største leverandør af minicomputere.

> Der er rigtigt mange der har arbejdet med Linux for sjov, og hvor
> firmaer har vurderet at deres arbejde var så meget værd for dem at de
> ville betale dem for at gøre det fuldtids.
>
> Altså at arbejdet med Linux var kvalifikationen, ikke den opgave der var
> fundet til dem.

Ok, jeg er ikke velbevandret nok i Linuxverdenen til at kunne vurdere, så
jeg bliver vel nødt til at give dig ret.


--
Med venlig hilsen
Stig Johansen

---

Stig Johansen skrev den 18-05-2008 23:52:

> Jeg er sikker på, der er _rigtig_ mange, der har rodet med det for sjov.
> Men jeg tror også, at rigtig meget af det bliver til slamkode.

Som jeg skrev, Linus har høje krav til kode der skal i kernen.

> Jeg håber de alle sammen finder fælles fodslag. Alene det at have KDE og
> Gnome ting på samme maskine er, rent ud sagt irriterende.

Det gør de ikke. Der er nok der vil have KDE til at det bliver
arbejdet med, og tilsvarende med Gnome.


> Til min bette server, i det her projekt bruger jeg
> <http://www.minimalinux.org/ttylinux/>
> Det foresvæver mig den er bygget på Debian, men jeg kan ikke lige finde
> noget om det.

Det har du nævnt før. Jeg vil endnu engang foreslå dig at skifte til en
distribution der er understøttet af dit udviklingsværktøj.

>> Nejda. Kig på hvor mange håndholdte der kører en Windowsvariant.
>
> Jeg bruger ikke håndholdte.

Det er der andre der gør.

> Enten skal de laves med en 19" skærm, eller også skal jeg have kraftigere
> briller. Men hvis du tænker på PDA'er, så fandtes der vel ikke et reelt
> grafisk alternativ til Windows.

Ikke? Palm sad da godt på markedet. Ved ikke hvad status er i dag.

>
>> Se på
>> kravene til NT 4.0 (som iøvrigt nok var den reneste variant og som
>> fandtes til Alpha, x86 og vistnok også PowerPC).
>
> Så vidt jeg husker, var NT 4.0 blot en shell upgrade til 3.51, så den fik
> samme brugerflade som Windows 95.

Ikke blot. Faktum er at den NT der er driverunderstøttelse til hvis der
er, er 4.0.

Til den her diskussion er de præcise detaljer ikke vigtige - målet er
hvad NT kernen kræver for at køre.


> Det var nu ikke ment som at de var finere eller bedre, men at virksomheder
> har enorme ressoucrser til at sætte 100 vis af folk på fulltime.

Men det gør de ikke. Det gør de på Windows.

>
> IBM - kan du huske denne her:
> <http://www.news.com/2100-1001_3-249750.html>

Jaja, det har været igennem marketingmøllen. Min personlige mening er
at IBM har vurderet at de er nødt til at skære ned på antallet af
arkitekturer og platforme for at kunne lave software med kritisk masse.
De har også fremragende java-maskiner på alle platforme af samme grund.

>> Altså at arbejdet med Linux var kvalifikationen, ikke den opgave der var
>> fundet til dem.
>
> Ok, jeg er ikke velbevandret nok i Linuxverdenen til at kunne vurdere, så
> jeg bliver vel nødt til at give dig ret.

God indstilling der. Det skal du nok komme...

--
Thorbjørn Ravn Andersen "... plus... Tubular Bells!"

---

Thorbjørn Ravn Andersen wrote:

> Stig Johansen skrev den 18-05-2008 23:52:
>> Til min bette server, i det her projekt bruger jeg
>> <http://www.minimalinux.org/ttylinux/>
>> Det foresvæver mig den er bygget på Debian, men jeg kan ikke lige finde
>> noget om det.
>
> Det har du nævnt før. Jeg vil endnu engang foreslå dig at skifte til en
> distribution der er understøttet af dit udviklingsværktøj.

Det er min _deployment_ distribution, og ikke min _udviklingsdistribution_ ,
der er himmelvid til forskel.

Jeg kan ikke rigtig se hvad jeg skal bruge udviklingsværktøjer til på
deployment, og vice verca.

Har du selv installeret alle udviklingsværktøjer på dine prod maskiner?

--
Med venlig hilsen
Stig Johansen

---

Stig Johansen skrev den 19-05-2008 01:58:
> Thorbjørn Ravn Andersen wrote:
>
>> Stig Johansen skrev den 18-05-2008 23:52:
>>> Til min bette server, i det her projekt bruger jeg
>>> <http://www.minimalinux.org/ttylinux/>
>>> Det foresvæver mig den er bygget på Debian, men jeg kan ikke lige finde
>>> noget om det.
>> Det har du nævnt før. Jeg vil endnu engang foreslå dig at skifte til en
>> distribution der er understøttet af dit udviklingsværktøj.
>
> Det er min _deployment_ distribution, og ikke min _udviklingsdistribution_ ,
> der er himmelvid til forskel.
>
> Jeg kan ikke rigtig se hvad jeg skal bruge udviklingsværktøjer til på
> deployment, og vice verca.
>
> Har du selv installeret alle udviklingsværktøjer på dine prod maskiner?

Nej. Men jeg har de værktøjer installeret der er nødvendige for at løse
et problem, og det foresvæver mig du har et problem du ikke kan fejlfinde.

--
Thorbjørn Ravn Andersen "... plus... Tubular Bells!"

---

Thorbjørn Ravn Andersen wrote:

> Stig Johansen skrev den 19-05-2008 01:58:
>> Har du selv installeret alle udviklingsværktøjer på dine prod maskiner?
>
> Nej. Men jeg har de værktøjer installeret der er nødvendige for at løse
> et problem, og det foresvæver mig du har et problem du ikke kan fejlfinde.

Jeg begynder at mistænke dig for at tænke i serielle baner.
Det er tale om, nogle gange, massiv parallellisme - og en hændelsesstyret
(ikke umiddelbar replicérbar) observation.

Hvis du har nogen form for parallellisme i dine systemer, hvilket værktøj
bruger du så ?

- Og vi snakker NPTL threads, som _ikke_ har selvstændige pid'er.

Valgrind er som nævnt udelukket, for i og med den nedsætter performance med
en faktor 20, ødelægger den muligheden for at (gen)skabe parallellismen.

Du kunne også nævne hvilket værktøj du ville bruge hvis du skulle profilere
din Linux baserede router.
Det er nok mere der vi skal henad.

--
Med venlig hilsen
Stig Johansen

---

Stig Johansen skrev den 19-05-2008 15:28:

>> Nej. Men jeg har de værktøjer installeret der er nødvendige for at løse
>> et problem, og det foresvæver mig du har et problem du ikke kan fejlfinde.
>
> Jeg begynder at mistænke dig for at tænke i serielle baner.
> Det er tale om, nogle gange, massiv parallellisme - og en hændelsesstyret
> (ikke umiddelbar replicérbar) observation.

Jeg har skam forstået at du har fået stablet en ganske interessant
situation på benene. Du har også forstået at standard-debuggeren under
Linux er gdb og at denne kombineret med lidt tælleværk i dine NPTL tråde
kan få dig til at få en cirka-ide om hvilke det er der drøner derudaf
hvis du sammenligner situationen mellem to breaks. Nå, det var bare
rygmarvsreaktionen - jeg søgte lidt på nptl og Wikipedia har en udmærket
artikel der lige fik mig med på hvad det er du roder med. De har
pudsigt nok også et link til http://nptltracetool.sourceforge.net/

"The POSIX Thread Trace Toolkit (PTT) is a library-level trace tool for.
the glibc (GNU C library) thread library (Native POSIX Thread Library or
NPTL). It aims to help users to analyze and debug multi-threaded
applications using the NPTL under Linux systems."

Gad vide om du kan bruge det til noget?

> Hvis du har nogen form for parallellisme i dine systemer, hvilket værktøj
> bruger du så ?

Jeg har masser af parallisme - det er så dejligt nemt i Java :)

> - Og vi snakker NPTL threads, som _ikke_ har selvstændige pid'er.

Jaja, rolig nu.

> Du kunne også nævne hvilket værktøj du ville bruge hvis du skulle profilere
> din Linux baserede router.

Først ville jeg vurdere situationen. Jeg tror som bekendt stadig at du
bruger alle de der porte forkert.

> Det er nok mere der vi skal henad.

Nu får vi se :)


--
Thorbjørn Ravn Andersen "... plus... Tubular Bells!"

---

Thorbjørn Ravn Andersen wrote:

> Linux er gdb og at denne kombineret med lidt tælleværk i dine NPTL tråde
> kan få dig til at få en cirka-ide om hvilke det er der drøner derudaf
> hvis du sammenligner situationen mellem to breaks. Nå, det var bare
> rygmarvsreaktionen

Det var præcis den slags jeg hentydede til med 'fattigmandsdebuggeren'.

> "The POSIX Thread Trace Toolkit (PTT) is a library-level trace tool for.
> the glibc (GNU C library) thread library (Native POSIX Thread Library or
> NPTL). It aims to help users to analyze and debug multi-threaded
> applications using the NPTL under Linux systems."
>
> Gad vide om du kan bruge det til noget?

hmm..
.......
even when a lot of threads are involved (less than 5% with 16 concurrent
threads on 8xia32).
.......
Jeg snakker 100-200+, ikke sølle 16 tråde.

Men fælles for den og 'fattigmandsdebuggeren' er, at tracen/loggen skal køre
hele tiden.

Situationen er opstået 2 gange i de par måneder den har kørt 24/7.
Jeg kan ikke umiddelbart genskabe situationen, og ved ikke hvornår - eller
hvis, den nogensinde opstår igen.

Og husk, der er ingenting der hænger, så der er tale om et eller andet
infinite loop.
Det kan være alt muligt - en tråd der ikke får afleveret sine data pga.
afbrydelse af forbindelse, race conditions i SQLite, race conditions i brug
at mutexes m.v.

>> Du kunne også nævne hvilket værktøj du ville bruge hvis du skulle
>> profilere din Linux baserede router.
>
> Først ville jeg vurdere situationen.

Det er også det jeg gør.
Nu har jeg fundet ud af, at der ligger detaljerede oplysninger
i /proc/<pid>/task om hver enkelt tråd.

Når, eller hvis, situationen opstår igen tager jeg den derfra.

> Jeg tror som bekendt stadig at du
> bruger alle de der porte forkert.

Her må tænker du nok på min tunnel/filter?
Det har også kørt fejlfrit i månedsvis, og der er ingen problemer der.

Jeg var bare forunderet over den lange TIME_WAIT, der sætter en øvre grænse
for sustained requests/sekund. Og da det er sockets, der sætter
begrænsningen,gælder det for alle systemer, også Java m.m.


--
Med venlig hilsen
Stig Johansen

---

On 2008-05-18, Thorbjørn Ravn Andersen <thunderaxiom@gmail.com> wrote:
>
>> Enten skal de laves med en 19" skærm, eller også skal jeg have kraftigere
>> briller. Men hvis du tænker på PDA'er, så fandtes der vel ikke et reelt
>> grafisk alternativ til Windows.
>
> Ikke? Palm sad da godt på markedet. Ved ikke hvad status er i dag.

Man bør nok mindst nævne Symbian.

--
Andreas

---

Stig Johansen <wopr.dk@gmaill.com> writes:

> Anders Wegge Jakobsen wrote:

>> Stig Johansen <wopr.dk@gmaill.com> writes:
>>> Don't shoot the messenger. Jeg refererer bare hvad jeg får at vide
>>> på 'de bonede gulve'.

>> Oversat til dansk betyder det at sælgerne skyder på alt hvad der
>> bevæger sig, når de skal finde på en god grund til at de ikke fik
>> ordren i hus.

...

> Jeg har indtrykket at det mere upper management, der ønsker
> 'tryghed' - man bliver ikke fyret for at købe IB^H^HMicrosoft.

Det er ikke meget galt.

...

> Derudover kommer følgespørgsmålet: Hvem skal jeg ringe til når det
> går ned?

Hvem ringer du til nu? Vi har for eksempel en kunde der har en 20-30
arbejdsstationer der kører VB6. Har du et nummer vi kan ringe til, når
vi skal have stadset til at køre på en XP, fordi vi ikke længere kan
få noget hardware der er supporteret af NT 4.0?

>> Been there, done that, set firmaet gå praktisk taget konkurs på et
>> uovervejet skift til Windows som serverplatform :(

> Forhåbentlig ikke de operationelle systemer?

Jo.

--
// Wegge
<http://blog.wegge.dk> - Her hænger jeg også ud.
<http://geowiki.wegge.dk/wiki/Forside> - Alt om geocaching.
Bruger du den gratis spamfighther ser jeg kun dine indlæg *EN* gang.

---

Anders Wegge Jakobsen wrote:

> Stig Johansen <wopr.dk@gmaill.com> writes:
>> Derudover kommer følgespørgsmålet: Hvem skal jeg ringe til når det
>> går ned?
>
> Hvem ringer du til nu?

Jeg er ikke sikker på jeg forstår denne her rigtigt, men for lige at
præcisere:
Der er upper management, der spørger _mig_ hvem de skal ringe til, ikke mig
der spørger.

Jeg kender ikke nogle firmaer, der yder support på Linux i den skala, så jeg
kan ikke svare. Jeg har ingen intentioner om at forsøge at fortælle
beslutningstagere om teknik og support via usenet m.m.

Apropos usenet, så bruger alle Outlook og Exchange, men der er ikke rigtig
usenet funktioner i den slags, så ikke engang IT medarbejderne eller IT
cheferne ved hvad usenet er for noget.

> Vi har for eksempel en kunde der har en 20-30
> arbejdsstationer der kører VB6.

VB6, er det ikke abandonware udviklingsværktøj fra MS?
Mener du udvikle på, eller 'køre' som i den der vbrundll - ting?

> Har du et nummer vi kan ringe til, når
> vi skal have stadset til at køre på en XP

Jeg ville ringe til leverandøren af softwaren.

> , fordi vi ikke længere kan
> få noget hardware der er supporteret af NT 4.0?

Er det så serveren - NT 4.0?
For klienterne burde der ikke være den store forskel om den kører NT 4.0
eller andet, blot protokollerne er kompatible.

Hvis det er omkostninger til serverlicenser m.v. du tænker på, så kunne i
kigge på en WmWare løsning, og bibeholde NT 4.0.


--
Med venlig hilsen
Stig Johansen

---

Stig Johansen <wopr.dk@gmaill.com> wrote:

> Jeg kender ikke nogle firmaer, der yder support på Linux i den skala, så jeg
> kan ikke svare. Jeg har ingen intentioner om at forsøge at fortælle
> beslutningstagere om teknik og support via usenet m.m.

Min oplevelse er at det er langt lettere at få ordenlig support på Linux
(lige fra rygraden kender jeg til RedHat, Novell (SuSE) og Canonical (Ubuntu), men der er helt sikkert mange flere). Min oplevelse af support fra Microsoft er at den er meget fraværende.

mvh
--
Allan Willems Joergensen, OnDemand: http://www.nowhere.dk

"Bother," said Pooh, as the writers killed off his character.

---

Stig Johansen <wopr.dk@gmaill.com> writes:

> Anders Wegge Jakobsen wrote:
>
>> Stig Johansen <wopr.dk@gmaill.com> writes:
>>> Derudover kommer følgespørgsmålet: Hvem skal jeg ringe til når det
>>> går ned?
>
>> Hvem ringer du til nu?

> Jeg er ikke sikker på jeg forstår denne her rigtigt, men for lige at
> præcisere: Der er upper management, der spørger _mig_ hvem de skal
> ringe til, ikke mig der spørger.

Hvem mener din "upper managment" så at de kan ringe til nu?

...

>> Vi har for eksempel en kunde der har en 20-30 arbejdsstationer der
>> kører VB6.

> VB6, er det ikke abandonware udviklingsværktøj fra MS? Mener du
> udvikle på, eller 'køre' som i den der vbrundll - ting?

Udvikle som i "Få stadset til at fungere, når kunden finder endnu en
fejl."

>> Har du et nummer vi kan ringe til, når vi skal have stadset til at
>> køre på en XP

> Jeg ville ringe til leverandøren af softwaren.

Det er os der er leverandøren af applikationen. Problemet er support
af platformen.

>> , fordi vi ikke længere kan få noget hardware der er supporteret af
>> NT 4.0?

> Er det så serveren - NT 4.0? For klienterne burde der ikke være den
> store forskel om den kører NT 4.0 eller andet, blot protokollerne er
> kompatible.

Fortæl endelig hvordan du får en VB6-applikation til at køre på XP.

> Hvis det er omkostninger til serverlicenser m.v. du tænker på, så
> kunne i kigge på en WmWare løsning, og bibeholde NT 4.0.

Licenser er det mindste problem.

--
// Wegge
<http://blog.wegge.dk> - Her hænger jeg også ud.
<http://geowiki.wegge.dk/wiki/Forside> - Alt om geocaching.
Bruger du den gratis spamfighther ser jeg kun dine indlæg *EN* gang.

---

Anders Wegge Jakobsen wrote:

> Stig Johansen <wopr.dk@gmaill.com> writes:
>
> Hvem mener din "upper managment" så at de kan ringe til nu?

Den slags virksomheder har typisk en global oem eller select aftale, eller
hvad det hedder p.t. i størrelsesordenen 10-25.000 arbejdpladser, for
formentlig en tusind stykker windows servere, så jeg er lige ved at tro, de
få selve William i tale.

Men ellers der hvor de handler udstyr, nogle gange HP, nogle gange IBM, lidt
afhængig af hvad dagens 'mærke er'.

Top Nordic synes jeg også jeg har hørt.

>> VB6, er det ikke abandonware udviklingsværktøj fra MS? Mener du
>> udvikle på, eller 'køre' som i den der vbrundll - ting?
>
> Udvikle som i "Få stadset til at fungere, når kunden finder endnu en
> fejl."

Jeg må indrømme, at jeg aldrig har rørt ved VB.
På PC/PC-serversiden siden har jeg brugt Borlands Turbo Pascal siden midt
80'erne, og i de sidste 10-11 år Delphi.

Hvis 'kunden finder en fejl' er vel lidt pinligt, for en programmerings fejl
burde nok have været fundet inden afleveringen.

Men hvis du mener fejl i de bagvedliggende MS komponenter m.v., så kan jeg
godt se problemet, og irritationen.

> Det er os der er leverandøren af applikationen. Problemet er support
> af platformen.

I og med MS har droppet VB tror jeg ikke der er nogen der vil yde support på
den slags.

>> Er det så serveren - NT 4.0? For klienterne burde der ikke være den
>> store forskel om den kører NT 4.0 eller andet, blot protokollerne er
>> kompatible.
>
> Fortæl endelig hvordan du får en VB6-applikation til at køre på XP.

Det kan jeg ikke uden at kende problemet.
Jeg kører selv Win2K, uden .NET og dillerdaller, og den kører lige så
hurtigt som den altid har gjort, så jeg ingen intentioner om at 'opgradere'
til XP, eller Vista for den sags skyld.

Jeg gør mere i (native code) middleware laget, og der er der ikke rigtig
nogle problemer med de nyere Windows server versioner.

Jeg følger dog med i Borland grupperne, hvor der antageligt er flere
millioner læsere, og synes jeg har set noget med:
Problemer med manifester, men det er vist kun udseende.
Problemer med placering af brugerfiler,inifiler, m.m. Her er det en
sikkerhedsopstramning, der er problemet, og kræver andre (directory)
placeringer af disse filer.

Men der er 100 vis af folk, der kender både VB6,C#,C++ m.m. så hvis du
skriver (præcist) hvad problemet er, kan jeg godt spørge over i Borland
grupperne.

--
Med venlig hilsen
Stig Johansen

---

Stig Johansen skrev den 18-05-2008 22:02:

> Hvis 'kunden finder en fejl' er vel lidt pinligt, for en programmerings fejl
> burde nok have været fundet inden afleveringen.

Det er tit nemmere sagt end gjort. Når man interagerer med den
virkelige verden i sine programmer, kan der opstå fejl man simpelthen
ikke kunne forudse og dem skal man naturligvis så tilrette så de bliver
håndteret.

Eksempel: Du styrer en ftp-klient som glad og fro flytter filer frem og
tilbage, men hos en bestemt kunde virker det ikke pga deres firewall
forlanger en speciel måde at gøre tingene på (aktiv/passiv, åbne ved at
prikke på en port/bruge proxy/osv). Din kode skal så udvides til at
håndtere dette.

Jeg er ret sikker på at det er tilsvarende ting Anders er velsignet med.

> I og med MS har droppet VB tror jeg ikke der er nogen der vil yde support på
> den slags.

Og der har man fremtidens helvede - den valgte platform visner lige så
stille væk - og SÅ har man problemet.

Hvilket bringer os tilbage til closed source problematikken. Havde
Microsoft valgt at lave VB6 open source, ville disse programmer leve
evigt fordi man KUNNE holde skidtet i luften.

Det har menigmand ikke set endnu fordi Microsoft har været så gode til
at sikre at gamle binære programmer kører som de skal under nye Windows
versioner. Jeg synes dog jeg kunne forstå på Anders at det var ved at
gå over.

Personligt er jeg dybt forundret over at der ikke er en bevægelse til at
indsamle penge til Wineprojektet simpelhten for at have et alternativ
til hvad nu Microsoft finder på der IKKE vil virke med et eller andet
meget vigtigt program.

Min egen verden er heldigvis lidt sikrere. Jeg arbejder med Java, og
det er netop blevet udødeliggjort ved at Sun frigiver hele dynen under
GPL. Så kan virksomhed X ikke slå Java ihjel ved at købe det og lukke
butikken som Microsoft i praksis gjorde med Mono ved at lave
patentaftalen med Novell.


> Jeg kører selv Win2K, uden .NET og dillerdaller, og den kører lige så
> hurtigt som den altid har gjort, så jeg ingen intentioner om at 'opgradere'
> til XP, eller Vista for den sags skyld.

Det kommer den dag hvor din netbank kræver IE7 :)

Glæder du dig ikke?
--
Thorbjørn Ravn Andersen "... plus... Tubular Bells!"

---

Thorbjørn Ravn Andersen wrote:

> Stig Johansen skrev den 18-05-2008 22:02:
>
>> Hvis 'kunden finder en fejl' er vel lidt pinligt, for en programmerings
>> fejl burde nok have været fundet inden afleveringen.
>
> Det er tit nemmere sagt end gjort.

Den sætning var møntet på en decideret programmeringsfejl i selve
applikationen.

> Når man interagerer med den
> virkelige verden i sine programmer, kan der opstå fejl man simpelthen
> ikke kunne forudse og dem skal man naturligvis så tilrette så de bliver
> håndteret.

Et virkeligt eksempel fra den virkelige verden.
Jeg havde engang lavet en 24/7 service til Windows server, der bla.
opdaterede i MS SQLServer ud fra nogle operationelle databaser.
En dag var der pludselig fejl, efter 1 ½ års fejlfri drift.
Selvfølgelig var det i Jylland, og jeg bor på Sjælland, så krudte dytten.
Der gik rigtig lang tid med at finde ud af hvad f* der pludselig skulle være
galt med SQL sætningerne.

INDTIL - jeg fandt ud af, at man havde 'opgraderet' MS SQLServeren, og i den
forbindelse havde vores kære William benyttet chancen til at disable
standard Quoting (") og indført sin 'nye' standard ([]).

Det kunne heldigvis konfigureres tilbage, men jeg kunne ikke forklare, at
det ikke var mist system der fejlede, men MS.

At sluge - en returbillet til Jylland, incl benzin m.v. og en samlet wall
time på omkring 16 timer.

> Jeg er ret sikker på at det er tilsvarende ting Anders er velsignet med.

Jeg er også sikker på det er tilsvarende ting.
Microsoft skal nok sørge for at 'gamle' ting ikke virker, så man er tvunget
til at 'opgradere' hele tiden.

>> I og med MS har droppet VB tror jeg ikke der er nogen der vil yde support
>> på den slags.
>
> Og der har man fremtidens helvede - den valgte platform visner lige så
> stille væk - og SÅ har man problemet.

Lige i det her tilfælde synes jeg nok man er lidt sent ude.
Det har været alment kendt, at MS stoppede med VB6 for at promovere sit .NET
omkring årtusindeskiftet.
Wikipedia <http://en.wikipedia.org/wiki/Visual_Basic> siger
....
The final release was version 6 in 1998. Microsoft's extended support ended
in February 2008 and the designated successor was Visual Basic .NET.
....

Det kan godt være det lyder lidt hårdt, men man har sådan set haft 10 år til
at omlægge sit system.

> Hvilket bringer os tilbage til closed source problematikken. Havde
> Microsoft valgt at lave VB6 open source, ville disse programmer leve
> evigt fordi man KUNNE holde skidtet i luften.

Jeg kan godt lide din enthusiasme, men det er ikke VB6, der er problemet,
det er garanteret Windows OS'et, der ikke er kompatibelt.

Men hvis _Windows_ blev open source, så er det en helt anden snak.

> Personligt er jeg dybt forundret over at der ikke er en bevægelse til at
> indsamle penge til Wineprojektet simpelhten for at have et alternativ
> til hvad nu Microsoft finder på der IKKE vil virke med et eller andet
> meget vigtigt program.

Jeg synes jeg så et eller andet sted, at wine er ret aggressiv p.t. og
forventer at nå en release 1.0 snart.

Men man skal vist stadig have dll filer fra windows (=licens) for at kunne
køre 100%, så det er spørgsmålet om der er 'redningen'.

> Så kan virksomhed X ikke slå Java ihjel ved at købe det og lukke
> butikken som Microsoft i praksis gjorde med Mono ved at lave
> patentaftalen med Novell.

Time will show.

Jeg er lidt forundret over hvem der er i seng med hvem, og hvorfor.
På den ene side, så satser IBM tilsyneladende på Java, og dermed halvvejs er
i seng med Sun.
På den anden side, hørte jeg, under et projekt i Videnskabsministeriet, at
extensions til Webservices, var defineret/udviklet af MS og IBM i samråd,
og til sidst lagt ud som standard.
Altså aktiv udelukkelse af Sun - som også en Sun repræsentant fortalte - ja,
en direkte nægtelse af Suns medvirken.
På det område er IBM tilsyneladende i seng med MS, og Sun er 'fjenden'.

> Det kommer den dag hvor din netbank kræver IE7 :)

Jeg tror der er rigeligt fokus på Netbankernes manglende evner til at lave
ordentlige systemer, så det tror jeg ikke kommer til at ske.

Hvis det sker går jeg ind og låner en af naboens PC'ere.

> Glæder du dig ikke?


--
Med venlig hilsen
Stig Johansen

---

Stig Johansen skrev den 19-05-2008 01:18:

> Det kunne heldigvis konfigureres tilbage, men jeg kunne ikke forklare, at
> det ikke var mist system der fejlede, men MS.
>
> At sluge - en returbillet til Jylland, incl benzin m.v. og en samlet wall
> time på omkring 16 timer.

Sært. Eftersom det faldt sammen med en opgradering af kernesoftware...

Så sagde du vel at det virkede på det det var solgt til, og at du ikke
kunne gøre for at de ændrede på forudsætningerne? Så må det vel være
"nedgrader og det virker som købt".

>> Og der har man fremtidens helvede - den valgte platform visner lige så
>> stille væk - og SÅ har man problemet.
>
> Lige i det her tilfælde synes jeg nok man er lidt sent ude.
> Det har været alment kendt, at MS stoppede med VB6 for at promovere sit .NET
> omkring årtusindeskiftet.
> Wikipedia <http://en.wikipedia.org/wiki/Visual_Basic> siger
> ...
> The final release was version 6 in 1998. Microsoft's extended support ended
> in February 2008 and the designated successor was Visual Basic .NET.
> ...
>
> Det kan godt være det lyder lidt hårdt, men man har sådan set haft 10 år til
> at omlægge sit system.

Det kan godt være det lyder hårdt, men hvorfor i alverden skal man bruge
penge på at bygge noget om der faktisk virker? Det er jo DEN situation
Anders står i med kunderne - og i Jylland - som du ved - sidder pengene
ikke løst.

Desuden er VB.NET ikke bagudkompatibelt og det er DET der er alfa og
omega i den situation - hvor bøvlet er det at lægge om. Skal man
alligevel bygge en masse, er vi meget tæt på at skrotte VB og bruge en
langtidssikker teknologi.


>> Hvilket bringer os tilbage til closed source problematikken. Havde
>> Microsoft valgt at lave VB6 open source, ville disse programmer leve
>> evigt fordi man KUNNE holde skidtet i luften.
>
> Jeg kan godt lide din enthusiasme, men det er ikke VB6, der er problemet,
> det er garanteret Windows OS'et, der ikke er kompatibelt.

Tjah, hvis du ved hvad der er galt så tror jeg gerne Anders vil vide
det. Tænk hvis det nu var nemt at opgradere.

Iøvrigt er det ikke et spørgsmål om entusiasme, men almindelig
pragmatisme. Ønsker du at være helgarderet mht fremtidige rettelser,
skal du have adgang til hele platformen, inklusiv compiler og
operativsystem.

Se hvad der skete med OS/2 da IBM droppede det. Folk kæmpede længe, men
fordi programmerne - traditionelt fra Windowsverdenen - var EXEudgaver
uden kildetekst, visnede de.

Se hvad der skete med din verden da Borland holdt op med at supporte
Linux...


> Men hvis _Windows_ blev open source, så er det en helt anden snak.

Nu ikke naiv. Det skal Microsoft tvinges til.

>
>> Personligt er jeg dybt forundret over at der ikke er en bevægelse til at
>> indsamle penge til Wineprojektet simpelhten for at have et alternativ
>> til hvad nu Microsoft finder på der IKKE vil virke med et eller andet
>> meget vigtigt program.
>
> Jeg synes jeg så et eller andet sted, at wine er ret aggressiv p.t. og
> forventer at nå en release 1.0 snart.

Jaja, og det projekt har været igang de sidste 10-15 år. Dejligt det
nærmer sig.


>> Så kan virksomhed X ikke slå Java ihjel ved at købe det og lukke
>> butikken som Microsoft i praksis gjorde med Mono ved at lave
>> patentaftalen med Novell.
>
> Time will show.

Jamen, det KAN de ikke. GPL programmer er sikrede mod den slags, og det
er pt det eneste ikke-Microsoft teknologi der uændret kan køres på mange
platforme.

> På det område er IBM tilsyneladende i seng med MS, og Sun er 'fjenden'.

Firmaerne er pragmatiske. Det drejer sig om at tjene penge.


>
>> Det kommer den dag hvor din netbank kræver IE7 :)
>
> Jeg tror der er rigeligt fokus på Netbankernes manglende evner til at lave
> ordentlige systemer, så det tror jeg ikke kommer til at ske.

Lad os nu se. Det er før set der er sjove activex-krav.


> Hvis det sker går jeg ind og låner en af naboens PC'ere.

Så du vil gerne tiltro din nabo dine bankdata? Ok.

Personligt er jeg fint tilfreds med XP installeret og Windows2000 i vmware.
--
Thorbjørn Ravn Andersen "... plus... Tubular Bells!"

---

Thorbjørn Ravn Andersen wrote:

> Stig Johansen skrev den 19-05-2008 01:18:
>
> Sært. Eftersom det faldt sammen med en opgradering af kernesoftware...

Nej, ikke hvis man ved det, men det var først efter mange timer, jeg fik at
vide man havde opdateret MS SQLServer, om du så vil kalde det
kernesoftware.

I den slags organisationer, modtager man stakkevis af CD'ere med nyeste
software fra MS, og man opdaterer blindt hvad der kommer ind af døren.

Så IT chefen vidste ikke engang selv, at der var blevet opdateret.

> Så sagde du vel at det virkede på det det var solgt til, og at du ikke
> kunne gøre for at de ændrede på forudsætningerne? Så må det vel være
> "nedgrader og det virker som købt".

Hvis jeg opførte mig på den måde, kom jeg nok ikke der mere, så nej, det er
ikke min stil.

>> Det kan godt være det lyder lidt hårdt, men man har sådan set haft 10 år
>> til at omlægge sit system.
>
> Det kan godt være det lyder hårdt, men hvorfor i alverden skal man bruge
> penge på at bygge noget om der faktisk virker? Det er jo DEN situation
> Anders står i med kunderne - og i Jylland - som du ved - sidder pengene
> ikke løst.

Jeg ved ikke om Anders opererer i Jylland, men selvom jeg bor på Sjælland,
er det ikke ensbetydende med jeg er født på Sjælland ;)

> Desuden er VB.NET ikke bagudkompatibelt og det er DET der er alfa og
> omega i den situation - hvor bøvlet er det at lægge om.

Det ved jeg godt, og det er da også det der gør folk sure. Jeg har som sagt
undgået VB, men jeg hører at en omlægning til VB.NET er stort set en
omskrivning.
Ud over, at .NET kræver opgradering, kæmpe runtime, versionshelvede, lock-in
til Microsoft osv.
Men er det ikke netop det MS er ude efter?

> Skal man
> alligevel bygge en masse, er vi meget tæt på at skrotte VB

Pointen var, at Anders og hans firma burde have set lyset, og skrottet VB
allerede for 6-8 år siden.

> og bruge en langtidssikker teknologi.

Findes det?
Jeg ved godt du tror på Java, men hvordan er det gået med alle de 4 GL,
pcode ting, m.v. fra 80-90'erne.


> Tjah, hvis du ved hvad der er galt så tror jeg gerne Anders vil vide
> det. Tænk hvis det nu var nemt at opgradere.

Jeg ved ikke hvad der er galt, så havde jeg skrevet det.
Men simpel logik:
Som du selv skriver, så har vi et VB6 program der virker.
Hvis man flytter det selvsamme program over på en ny version af Windows, og
det ikke virker, kan det ikke være andet end at Windows ikke er
kompatibelt.

> Se hvad der skete med OS/2 da IBM droppede det. Folk kæmpede længe, men
> fordi programmerne - traditionelt fra Windowsverdenen - var EXEudgaver
> uden kildetekst, visnede de.

Her observerede jeg, at Chicago ( hmm.. var det det det hed), blev forsinket
i årevis, så den først udkom som Windows 95 - efter MS kom ud af aftalen om
udveksling af kildetekster med IBM.

Kom OS/2 nogensinde til at afvikle 32-bit's windowsprogrammer?

> Se hvad der skete med din verden da Borland holdt op med at supporte
> Linux...

Der er ikke sket noget med min verden. I den kommercielle verden bruger man
primært Windows til småservere, og det tror jeg man bliver ved med en lang
årrække endnu.
Linux satsningen fra Borlands side var et forsøg på at kunne levere
commercial strength kvalitet på Linux (Desktop), men som sagt så er der
ikke et marked for det, og kommer måske aldrig.

> Lad os nu se. Det er før set der er sjove activex-krav.

Ja, og et sandt virvar af jre versioner, men bankerne lærer vel også med
tiden.

>
>
>> Hvis det sker går jeg ind og låner en af naboens PC'ere.
>
> Så du vil gerne tiltro din nabo dine bankdata? Ok.

Jeg snakker om at låne en af deres PC'ere, ikke udlevere mine bankdata.

> Personligt er jeg fint tilfreds med XP installeret og Windows2000 i
> vmware.

Diverse Linux på diverse Wmware på diverse maskiner kører fantastisk fint
her, så jo Wmware styrer.

--
Med venlig hilsen
Stig Johansen

---

Stig Johansen wrote:
> Anders Wegge Jakobsen wrote:
>
>> Stig Johansen <wopr.dk@gmaill.com> writes:
>>> Derudover kommer følgespørgsmålet: Hvem skal jeg ringe til når det
>>> går ned?
>> Hvem ringer du til nu?
>
> Jeg er ikke sikker på jeg forstår denne her rigtigt, men for lige at
> præcisere:
> Der er upper management, der spørger _mig_ hvem de skal ringe til, ikke mig
> der spørger.
>

I Danmark kan de f.x. ringe til Liga eller måske superusers ?

/Martin

---

Anders Wegge Jakobsen skrev den 18-05-2008 19:08:

> Hvem ringer du til nu? Vi har for eksempel en kunde der har en 20-30
> arbejdsstationer der kører VB6. Har du et nummer vi kan ringe til, når
> vi skal have stadset til at køre på en XP, fordi vi ikke længere kan
> få noget hardware der er supporteret af NT 4.0?

Dagens ord: vmware, virtual pc, virtual box....

Letter backup, letter migrering.


>>> Been there, done that, set firmaet gå praktisk taget konkurs på et
>>> uovervejet skift til Windows som serverplatform :(
>
>> Forhåbentlig ikke de operationelle systemer?
>
> Jo.

Så kunne de lære det. Godt de overlevede alligevel.

--
Thorbjørn Ravn Andersen "... plus... Tubular Bells!"

---

---

Michael Rasmussen wrote:

> Har du set dette?
>
http://www.lazarus.freepascal.org/modules.php?op=modload&name=StaticPage&file=index&sURL=about

Ja, det er blevet diskuteret tit og ofte de sidste 5 års tid i Borland
grupperne.

Der er flere, der arbejder på crosscompiling via FPC, så man bruger Windows
til udvikling og 'efterkompilerer' på Linux.

Det er i princippet også det jeg gør med Commandline compileren fra Kylix.

Hvis man bare holder sig fra GUI på Linux, så virker det perfekt, og Kylix
har, i modsætning til FPC, indbygget XML/SOAP, tusindvis af mere eller
mindre frie 3. parts komponenter m.v.

Hvorvidt man må bruge Sourcen fra Kylix, til at kompilere med FPC en gang i
fremtiden, hvis det bliver aktuelt, bliver nok et legal issue.

--
Med venlig hilsen
Stig Johansen

---

---

Stig Johansen <wopr.dk@gmaill.com> writes:

> Hej gruppe.
>
> Som nævnt i subj - Findes der noget profiling tool til Linux?
>
> Det jeg er ude efter er et tool, der kan fortælle hvor jeg brænder CPU af.
>
> Situationen er, at jeg tilsyneladende, et eller andet sted, i en eller anden
> tråd har fået lavet et infinite loop - en gang imellem.
>
> Indtil videre, er det lidt på prototype stadiet, og jeg ved godt jeg skal
> have kigget min kode efter med lup, men hvis man kunne finde et hint, ville
> det være nemmere ;)

Du kan eventuelt se paa Sysprof:

http://www.daimi.au.dk/~sandmann/sysprof

Hvis Kylix genererer normale ELF-filer, burde den virke godt nok.

Det er noedvendigt at have kerne-headere installeret for at kunne
oversaette den.



Soren

---

Soeren Sandmann wrote:

> Du kan eventuelt se paa Sysprof:
>
> http://www.daimi.au.dk/~sandmann/sysprof

Det ser absolut brugbart ud, dog er jeg lidt i tvivl om X skal køre på
serveren, eller der er tale om et dump, der efterfølgende analyseres.

> Hvis Kylix genererer normale ELF-filer, burde den virke godt nok.

Det er normale ELF filer, men jfr. din Readme:
....
The X server as shipped by most distributions uses its own home-rolled
module loading system and Sysprof has no way to deal with that, so if you
run sysprof with your normal X serverr you won't get any information about
how time is spent inside the X server.
....

Jeg er rimelig sikker på Borland bruger sit eget loading system på et eller
andet plan.

I Delphi, og dermed Kylix, er der både en initialization section og en
finalization section.
Disse ting understøttes ikke at Linux, og jeg husker, at der var en masse
bøvl, hvor Borland forsøgte at få det ind som standard i Linux, men det
ville man ikke høre tale om.


--
Med venlig hilsen
Stig Johansen

---

Stig Johansen <wopr.dk@gmaill.com> writes:

> Soeren Sandmann wrote:
>
> > Du kan eventuelt se paa Sysprof:
> >
> > http://www.daimi.au.dk/~sandmann/sysprof
>
> Det ser absolut brugbart ud, dog er jeg lidt i tvivl om X skal køre på
> serveren, eller der er tale om et dump, der efterfølgende analysere.

Den sidste version (1.0.10) kraever X, men den virker fint nok hen
over fx ssh -Y, saa det vaerste krav er nok at gtk+ skal vaere
installeret. I svn-versionen er der en kommandolinjeversion som
genererer et dump der efterfoelgende kan analyseres.

> > Hvis Kylix genererer normale ELF-filer, burde den virke godt nok.
>
> Det er normale ELF filer, men jfr. din Readme:
> ...
> The X server as shipped by most distributions uses its own home-rolled
> module loading system and Sysprof has no way to deal with that, so if you
> run sysprof with your normal X serverr you won't get any information about
> how time is spent inside the X server.
> ...
>
> Jeg er rimelig sikker på Borland bruger sit eget loading system på et eller
> andet plan.

Hvis Kylix mmap()er filerne, saa burde det virke, ogsaa selv om de
indeholder ekstra Kylix-specifikke sektioner. Det som de gamle
X-servere gjorde var at indlaese en kopi i stedet for a bruge mmap(),
saa sysprof ikke kunne se dem i /proc/<pid>/maps. Bemaerkningen i
README er foraeldet nu, for X-serveren i alle nutidige distributioner
bruger mmap.

---

Soeren Sandmann wrote:

> Hvis Kylix mmap()er filerne, saa burde det virke, ogsaa selv om de
> indeholder ekstra Kylix-specifikke sektioner. Det som de gamle
> X-servere gjorde var at indlaese en kopi i stedet for a bruge mmap(),
> saa sysprof ikke kunne se dem i /proc/<pid>/maps. Bemaerkningen i
> README er foraeldet nu, for X-serveren i alle nutidige distributioner
> bruger mmap.

Det må jeg lige prøve at se på (hvis jeg kan finde ud af det).

Jeg bruger bare de indbyggede 'loadlibrary' og 'getprocaddress', men der
følger en mulliard linier source med, så jeg prøver at se om jeg kan finde
ud af hvad det lander i 'behind the scene'.

--
Med venlig hilsen
Stig Johansen

---

Soeren Sandmann wrote:

> Stig Johansen <wopr.dk@gmaill.com> writes:
>
>> Jeg er rimelig sikker på Borland bruger sit eget loading system på et
>> eller andet plan.
>
> Hvis Kylix mmap()er filerne, saa burde det virke, ogsaa selv om de
> indeholder ekstra Kylix-specifikke sektioner.

Nu har jeg kigget ned gennem de underliggende kildetekster, og på Linux
mappes der direkte til
dlopen,dlsym samt dlclose.

Så vidt jeg kan forstå på Google, så mmap'er dlopen selv filerne.

Jeg har også kigget på denne her:
<http://linux.die.net/man/5/proc>

og fundet ud af, at hver thread (eller task) har sit eget subdir
i /proc/<pid>/task

Så hvis 'problemet' opstår igen, en dag - om en uge eller aldrig? - Starter
jeg med at se hvad jeg kan udlede deraf.

Du skal i hvert fald have tak for at have ledt mig på rette vej.

--
Med venlig hilsen
Stig Johansen

---

---

Michael Rasmussen wrote:

> On Mon, 19 May 2008 15:28:46 +0200
> Stig Johansen <wopr.dk@gmaill.com> wrote:
>
>>
>> - Og vi snakker NPTL threads, som _ikke_ har selvstændige pid'er.
>>
> Det er ikke korrekt. NPTL adskiller sig netop fra linker library tråde
> ved, at kernen tildeler hver enkelt tråd sin egen PID, men har fælles
> PPID - dog i kerneland.

Det har jeg lige fundet ud af - tror jeg nok.
(Se mit svar til Soeren)

Jeg har nok blandet noget sammen fordi jeg ikke kan se de enkelte ID'er i
hhv. top og ps.

Men jeg har opdaget /proc/<pid>/task, så det gør mig glad.


> library tråde udmærker sig ved, at de er portable, da det ikke kræver
> understøttelse for tråde i kernen, men den store ulempe er så, at alle
> tråde deler samme PID, hvorfor en hængende tråd vil få hele
> applikationen til at hænge, da kernen ikke kan intervenere mod den
> enkelte tråd.

He - det har jeg opdaget.
Jeg havde en situation hvor hele skidtet hang om søndagen, men kun om
søndagen.

Årsag? 'Idioten' havde defineret et array [0..6] og brugte [1..7] - eller
også var det omvendt.

Så jo, jeg kan bekræfte, at unhandled exceptions låser det _hele_.

Det er dog ikke tilfældet her, da alt virker, og ingen synlige
svartidsproblemer.

Jeg opdager det først hvis lige kigger med en top, men det er ikke hver dag.

Jeg fandt ud af i går, at jeg havde glemt at leve index på nogle tabeller i
SQLite, så der var laaang svartid ( = et par minutter).

Der foreligger også den mulighed, at jeg tilfældigvis kiggede på top mens
der var sådan en i gang.

--
Med venlig hilsen
Stig Johansen

---

Stig Johansen skrev den 19-05-2008 18:43:

> Jeg havde en situation hvor hele skidtet hang om søndagen, men kun om
> søndagen.
>
> Årsag? 'Idioten' havde defineret et array [0..6] og brugte [1..7] - eller
> også var det omvendt.
>
> Så jo, jeg kan bekræfte, at unhandled exceptions låser det _hele_.

Så nu har du en global exception handler der lukker pænt ned hvis der
sker noget uventet? Man lærer af den slags :) Been there, done that.



--
Thorbjørn Ravn Andersen "... plus... Tubular Bells!"

---

Thorbjørn Ravn Andersen wrote:

> Stig Johansen skrev den 19-05-2008 18:43:
>> Så jo, jeg kan bekræfte, at unhandled exceptions låser det _hele_.
>
> Så nu har du en global exception handler der lukker pænt ned hvis der
> sker noget uventet? Man lærer af den slags :) Been there, done that.

Nej - exceptions er noget fanden har skabt i sin vrede.
Tværtimod, så fjerner jeg dem (i det omfang, det kan lade sig gøre), og
laver det om til statuskoder, så man kan lave _ordentlige_ bail-out
procedurer.

--
Med venlig hilsen
Stig Johansen

---

Stig Johansen skrev den 19-05-2008 22:34:

> Nej - exceptions er noget fanden har skabt i sin vrede.
> Tværtimod, så fjerner jeg dem (i det omfang, det kan lade sig gøre), og
> laver det om til statuskoder, så man kan lave _ordentlige_ bail-out
> procedurer.

Det lyder det som om vi godt kunne få noget tid til at gå med at
diskutere. Det tror jeg dog ikke jeg gider. Jeg vil blot konstatere
at Exceptions som de er i Java, giver mulighed for at skille
programlogik fra fejlhåndtering, hvilket potentielt gør programmerne
lettere at vedligeholde.

Uanset hvad, er det et stort plus at man ikke skal lave sammensyltede
returværdier - "hvis det er negativt er det en fejlkode, ellers er det
et resultat", samt at man kan sende kontekst med op. Et detaljeret
stack trace med indlejrede exceptions er et fantastisk
fejlfindingsværktøj (hvis fejlene er sket der hvor exceptions er smidt)
som kan afhjælpe en del inden det er nødvendigt at få en debugger på.

Det kræver naturligvis at der er fejl i ens program, så det er en lille
krølle som ikke alle kan leve op til.

--
Thorbjørn Ravn Andersen "... plus... Tubular Bells!"

---

Thorbjørn Ravn Andersen wrote:

> Stig Johansen skrev den 19-05-2008 22:34:
>
>> Nej - exceptions er noget fanden har skabt i sin vrede.
>> Tværtimod, så fjerner jeg dem (i det omfang, det kan lade sig gøre), og
>> laver det om til statuskoder, så man kan lave _ordentlige_ bail-out
>> procedurer.
>
> Det lyder det som om vi godt kunne få noget tid til at gå med at
> diskutere. Det tror jeg dog ikke jeg gider.

Øv - øv, det var ellers en provokation.

> Jeg vil blot konstatere
> at Exceptions som de er i Java, giver mulighed for at skille
> programlogik fra fejlhåndtering, hvilket potentielt gør programmerne
> lettere at vedligeholde.

Der er ikke nogen forskel på Java og Delphi.
Jeg kan skrive
try
do en masse
except
do something
finally
clean up
end.

Det hedder vist bare catch i Java.

Og selvfølgelig bruger jeg dem der hvor de skal/kan bruges.
Jeg er bare lidt irriteret over det, som jeg vil kalde misbrug.

Et eksempel:
Jeg oprerer bla. med nogle HTTP requests.
I det undeliggende komponent er der f.eks.
if status <> 200 then
raiseerror noget ; <-- afslutter her
.....

Med den konstruktion skal jeg så bruge:
try
doHTTP
.....
except
noget..
end;

Det laver jeg så, igen eksempelvis, om til
if status <> 200 then exit;

Og i hovedprogrammet:
if doHTTP = 200 then begin
...........
end else
noget;

Sparet ?

Adskillige object creations og destructions, der koster performance + memory
fragmentation.

> Uanset hvad, er det et stort plus at man ikke skal lave sammensyltede
> returværdier - "hvis det er negativt er det en fejlkode, ellers er det
> et resultat", samt at man kan sende kontekst med op.

Igen en provokation, den er fin til en bruger, der kan læse og forstå, og
trykke ja/nej, osv.

Men hvis vi snakker baggrunds/batch/transaction processing, så er man nødt
til at 'rulle baglæns', aka bail-out, og rydde op i de foranstående.

> Et detaljeret
> stack trace med indlejrede exceptions er et fantastisk
> fejlfindingsværktøj (hvis fejlene er sket der hvor exceptions er smidt)
> som kan afhjælpe en del inden det er nødvendigt at få en debugger på.

Delphi er sådan indrettet, at man udvikler, tester, og evt. debugger i een
forretningsgang.

> Det kræver naturligvis at der er fejl i ens program, så det er en lille
> krølle som ikke alle kan leve op til.

Præcis.

--
Med venlig hilsen
Stig Johansen

---

Stig Johansen skrev den 19-05-2008 23:33:

>> Uanset hvad, er det et stort plus at man ikke skal lave sammensyltede
>> returværdier - "hvis det er negativt er det en fejlkode, ellers er det
>> et resultat", samt at man kan sende kontekst med op.
>
> Igen en provokation, den er fin til en bruger, der kan læse og forstå, og
> trykke ja/nej, osv.

Det var nu ikke tænkt som en provokation. Bare en forklaring - hvis du
har noget der returnerer en Person (et objekt) og der går noget galt
hvad vil du så returnere som fejlkode?

"null" siger bare AT der var en fejl, og ikke hvad, så det er noget hø.
Så kan du lave særlige fejlobjekter der har speciel betydning
(Personen "Anders And" betyder at filen ikke kunne slettes) og så
begynder det først at blive rigtigt grimt.


>> Et detaljeret
>> stack trace med indlejrede exceptions er et fantastisk
>> fejlfindingsværktøj (hvis fejlene er sket der hvor exceptions er smidt)
>> som kan afhjælpe en del inden det er nødvendigt at få en debugger på.
>
> Delphi er sådan indrettet, at man udvikler, tester, og evt. debugger i een
> forretningsgang.

Du misforstår. Jeg snakker om at kunder ringer og siger at skidtet gav
fejl kl 12:15 i går, og at de var nødt til at genstarte, og at det skal
du lige fikse.

Er vi ikke enige om at det her er noget der skal bruges af andre?


--
Thorbjørn Ravn Andersen "... plus... Tubular Bells!"

---

Thorbjørn Ravn Andersen wrote:

> Stig Johansen skrev den 19-05-2008 23:33:
>
>>> Uanset hvad, er det et stort plus at man ikke skal lave sammensyltede
>>> returværdier - "hvis det er negativt er det en fejlkode, ellers er det
>>> et resultat", samt at man kan sende kontekst med op.
>>
>> Igen en provokation, den er fin til en bruger, der kan læse og forstå, og
>> trykke ja/nej, osv.
>
> Det var nu ikke tænkt som en provokation.

Nej, det var en provokation fra min side, for jeg synes folk tænker for
snævertsynet.

> Bare en forklaring - hvis du
> har noget der returnerer en Person (et objekt) og der går noget galt
> hvad vil du så returnere som fejlkode?

Det kommer an på hvad der går galt.
Hvis vi antager jeg har en person a la.
Tperson = class(enellerandenclass)
private
name : string
cprnr : tcprnr
...osv
public
diverse properties
end.

Så vil jeg lave
try
tperson.create(maybe.some.initial.values)
except on e:personexception do
result := min.lede.tekst + e.message
end;

Det vil returnere den ledetekst jeg selv vælger samt den systemgenerede
exception.

Er det derimod udfyldte/forkerte felter vil jeg give en sigende fejl og
årsag, og ikke raise en exception.
Hvis et postnummer ikke findes i postnummer tabellen, er der ingen grund til
at præsentere et stacktrace for brugerne.

Stacktrace blive nu heller ikke genereret, det er noget der hører til
'fortolkerveredenen'.

Nu vi er ved objekter, så kan jeg fortælle at nutidens Delphi frem for
turbopascal for 15 år siden, varetager al memory allokering og deallokering
automatisk, der er ikke brug for noget med getmem,freemem,new,dispose siden
midt 90'erne.

Den eneste manuelle allokering er den ovenfor viste udtagning af et objekt.
Og som følge deraf skal man huske til sidst at frigive objektet med:
tperson.free

Det er det ene lille statement, man kan spare ved at indføre garbage
collection. Min personlige indstilling er, at hvis man ikke kan huske at
frigive de objekter man selv har kreeret, så skal man _slet_ ikke være
programmør.
Hvis man ikke kan styre det, hvordan kan man så styre programmering af
banktransktioner,værdipapirhandel,ejendomshandel ?

>>> Et detaljeret
>>> stack trace med indlejrede exceptions er et fantastisk
>>> fejlfindingsværktøj (hvis fejlene er sket der hvor exceptions er smidt)
>>> som kan afhjælpe en del inden det er nødvendigt at få en debugger på.

Som nævnt findes der ikke stracktrace i native codede programmer.
Der en en hel gruppe mennesker, der næsten har viet deres liv til at
optimere memory manageren.
Det er også blevet til en noget hurtigere en, også med indbygget stacktrace.
Men der er rimelig meget assembler indbygget, så den venter jeg lidt med at
afprøve. Den er trods alt kun kvalitets sikret på Windows.


> Du misforstår. Jeg snakker om at kunder ringer og siger at skidtet gav
> fejl kl 12:15 i går, og at de var nødt til at genstarte, og at det skal
> du lige fikse.

Af de flere 1000 programmer jeg har lavet gennem tiderne, har der ikke været
behov for genstart.

> Er vi ikke enige om at det her er noget der skal bruges af andre?

Det er et godt spørgsmål. Jeg er muligvis ude på dybt vand, og så må vi se
om man kan svømme.

Kardinalpunktet er brugen af SQLite.
Hvis du kigge på SQLite's side efter multithreading capabilities, skriver
de:
Threads are evil, _avoid_ them.
Og hvis du søger på Google efter SQLite og 'Database locked' sidder jeg i
samme situation som dig.
1000 vis af _problemer_ men ingen _løsninger_.

Hvis det ender med jeg bliver nødt til at serialisere SQLite, falder hele
skidtet til jorden.

Indtil videre har jeg, som vistnok nævnt, sat SQLite op til at bruge memory
som temp store.

Den kan jeg sætte til disk i stedet for, men jeg vil jo grumme gerne vide
hvad der sker når tingene løber tør for ressourcer.

--
Med venlig hilsen
Stig Johansen

---

Stig Johansen skrev den 20-05-2008 08:24:

> Nej, det var en provokation fra min side, for jeg synes folk tænker for
> snævertsynet.

Det er så din holdning - det er jeg ikke enig med dig i.

>> Bare en forklaring - hvis du
>> har noget der returnerer en Person (et objekt) og der går noget galt
>> hvad vil du så returnere som fejlkode?
>
> Det kommer an på hvad der går galt.
> Hvis vi antager jeg har en person a la.
> Tperson = class(enellerandenclass)
> private
> name : string
> cprnr : tcprnr
> ..osv
> public
> diverse properties
> end.
>
> Så vil jeg lave
> try
> tperson.create(maybe.some.initial.values)
> except on e:personexception do
> result := min.lede.tekst + e.message
> end;
>
> Det vil returnere den ledetekst jeg selv vælger samt den systemgenerede
> exception.

Du har vist ikke helt forstået hvad jeg mener

Lad os sige vi har en prograstump

   Person person = lookupPerson(String name)

hvor lookupPerson returnerer en _person_ (objekt, ikke streng) til
viderbehandling. Lad os sige at den slår den op i en database, og at
denne database melder fejl fordi du har et tegn i dit navn som
databasedriveren ikke kan lide (hvis det er et unicodetegn der ikke kan
foldes ned i databasens tegnsæt).

Hvordan vil du håndtere den fejlsituation?

Hvordan håndterer du hvis der er en division-med-nul-fejl i den rutine
der genererer din SQL - igen i ovenstående?

> Er det derimod udfyldte/forkerte felter vil jeg give en sigende fejl og
> årsag, og ikke raise en exception.

Naturligvis ikke. Exceptions er til at håndtere fejlsituationer uden at
skulle have en if/case-struktur efter hvert kald, ikke almindeligt
programflow (hvilket validering er).


> Hvis et postnummer ikke findes i postnummer tabellen, er der ingen grund til
> at præsentere et stacktrace for brugerne.
>
> Stacktrace blive nu heller ikke genereret, det er noget der hører til
> 'fortolkerveredenen'.

Mnjah, alle debuggere jeg kender kan levere et stacktrace af en kørende
process.

> Det er det ene lille statement, man kan spare ved at indføre garbage
> collection. Min personlige indstilling er, at hvis man ikke kan huske at
> frigive de objekter man selv har kreeret, så skal man _slet_ ikke være
> programmør.

Tjah, ting har det jo med at blive sværere at overskue når de bliver store.

Hvad er de helt store fejlkilder i Delphi-programmering? I C er det
pointergymnastik og hukommelsesstyring.

> Hvis man ikke kan styre det, hvordan kan man så styre programmering af
> banktransktioner,værdipapirhandel,ejendomshandel ?

Det er meget enkelt. Man bruger sprog uden objekter. Prøv du at
spørge din bank hvad der kører deres transaktioner - ikke alle
webtingene eller sådan - den rå "flyt penge rundt" del.

> Det er også blevet til en noget hurtigere en, også med indbygget stacktrace.
> Men der er rimelig meget assembler indbygget, så den venter jeg lidt med at
> afprøve. Den er trods alt kun kvalitets sikret på Windows.

Jeg tror desværre du må indse at Kylix er et dødt produkt og at Linux
derfor ikke er en god platform for Delphi-programmører.


>> Du misforstår. Jeg snakker om at kunder ringer og siger at skidtet gav
>> fejl kl 12:15 i går, og at de var nødt til at genstarte, og at det skal
>> du lige fikse.
>
> Af de flere 1000 programmer jeg har lavet gennem tiderne, har der ikke været
> behov for genstart.

Fint. Så siger vi bare at der var en fejl kl 12:15 i går og det skal du
fikse. Hvordan griber du det an? (Jeg spørger af nysgerrighed,
personligt er indfaldsvinklen at den nødvendige information skal stå i
logfilen).


> Hvis du kigge på SQLite's side efter multithreading capabilities, skriver
> de:
> Threads are evil, _avoid_ them.
> Og hvis du søger på Google efter SQLite og 'Database locked' sidder jeg i
> samme situation som dig.
> 1000 vis af _problemer_ men ingen _løsninger_.

Så har du valgt forkert teknologi. Tillad mig at anbefale at du finder
en teknologi der er egnet til det du vil.

--
Thorbjørn Ravn Andersen "... plus... Tubular Bells!"

---

Thorbjørn Ravn Andersen wrote:

> Stig Johansen skrev den 20-05-2008 08:24:
>
>> Nej, det var en provokation fra min side, for jeg synes folk tænker for
>> snævertsynet.
>
> Det er så din holdning - det er jeg ikke enig med dig i.
>
>>> Bare en forklaring - hvis du
>>> har noget der returnerer en Person (et objekt) og der går noget galt
>>> hvad vil du så returnere som fejlkode?
>>
>> Det kommer an på hvad der går galt.
>> Hvis vi antager jeg har en person a la.
>> Tperson = class(enellerandenclass)
>> private
>> name : string
>> cprnr : tcprnr
>> ..osv
>> public
>> diverse properties
>> end.
>>
>> Så vil jeg lave
>> try
>> tperson.create(maybe.some.initial.values)
>> except on e:personexception do
>> result := min.lede.tekst + e.message
>> end;
>>
>> Det vil returnere den ledetekst jeg selv vælger samt den systemgenerede
>> exception.
>
> Du har vist ikke helt forstået hvad jeg mener
>
> Lad os sige vi har en prograstump
>
> Person person = lookupPerson(String name)
>
> hvor lookupPerson returnerer en _person_ (objekt, ikke streng) til
> viderbehandling.

Nu var det pseudokode jeg skrev, i virkeligheden er det
person := Tperson.Create(maybe.some.initial.values)
Hvor person er det returnerede objekt.
Vi kan også kalde den person := TLookupperson.Create(name).
Men normalt ville jeg lægge lookupdelen som en metode i under
personobjektet, og ikke et selvstændigt nedarvet objekt.

> Lad os sige at den slår den op i en database, og at
> denne database melder fejl fordi du har et tegn i dit navn som
> databasedriveren ikke kan lide (hvis det er et unicodetegn der ikke kan
> foldes ned i databasens tegnsæt).

Det er jo en decideret _designfejl_ hvis det skulle kunne opstå.
Det er en ommer.

> Hvordan vil du håndtere den fejlsituation?

Nu ved jeg ikke hvordan den skulle kunne opstå, men jeg ville skamme mig
over at have begået sådan en brøler.

>
> Hvordan håndterer du hvis der er en division-med-nul-fejl i den rutine
> der genererer din SQL - igen i ovenstående?
>
>> Er det derimod udfyldte/forkerte felter vil jeg give en sigende fejl og
>> årsag, og ikke raise en exception.
>
> Naturligvis ikke. Exceptions er til at håndtere fejlsituationer uden at
> skulle have en if/case-struktur efter hvert kald, ikke almindeligt
> programflow (hvilket validering er).

Uden at udtale mig for eller imod patenter, så ligger det sådan at Borland
har noget patent på Exception handling.
Det siger lidt om vi godt ved hvad exception handling er, og at vi har haft
det siden midt 90'erne.

>> Hvis et postnummer ikke findes i postnummer tabellen, er der ingen grund
>> til at præsentere et stacktrace for brugerne.
>>
>> Stacktrace blive nu heller ikke genereret, det er noget der hører til
>> 'fortolkerveredenen'.
>
> Mnjah, alle debuggere jeg kender kan levere et stacktrace af en kørende
> process.

Ok, det gør jeg så ikke. Normalt fjerner man debug info m.v. når men
levererer et production ready - fejlfrit - system.

> Tjah, ting har det jo med at blive sværere at overskue når de bliver
> store.

Definer 'store'.
Det er klart, hvis man arbejder ustruktureret, og ikke evner at udskille
ting i passende størrelser af funktioner, procedurer eller objekter, så
mister man overblikket.
Men så er det fordi man ikke kan sit fag.

> Hvad er de helt store fejlkilder i Delphi-programmering?

Ingen - ud over fejl 40.
Ok, selvfølgelig memoryleaks hvis man ikke husker at frigive sine udtagne
objekter, men den klassificerer jeg som fejl 40.

> I C er det
> pointergymnastik og hukommelsesstyring.

I know - også hvad der sker ved missing trailing #0.

>> Hvis man ikke kan styre det, hvordan kan man så styre programmering af
>> banktransktioner,værdipapirhandel,ejendomshandel ?
>
> Det er meget enkelt. Man bruger sprog uden objekter. Prøv du at
> spørge din bank hvad der kører deres transaktioner - ikke alle
> webtingene eller sådan - den rå "flyt penge rundt" del.

He - det var et hint - det er ikke umuligt, at den gamle også har kodet
netop disse ting

>> Det er også blevet til en noget hurtigere en, også med indbygget
>> stacktrace. Men der er rimelig meget assembler indbygget, så den venter
>> jeg lidt med at afprøve. Den er trods alt kun kvalitets sikret på
>> Windows.
>
> Jeg tror desværre du må indse at Kylix er et dødt produkt og at Linux
> derfor ikke er en god platform for Delphi-programmører.

Måske, måske ikke.
Essensen er den samme som du selv var inde på.
Ved at porte Delphi til Linux, har man automatisk adgang til de millioner og
atter millioner af applikationer og komponenter 'out there'.

Hvis Linux nogensinde vinder indpas på arbejdspladser skal det nok komme.
Men det er Linux, altså ikke kernen her, men applikationerne, der skuffer
mig.
Den lavthængende frugt for at komme ind på arbejdspladser er et substitut
for Exchange og Outlook.
Før det problem er løst, kommer Linux ikke på arbejdspladser, heller ikke
inden for det offentlige.

Men mht. til mit projekt, skal du huske, som jeg skrev, at det kører ligeså
godt(dog ikke lige så hurtigt) som en windows service.

Min eneste Linux 'satsning' er nogle få 100 linier kode i hovedprogrammet,
der afgør om det er en Linux Daemon eller en Windows service, resten af
units/komponenter er fælles.

Det der er interessant nu er NPTL threads, som nu faktisk virker.
Med den gamle threading model var windows versionen faktisk hurtigere en
Linux.

Men som du (måske) så andetsteds, så er NPTL threads absolut ikke for
amatører. En enkelt fejl river hele processen ned, og ikke bare den enkelte
tråd.

> Fint. Så siger vi bare at der var en fejl kl 12:15 i går og det skal du
> fikse. Hvordan griber du det an? (Jeg spørger af nysgerrighed,
> personligt er indfaldsvinklen at den nødvendige information skal stå i
> logfilen).

Du må sætte en referenceramme for sådan et spørgsmål.
Snakker vi web-systemer, banksystemer, produktionsstyrings systemer,
administrative systemer eller ?
De fleste ting jeg har lavet er mission critical, der der ringer telefonen i
samme øjeblik der skulle ske en fejl.

Hvis der derimod er tale om posteringer på en fejlkonto som følge af
forkerte koder, så laver jeg tingene, så brugerne i videst muligt omfang
selv kan udrede koderne og korrigere regnskabs data.

Fejl og logfiler?
Jeg gør meget ud af at lave forskellige, og sigende fejlmeldinger, så
1) Brugeren for en sigende fejlmelding og
2) Jeg ved stort set på linienummer hvor i koden fejlen opstår.
Så ja vi er enige, at spare på informationer i logfilen er at skyde foden af
sig selv - på sigt.

>> Hvis du kigge på SQLite's side efter multithreading capabilities, skriver
>> de:
>> Threads are evil, _avoid_ them.
>> Og hvis du søger på Google efter SQLite og 'Database locked' sidder jeg i
>> samme situation som dig.
>> 1000 vis af _problemer_ men ingen _løsninger_.
>
> Så har du valgt forkert teknologi. Tillad mig at anbefale at du finder
> en teknologi der er egnet til det du vil.

Jeg startede med at spørge vennerne ovre i Borland grupperne efter mulige
emner til embedded database.

Det eneste alternativ er så vidt jeg forstod firebird embedded. Men der ved
jeg af erfaring, at der er(var) 'severe problems' med mutithreading.

Det her - måske forsøg - går ud på at spare _ressourcer_, ikke at få tingene
til at fungere, det gør det i forvejen på MS SQLServer,Oracle,SapDB (nu
MaxDB), en DB/2 havde jeg vist nok også oppe at køre på et tidspunkt.
Men prøv lige at spørge hvor mange IT folk, der kan administrere en SapDB.

Java - undskyld, men jeg bliver nødt til lige at klippe noget over fra et
dugfrisk indlæg fra en Borland gruppe.
<citat>
> I have compared the speed of my code to that of other similar softwares
> (some of which written in C++) and mine is much faster (more than 4 times
> against C++ applications while more than 25 times against a Java
> application).
</citat>

--
Med venlig hilsen
Stig Johansen

---

Stig Johansen skrev den 20-05-2008 23:32:

>> Lad os sige at den slår den op i en database, og at
>> denne database melder fejl fordi du har et tegn i dit navn som
>> databasedriveren ikke kan lide (hvis det er et unicodetegn der ikke kan
>> foldes ned i databasens tegnsæt).
>
> Det er jo en decideret _designfejl_ hvis det skulle kunne opstå.
> Det er en ommer.

Hvorfor det? Det er før set at fx Oracle kan sættes op til 8-bit tegn
som fx ISO-Latin-1. Kommer man så med ISO-Latin-2 så har vi balladen.


>> Hvordan vil du håndtere den fejlsituation?
>
> Nu ved jeg ikke hvordan den skulle kunne opstå, men jeg ville skamme mig
> over at have begået sådan en brøler.

Læs ovenfor, og prøv så at svare. Det er faktisk ikke alle fejl der er
gigantiske designbrølere.


>> Hvordan håndterer du hvis der er en division-med-nul-fejl i den rutine
>> der genererer din SQL - igen i ovenstående?

Den svarede du heller ikke på :(



>>
>>> Er det derimod udfyldte/forkerte felter vil jeg give en sigende fejl og
>>> årsag, og ikke raise en exception.
>> Naturligvis ikke. Exceptions er til at håndtere fejlsituationer uden at
>> skulle have en if/case-struktur efter hvert kald, ikke almindeligt
>> programflow (hvilket validering er).
>
> Uden at udtale mig for eller imod patenter, så ligger det sådan at Borland
> har noget patent på Exception handling.
> Det siger lidt om vi godt ved hvad exception handling er, og at vi har haft
> det siden midt 90'erne.

Jamen, det er da fint at du ved hvad exception handling er, men jeg vil
gerne vide hvordan du håndterer tingene i praksis.

>> Mnjah, alle debuggere jeg kender kan levere et stacktrace af en kørende
>> process.
>
> Ok, det gør jeg så ikke. Normalt fjerner man debug info m.v. når men
> levererer et production ready - fejlfrit - system.

Derfor kan man alligevel godt få et stacktrace. Bare spørg Linus
Thorvalds :)


>> Tjah, ting har det jo med at blive sværere at overskue når de bliver
>> store.
>
> Definer 'store'.

Det er individuelt fra person til person.


> Det er klart, hvis man arbejder ustruktureret, og ikke evner at udskille
> ting i passende størrelser af funktioner, procedurer eller objekter, så
> mister man overblikket.
> Men så er det fordi man ikke kan sit fag.

Jeg savner stadig at få at vide hvordan du vil lave en "returnér
objekt"-metode som også kan returnere en fejlkode.


>>> Hvis man ikke kan styre det, hvordan kan man så styre programmering af
>>> banktransktioner,værdipapirhandel,ejendomshandel ?
>> Det er meget enkelt. Man bruger sprog uden objekter. Prøv du at
>> spørge din bank hvad der kører deres transaktioner - ikke alle
>> webtingene eller sådan - den rå "flyt penge rundt" del.
>
> He - det var et hint - det er ikke umuligt, at den gamle også har kodet
> netop disse ting

Som du måske efterhånden har opdaget, så er antydninger spildt på mig.
Vil du sige noget, så sig det.


>> Jeg tror desværre du må indse at Kylix er et dødt produkt og at Linux
>> derfor ikke er en god platform for Delphi-programmører.
>
> Måske, måske ikke.

Lad os se om 10 år.

>> Fint. Så siger vi bare at der var en fejl kl 12:15 i går og det skal du
>> fikse. Hvordan griber du det an? (Jeg spørger af nysgerrighed,
>> personligt er indfaldsvinklen at den nødvendige information skal stå i
>> logfilen).
>
> Du må sætte en referenceramme for sådan et spørgsmål.
> Snakker vi web-systemer, banksystemer, produktionsstyrings systemer,
> administrative systemer eller ?
> De fleste ting jeg har lavet er mission critical, der der ringer telefonen i
> samme øjeblik der skulle ske en fejl.

Lad os bare sige et websystem. Mission critical, det lyder interessant.

> Hvis der derimod er tale om posteringer på en fejlkonto som følge af
> forkerte koder, så laver jeg tingene, så brugerne i videst muligt omfang
> selv kan udrede koderne og korrigere regnskabs data.
>
> Fejl og logfiler?
> Jeg gør meget ud af at lave forskellige, og sigende fejlmeldinger, så
> 1) Brugeren for en sigende fejlmelding og
> 2) Jeg ved stort set på linienummer hvor i koden fejlen opstår.

Så det du egentlig gør, er at lave en kode i din fejlmelding som
fortæller hvor den stammer fra? Et enlinies stacktrace :))

Jeg går ud fra at du også håndtere flersprogsproblematikken i disse
fejlmeldinger?

>> Så har du valgt forkert teknologi. Tillad mig at anbefale at du finder
>> en teknologi der er egnet til det du vil.
>
> Jeg startede med at spørge vennerne ovre i Borland grupperne efter mulige
> emner til embedded database.
>
> Det eneste alternativ er så vidt jeg forstod firebird embedded. Men der ved
> jeg af erfaring, at der er(var) 'severe problems' med mutithreading.

Spøjst. Så er det måske et forkert programmeringssprog du har valgt?
Til Java er der Apache Derby, den skulle vist være ok til det meste.

> <citat>
>> I have compared the speed of my code to that of other similar softwares
>> (some of which written in C++) and mine is much faster (more than 4 times
>> against C++ applications while more than 25 times against a Java
>> application).
> </citat>

Benchmarking er en kunst i sig selv. De fleste JVM'er er tæskelangsomme
til at komme i luften, og gevinsten kommer først når de har kørt et
stykke tid. Hjemmelavede benchmarks tager sjældent højde for den slags.

Bemærk venligst at jeg ikke synes det er en dårlig ide at lave
Delphi-programmer. Det må du selv rode med :)


--
Thorbjørn Ravn Andersen "... plus... Tubular Bells!"

---

Thorbjørn Ravn Andersen wrote:

> Stig Johansen skrev den 20-05-2008 23:32:
>> Det er jo en decideret _designfejl_ hvis det skulle kunne opstå.
>> Det er en ommer.
>
> Hvorfor det? Det er før set at fx Oracle kan sættes op til 8-bit tegn
> som fx ISO-Latin-1. Kommer man så med ISO-Latin-2 så har vi balladen.

Designfejl = manglende inputvalidering/håndtering af tegnsæt.
Det samme sker i øvrigt på MS SQLServer hvis man ikke har styr på tingene.

> Læs ovenfor, og prøv så at svare. Det er faktisk ikke alle fejl der er
> gigantiske designbrølere.

Hvis jeg skal prøve at svare, så må du fortælle hvordan et forkert tegnsæt
er sluppet helt ind til database layeren.

>>> Hvordan håndterer du hvis der er en division-med-nul-fejl i den rutine
>>> der genererer din SQL - igen i ovenstående?
>
> Den svarede du heller ikke på :(

Det er fordi jeg ikke har division by zero nogle steder, så der er ikke
noget at svare på.
Jeg kontrollerer altid for 0 værdier på divisorer, så det sker ikke.

Skulle jeg have overset en, og der sker fejl, afhænger det af hvad det er
for noget.

Jeg snakker programmering generelt, og ikke Delphi.
Fejlhåndtering er _noget_ anderledes i COBOL end det er i Delphi/Java.

> Jamen, det er da fint at du ved hvad exception handling er, men jeg vil
> gerne vide hvordan du håndterer tingene i praksis.

Formentlig på samme måde som du ville gøre det i Java.
Jeg har ikke noget entydigt svar, det afhænger af systemet.
Hvis det er et ukritisk klient program til Windows, kan jeg godt finde på at
bruge den dovne metode med bare at smide en exception ud til brugeren.

Er det en windows service, hvor der ikke er nogen desktop at interagere med,
dur den selvfølgelig ikke, der hænger skidtet bare.

Hvis det er en fejl, der returneres fra en webservice (500), må man blader
gennem SOAP bodyen (hvis den overhovedet returneres) og håbe på der er
noget sigende der.

og så videre..., altså ikke en universel praksis, men afhængig af de enkelte
systemer.

> Derfor kan man alligevel godt få et stacktrace. Bare spørg Linus
> Thorvalds :)

Er vi ikke ved at være lidt ude i ordkløveri her.
Formentlig kan man få en stacktrace, men uden debug info, er det ikke ret
meget værd.

>> Definer 'store'.
>
> Det er individuelt fra person til person.

Netop, og der må svaret være, at hvis der er for 'stort' til man kan
overskue det, bør man nok finde/sættes til nogle mindre opgaver.

>> Det er klart, hvis man arbejder ustruktureret, og ikke evner at udskille
>> ting i passende størrelser af funktioner, procedurer eller objekter, så
>> mister man overblikket.
>> Men så er det fordi man ikke kan sit fag.
>
> Jeg savner stadig at få at vide hvordan du vil lave en "returnér
> objekt"-metode som også kan returnere en fejlkode.

Det kommer lidt an på hvad du mener.
Det virker som du forventer jeg vil lave tingene som du vel have det, og som
jeg gør.
Men hvis jeg skulle indføre en statuskode i dit eksempel, så er det bare at
udvide klassen med en kode.
Så under public sektionen ville jeg tilføje:
enten
Property Returnstatus : integer read fReturnstatus write fReturnstatus //
simpel porperty
eller
Property Returnstatus : integer read GetReturnstatus write SetReturnstatus

Propertien kan man så sætte under create, hvis det er det man vil.

> Som du måske efterhånden har opdaget, så er antydninger spildt på mig.
> Vil du sige noget, så sig det.

Det var nu ikke en antydning til dig.
Det var et hint om, at ikke alt er objektorienteret.

>>> Jeg tror desværre du må indse at Kylix er et dødt produkt og at Linux
>>> derfor ikke er en god platform for Delphi-programmører.
>>
>> Måske, måske ikke.
>
> Lad os se om 10 år.

Jeg er hverken religiøs eller fanatiker, så om det bliver om 10 år eller
aldrig er sådan set ligegyldigt.
Hvis der ikke er nogle kunder der bruger Linux, er det det fuldstændig
uinteressant alligevel.
Det er jo sådan set op til Linux folket at skabe de fornødne rammer.
Personligt tror jeg faktisk aldrig det vil ske, men hver har sin
krystalkugle.
Og jeg snakker ikke hjemmepc'ere, men virksomhedspc'ere.
For hver dag der går, kommer der mere og mere Windows applikationer på
PC'erne, så jo længere tid der går jo sværere bliver opgaven.
Og windows på PC'ere medfører mere eller mindre direkte Windows på Serverne,
så heller ikke der kommer Linux ind.

Det eneste brugbare udfald jeg kan se, er at Linux udvikler sig til et rent
plagiat af Windows.

> Lad os bare sige et websystem.

Ok, så er det ikke mission critical.
Her vil man formentlig kunne finde de fornødne oplysninger i diverse
logfiler/log tabeller.

> Mission critical, det lyder interessant.

Mission critical = Forretningen går i stå hvis systemet går i stå.

> Så det du egentlig gør, er at lave en kode i din fejlmelding som
> fortæller hvor den stammer fra? Et enlinies stacktrace :))

Hvis det er et kæmpe batchjob der fejler undervejs, skal du nok mere op i A4
siders størrelse med fejlmelding, med forklaring om hvad der gik galt, hvor
det gik galt, samt forslag til hvordan man kan rette det.

> Jeg går ud fra at du også håndtere flersprogsproblematikken i disse
> fejlmeldinger?

Hvis kunden ønsker flersprogssystemer, så får han det.
Men så vil han få tekster, fejlmeldinger m.v. på kun eet sprog.
Jeg har så et system, så de selv kan oprette lige så mange sprog og
oversættelser som de lyster. Jeg skal ikke nyde noget af at oversætte til
serbo kroatisk eller lign.

> Spøjst. Så er det måske et forkert programmeringssprog du har valgt?

Det er som man tager det.
Jeg har mange 100.000 linier (reusable) kode på lager fra de sidste 20 år.

Det vil nok tage mig 20 år at omskrive til Java, så det kommer ikke på tale.
Derudover kender jeg ikke rigtig nogen der kører/vil køre Java på Windows
systemer, så jeg ved rigtig hvad jeg skulle få ud af Java.

> Til Java er der Apache Derby, den skulle vist være ok til det meste.

Jeg har det fint med SQLite, og der er endnu ikke noget der tyder på, at den
ikke fungere tilfredsstillende.

> Benchmarking er en kunst i sig selv. De fleste JVM'er er tæskelangsomme
> til at komme i luften, og gevinsten kommer først når de har kørt et
> stykke tid.

Det har været diskuteret til hudløshed ovre i Borland grupperne, dog .NET,
men det er samme problemstilling.

Dem der fremhæver VM og GC laver benchmarks til deres fordel, og dem der
foretrækker Native laver dem omvendt.
Jeg synes det er logik for burhøns, at det afhænger af de enkelte behov.
Applikationer, der kræver en masse adressehåndtering vil pr. definition være
sindsygt langsomme under Pcode systemer, hvorimod hvis der kun er tale om
simple data transfer, er det nok fifty-fifty.

Jeg brugte selv noget engang, der hed Transact. Det performede ~10 %
langsommere end Cobol til de fleste ting.

Men til Renteberegning/tilskrivning på konti havde jeg brug for et
flerdimensionelt array.
Jeg lavede en indledende performance test mod en tilsvarende pascal rutine.

I den funktion var pcode systemet 1392 gange langsommere.
Så resultatet blev en hybrid model.

> Hjemmelavede benchmarks tager sjældent højde for den slags.

Hverken hjemmelavede eller 'betalte' benchmarks ville jeg tro på.
Den eneste reelle benchmark jeg ville stole på er den selvsamme, faktiske
applikation afprøvet under begge forhold.

> Bemærk venligst at jeg ikke synes det er en dårlig ide at lave
> Delphi-programmer. Det må du selv rode med :)

Hvilke andre værktøjer ville du anbefale til stort set alt fra native GUI på
windows over middleware til backend services/web services?

Hvis vi lige undtager .NET

--
Med venlig hilsen
Stig Johansen

---

Stig Johansen skrev den 21-05-2008 02:46:

> Hvilke andre værktøjer ville du anbefale til stort set alt fra native GUI på
> windows over middleware til backend services/web services?

Jeg tror ikke der findes eet værktøj/programmeringssprog der er velegnet
til det hele.

Det er efterhånden et spørgsmål om at finde de rigtige programklumper i
form af biblioteker, og så bruge et sprog der kan kalde dem.
--
Thorbjørn Ravn Andersen "... plus... Tubular Bells!"

---

Den Tue, 20 May 2008 21:07:09 +0200 skrev Thorbjørn Ravn Andersen:
> Stig Johansen skrev den 20-05-2008 08:24:
>
>> Er det derimod udfyldte/forkerte felter vil jeg give en sigende fejl og
>> årsag, og ikke raise en exception.
>
> Naturligvis ikke. Exceptions er til at håndtere fejlsituationer uden at
> skulle have en if/case-struktur efter hvert kald, ikke almindeligt
> programflow (hvilket validering er).

I stedet skal man så have en try før hvert kald og en catch efter
hvert kald.

Alternativt skal man bruge "Microsoft-løsningen", og have en stor
try/catch om det hele der smider en messagebox eller en blå skærm
op med "generel fejl".

Mvh
Kent
--
"So there I was surrounded by all these scary creatures
They were even scarier than what Microsoft call features"
- C64Mafia: Forbidden Forest (Don't Go Walking Slow).

---

Kent Friis skrev den 24-05-2008 22:13:

> I stedet skal man så have en try før hvert kald og en catch efter
> hvert kald.

Nej, det var præcis der vi startede. Fejlhåndtering følger ikke
nødvendigvis programmets logik, men kan eventult håndteres højere oppe.

Hvis jeg fx har en "Indlæs-konfigurationsfil" funktionalitet, behøver
jeg ikke nødvendigvis håndtere 117 forskellige fejsituationer men blot
konstatere at der skete en IO-fejl under indlæsningen og handle derefter.

At man kan have angive en exception som grunden til en anden, er en
rigtig god ting som kan lette fejlfinding enormt, fordi man bortsmider
mindst mulig information


--
Thorbjørn Ravn Andersen "... plus... Tubular Bells!"

---

Den Sun, 25 May 2008 01:44:51 +0200 skrev Thorbjørn Ravn Andersen:
> Kent Friis skrev den 24-05-2008 22:13:
>
>> I stedet skal man så have en try før hvert kald og en catch efter
>> hvert kald.
>
> Nej, det var præcis der vi startede. Fejlhåndtering følger ikke
> nødvendigvis programmets logik, men kan eventult håndteres højere oppe.
>
> Hvis jeg fx har en "Indlæs-konfigurationsfil" funktionalitet, behøver
> jeg ikke nødvendigvis håndtere 117 forskellige fejsituationer men blot
> konstatere at der skete en IO-fejl under indlæsningen og handle derefter.

Og det leder netop til fejl som "Der er sket en ukendt fejl under
indlæsning af konfigurations-filen, geninstaller programmet og
prøv igen".

I stedet for "Der er et komma for meget på linje 227, men filen kunne
iøvrigt godt indlæses".

Mvh
Kent
--
"So there I was surrounded by all these scary creatures
They were even scarier than what Microsoft call features"
- C64Mafia: Forbidden Forest (Don't Go Walking Slow).

---

Kent Friis skrev den 25-05-2008 12:53:

> Og det leder netop til fejl som "Der er sket en ukendt fejl under
> indlæsning af konfigurations-filen, geninstaller programmet og
> prøv igen".
>
> I stedet for "Der er et komma for meget på linje 227, men filen kunne
> iøvrigt godt indlæses".

Nogen fejl er vigtigere end andre fejl, og hvis specifikationen siger at
den slags situationer skal rapporteres sådan, så bliver den det.

Det gør den sjældent.

--
Thorbjørn Ravn Andersen "... plus... Tubular Bells!"

---

Den Sun, 25 May 2008 19:41:09 +0200 skrev Thorbjørn Ravn Andersen:
> Kent Friis skrev den 25-05-2008 12:53:
>
>> Og det leder netop til fejl som "Der er sket en ukendt fejl under
>> indlæsning af konfigurations-filen, geninstaller programmet og
>> prøv igen".
>>
>> I stedet for "Der er et komma for meget på linje 227, men filen kunne
>> iøvrigt godt indlæses".
>
> Nogen fejl er vigtigere end andre fejl, og hvis specifikationen siger at
> den slags situationer skal rapporteres sådan, så bliver den det.
>
> Det gør den sjældent.

Uanset hvad specifikationen siger, så lokker try/catch meget nemt
til at man laver "generel fejl" fejlbeskeder, med deraf følgende
retry, reboot, reinstall, reformat fejlsøgning.

Mvh
Kent
--
"So there I was surrounded by all these scary creatures
They were even scarier than what Microsoft call features"
- C64Mafia: Forbidden Forest (Don't Go Walking Slow).

---

Kent Friis skrev den 25-05-2008 21:14:

> Uanset hvad specifikationen siger, så lokker try/catch meget nemt
> til at man laver "generel fejl" fejlbeskeder, med deraf følgende
> retry, reboot, reinstall, reformat fejlsøgning.

Ikke i min verden. Siger speccen specifik fejlhåndtering, får de det.

Bortset fra det, så er alternativet med ignorerede fejlkoder da værre.
--
Thorbjørn Ravn Andersen "... plus... Tubular Bells!"

---

Den Sun, 25 May 2008 21:47:36 +0200 skrev Thorbjørn Ravn Andersen:
> Kent Friis skrev den 25-05-2008 21:14:
>
>> Uanset hvad specifikationen siger, så lokker try/catch meget nemt
>> til at man laver "generel fejl" fejlbeskeder, med deraf følgende
>> retry, reboot, reinstall, reformat fejlsøgning.
>
> Ikke i min verden. Siger speccen specifik fejlhåndtering, får de det.

Hvis vi lige vender den på hovedet en gang, siger du jo reelt
at hvis spec'en ikke udtrykkeligt beder om fornuftige fejlbeskeder,
laver du det præcist som jeg hele tiden har sagt at try/catch
lægger op til.

> Bortset fra det, så er alternativet med ignorerede fejlkoder da værre.

Man kan også ignorere exceptions, det er ikke det vi diskuterer.

Mvh
Kent
--
"So there I was surrounded by all these scary creatures
They were even scarier than what Microsoft call features"
- C64Mafia: Forbidden Forest (Don't Go Walking Slow).

---

Kent Friis skrev den 25-05-2008 22:12:

> Hvis vi lige vender den på hovedet en gang, siger du jo reelt
> at hvis spec'en ikke udtrykkeligt beder om fornuftige fejlbeskeder,
> laver du det præcist som jeg hele tiden har sagt at try/catch
> lægger op til.

Jeg har den grundholdning at exceptions skal håndteres korrekt. Hvad
"korrekt" dækker afhænger af konteksten. De fejl man ikke kan håndtere
eller ikke har forudset, skal boble op til den globale fejlhåndtering
med mest mulig information til retsmedicineren.

Det er nok den situation du væmmes over.

De fejl man KAN håndtere, skal boble op med den nødvendige information
til det sted der kan håndtere den. Dette gøres ofte med ekstra felter i
en hjemmelavet exception, og dem laver jeg sjældent fordi det netop
drejer sig om UVENTEDE ting. Ofte kan man komme rigtigt langt blot med
en passende navngivet exception.

Så uanset om du vender det på hovedet eller ej, ændrer det ikke på at
der er to slags - forudsete og uforudsete. De forudsete håndteres
naturligvis på passende vis. De uforudsete SKAL råbe vagt i gevær.

--
Thorbjørn Ravn Andersen "... plus... Tubular Bells!"

---

Michael Rasmussen <mir@miras.org> writes:

> On Mon, 19 May 2008 15:28:46 +0200
> Stig Johansen <wopr.dk@gmaill.com> wrote:
>
> >
> > - Og vi snakker NPTL threads, som _ikke_ har selvstændige pid'er.
> >
> Det er ikke korrekt. NPTL adskiller sig netop fra linker library tråde
> ved, at kernen tildeler hver enkelt tråd sin egen PID, men har fælles
> PPID - dog i kerneland.

NPTL-traade har ikke selvstaendige PID'er. Det var en af de ting der
adskilte NPTL fra den gamle, forkerte pthread-implementation.

Proev at koere dette program:

#include <unistd.h>
#include <stdlib.h>
#include <pthread.h>

static void *
thread_a (void *x)
{
while (1)
;
}

static void *
thread_b (void *x)
{
while (1)
;
}

int
main ()
{
pthread_t ta, tb;

pthread_create (&ta, NULL, thread_a, NULL);
pthread_create (&ta, NULL, thread_a, NULL);

sleep (30);
}

og se hvad ps siger:

localhost% ps -e -f -T
UID PID SPID PPID C STIME TTY TIME CMD
[...]
ssp 7399 7399 2703 0 14:04 pts/4 00:00:00 ./a.out
ssp 7399 7400 2703 88 14:04 pts/4 00:00:09 ./a.out
ssp 7399 7401 2703 86 14:04 pts/4 00:00:09 ./a.out

Bemaerk at de tre traade har samme PID og samme PPID, men forskellige
SPID'er.

---

Soeren Sandmann wrote:

> og se hvad ps siger:
>
> localhost% ps -e -f -T
> UID PID SPID PPID C STIME TTY TIME CMD
> [...]
> ssp 7399 7399 2703 0 14:04 pts/4 00:00:00 ./a.out
> ssp 7399 7400 2703 88 14:04 pts/4 00:00:09 ./a.out
> ssp 7399 7401 2703 86 14:04 pts/4 00:00:09 ./a.out
>
> Bemaerk at de tre traade har samme PID og samme PPID, men forskellige
> SPID'er.

Jeg har egentlig et følgespørgsmål.
På samme måde som dit eksempel, har jeg en masterprocess, og 2 (stationære)
tråde kørende, som derefter starter workerthreads.

ps med venner er stærkt reducerede på den ttylinux, så her er en ls:
# ls -l /proc/3594/task/
dr-xr-xr-x 4 root root 0 May 19 17:12 3594
dr-xr-xr-x 4 root root 0 May 19 17:12 3595
dr-xr-xr-x 4 root root 0 May 19 17:12 3596

Og det jeg bemærker er, at SPID[1] er fortløbende nummereret ud fra PID.

Det kan godt være jeg spørger dumt, men er det _samme_ nummerrække de deler?

Altså, at der max kan være 32767 aktive processer+tråde ?

[1] SPID ? hvad står det egentlig for Systems Processing ID?

--
Med venlig hilsen
Stig Johansen

---

---

---

Stig Johansen wrote:

> Nej - exceptions er noget fanden har skabt i sin vrede. Tværtimod, så
> fjerner jeg dem (i det omfang, det kan lade sig gøre), og laver det om
> til statuskoder, så man kan lave _ordentlige_ bail-out procedurer.

Hvad gør du når der er 17 funktionskald mellem det sted hvor fejlen
opstår og der hvor den skal behandles?

Der var vist ikke exceptions i de tidlige objekt orienterede versioner af
Turbo/Borland Pascal (i starten af 1990'erne), og efterfølgende er jeg
gået over til C++ så jeg har ikke fulgt med Delphi/Kylix udviklingen.

--
Jesper Lund

---

Jesper Lund wrote:

> Stig Johansen wrote:
>
>> Nej - exceptions er noget fanden har skabt i sin vrede. Tværtimod, så
>> fjerner jeg dem (i det omfang, det kan lade sig gøre), og laver det om
>> til statuskoder, så man kan lave _ordentlige_ bail-out procedurer.
>
> Hvad gør du når der er 17 funktionskald mellem det sted hvor fejlen
> opstår og der hvor den skal behandles?

I de ting jeg lave skal fejlen behandles der hvor den opstår, ikke 17
efterfølgende if's for at finde ud af hvor fejlen opstod.

> Der var vist ikke exceptions i de tidlige objekt orienterede versioner af
> Turbo/Borland Pascal (i starten af 1990'erne), og efterfølgende er jeg
> gået over til C++ så jeg har ikke fulgt med Delphi/Kylix udviklingen.

Jeg ved ikke hvornår exceptions kom til, men jeg ved de ikke var der i
80'erne.

Men hvis du kigger på status i dag, så er
Delphi/Object Pascal, C++, Java samt C# stort set eet fedt, det er næsten
bare at skifte mellem begin..end og {}.

C# er naturligt nok, for det selv samme Anders Hejlsberg der stod bag
Delphi.

Hvem der plagierer hvem i forhold til C++ og Java aner jeg ikke noget om.

--
Med venlig hilsen
Stig Johansen

---

Stig Johansen wrote:

> Uden at udtale mig for eller imod patenter, så ligger det sådan at
> Borland har noget patent på Exception handling. Det siger lidt om vi
> godt ved hvad exception handling er, og at vi har haft det siden midt
> 90'erne.

Siden midten af 1990erne må være i Delphi.

2nd edition af C++ biblen (Stroustrup, "The C++ Programming Language")
fra 1991 har et kapitel om exceptions.

--
Jesper Lund

---

Jesper Lund wrote:

> Stig Johansen wrote:
>
>> Uden at udtale mig for eller imod patenter, så ligger det sådan at
>> Borland har noget patent på Exception handling. Det siger lidt om vi
>> godt ved hvad exception handling er, og at vi har haft det siden midt
>> 90'erne.
>
> Siden midten af 1990erne må være i Delphi.
>
> 2nd edition af C++ biblen (Stroustrup, "The C++ Programming Language")
> fra 1991 har et kapitel om exceptions.

Jeg ved det ikke.
Midt 90'erne var bare et slag på tasken.
Jeg har brugt det siden Turbo pascal ca. midt '80 og husker ikke om det blev
indført i den ene eller anden version af Turbo Pascal/Borland
Pascal/Delphi.
Borland laver også C++, så kan også være startet der.
Patentet har tilsyneladende lavet støj i Wine projektet engang:
<http://www.builderau.com.au/news/soa/Wine-development-stifled-by-software-patent/0,339028227,339188400,00.htm>
Jeg har ikke nærlæst det, men umiddelbart ser det ud som om det er noget
specifikt, og ikke exception handling generelt.

--
Med venlig hilsen
Stig Johansen

---

Stig Johansen wrote:

> Borland laver også C++, så kan også være startet der. Patentet har
> tilsyneladende lavet støj i Wine projektet engang:
> <http://www.builderau.com.au/news/soa/Wine-development-stifled-by-
software-patent/0,339028227,339188400,00.htm>
> Jeg har ikke nærlæst det, men umiddelbart ser det ud som om det er noget
> specifikt, og ikke exception handling generelt.

Enig, der er andre former for exception handling end SEH.

--
Jesper Lund