krigun

Problemene LSE har hatt med TradElec er nok verdt å nevne i denne sammenheng:

London Stock Exchange suffers .NET Crash

Holder meg unna diskusjon.no fra nå av, grunnet Edda Media sin uforkastelige og barnslige oppførsel i denne saken med gamer. De ødelegger overlagt for gamer.no. De bråkutter siden FØR avtaletiden var over, sensurerer en rekke innlegg mot det de har gjort. Syns Edda bør ha baller til å stå for det de mener og kunne ta imot kritikk istedenfor å sensurere og banne.

 

Syns det er synd og vemodig at det er sånn det ender.

 

Takk for meg, mvh Thomas

Hail gamer.no!

Syns også det var dårlig gjort, og velger ikke å støtte selskaper som opererer slik.

Takk for meg også.

PS: Synd at det ikke går an å slette profilen sin.

Dagens programvare er gammeldags er resultatet av at dagens programmeringspråk er gammeldags.

Jupp. Skal en få fart på paralellisering må en inn med strukturendring i C++ ol. En endring på linje med tidligere innføring av objektoreintert struktur (C til C++).

Akkurat, det vi trenger er et "general purpose" språk som har disse egenskapene bygd inn, og som er bakoverkompatibel med eksisterende biblioteker, slik at ikke "hjulet" må skrives på nytt. Men dette er nok litt harde krav

Dagens programvare er gammeldags er resultatet av at dagens programmeringspråk er gammeldags.

Jepp, kor mange er det som faktisk har høyrt om Erlang?

Akkurat, det er ikke mange som har hørt om Erlang, og enda færre klarer å relatere seg til konseptene bak funksjonell programmering (unngå tilstand, immutable datastrukturer, osv). Erlang er jo heller ikke en erstatning på dagens språk, men det løser enkelte problemer myye bedre enn hva du kunne gjort med dagens mest brukte språk. Benytte f.eks 64 CPU kjerner effektivt er blant annet en av dem. Det faktum at du ikke har muterbar tilstand gjør at du ikke trenger låsing og synkronisering (med få unntak, seflfølgelig).

Dagens programvare er gammeldags er resultatet av at dagens programmeringspråk er gammeldags.

Litt morsomt, samt trist å se listen over norske spillutgivelser. AoC, og masse barnespill. Tipper svenskene er misunnelige på oss der

Yess, da gjenstår det bare for Google å dele ut gratis tynnklient PC-er til folket, og bygge ut WLAN globalt. Og så kommer det etterhvert betalingstjenester som tilbyr lokal lagring av filer, osv.

Nei, vent litt... det var Android det ja..

Hva var Firewire igjen? Noen som husker?

Firewire er det stabile alternativet til USB når det gjelder jevne datastrømmer.

Takk, nå husker jeg det. Sist jeg brukte FW var vel i 2001(ish), trodde ikke det hadde noe særlig mer i seg annet enn et fengende navn. Og jeg kunne ikke gitt mer F.. i om det ene alternativet var mer stabilt enn noe annet, ønsker bare ETT felles grensesnitt, ikke to eller flere.

Hva var Firewire igjen? Noen som husker?

Kanskje verdt å nevne at mesteparten av nyhetene ved denne driverlanseringen er for GF 8 serien eller bedre.

Finanskrisen for skylden for alt nå om dagen, selv om den er nesten bare skapt av media. Det er nok mer enn bare "finanskrisen" som ligger bak her.

Tror folk som bor/jobber på Island skulle ønske de også kunne skylde hele greia på mediene.. Men der tror jeg desverre situasjonen er MEGET reell

Fjern semikolon etter:

function onEnterFrame();

Jeg har implementert geometry shaders i Glorg, men jeg har ikke testet det, da jeg har GeForce 7800

Desverre har jeg heller ikke et frekt nok skjermkort til å kunne leke med dette

Hyggelig, skal se om jeg får tatt turen innom irc kanalen her snart

For de av dere som er interessert i GLSL, så kan dere sjekke ut Horde3D, denne motoren bruker så lite av fixed function pipeline i OGL som mulig, og gjør mesteparten i GLSL (deferred/forward shading, skinning, partikler, etc). Denne motoren er veldig fin å lære av, da det er lite annet "rusk" i koden, i motsetning til f.eks Ogre3D, og den er ganske pent skrevet.

Forresten, noen her som har sett på Geometry shadere?

Den går ganske sakte fram da..

Ja, det er jo en tykk bok (~1100 sider), men når det gjelder en som lærer programmering så er det veldig viktig å ikke gå altfor fort frem og presse på konsepter som man nødvendigvis ikke forstår som nybegynner. Dette er enda viktigere for et så komplekst språk som C++. Det er denne illusjonen de "Learn how to program [språk] in N [hours|days|weeks]" bøkene selger, mens de egentlig burde hete "Get a light introduction to [språk] in N [hours|days|weeks]", da det er mer sant.

Spør du meg (og sikkert en haug med andre folk), så er det ingen god ide å starte med å lære seg C, for så å gå over til C++ etterpå. Folk tror disse språkene er så like, at du til og med kan skrive C/C++. Men vi tar ikke den diskusjonen her.

En bok jeg definitivt vil anbefale er C++ Primer Plus. Den tar for seg alt du trenger å vite "fra C", og resten av C++. Har lest denne selv, og det er definitivt en bra bok.

Når du er ferdig med den, så MÅ du egentlig også lese Effective C++, da denne boken burde ha vært obligatorisk lesing for enhver C++ utvikler.

Og.. Man lærer ikke å programmere på 21 dager, iallefall ikke C++.

krigun, blander du ikke sammen det det Linus snakker om i første avsnitt? Han er ikke enig i fsf og rsm sine synspunkter, men synes lisensen er bra? Og den siste quoten er ikke snakk om å gi ut kildekoden(som det er snakk om her), men å låse hardware til programvare. Der er nok sansynlig vis rms og linus uenige.

Jada, den første quoten var kanskje ikke rett PÅ topic, men viser hvorfor Linux er GPL og ikke BSD.

Og ja, TiVo gir ut kildekoden, men lar den altså ikke kjøre på en TiVo box om du har modifisert det på noe vis. Det er denne Hardware->Software linkingen FSF og Linus ikke er enige om.

Det varmer mitt hjerte å se at ikke alle faller for C# og Direct3D. Veldig hyggelig initiativ!

Blir gjerne med hvis SSAO og Deferred Shading med GLSL står på agendaen

Selv skaperen av Linux er ikke enig med FSF (quote fra Torvalds himself, her også om hvorfor han ikke har valgt BSD lisensen):

"Because I think the GPLv2 is a great license. And I don't like the FSF's radical world-view, but I am able to separate the license (the GPLv2) from the author and source of the license (rms and the FSF). Why do people always confuse the two? The GPLv2 stands on its own. The fact that I disagree with the FSF on how to act has _zero_ relevance for my choice of license.

 

"[...] But for a project I actually care about, I would never choose the BSD license. The license doesn't encode my fundamental beliefs of 'fairness'. I think the BSD license encourages a 'everybody for himself' mentality, and doesn't encourage people to work together, and to merge."

 

"Let me put this in source management terms, since I've also been working on a source control management project for the last few years: the BSD license encourages 'branching', but the fact is, branching is not really all that interesting. What's interesting is 'merging': the branching is just a largely irrelevant prerequisite to be able to merge.

 

"The GPLv2 encourages *merging*. Again, the right to 'branch' needs to be there in order for merges to be possible, but the right to branch is actually much less important than the right to 'merge'."

TiVo har jo hatt samme type problemstilling, men de deler ut koden sin igjen, men lar ikke en modifisert versjon kjøre på deres hardware igjen:

TiVo uses Linux for its digital video recorder products. TiVo makes its modifications to the source code publicly available, as required by GPLv2. The term "Tivoization" describes the fact that you can't further modify the TiVo source code and make it run on TiVo hardware. TiVo uses a digital signature to prevent you from doing so. The Free Software Foundation objects to this. Linus Torvalds does not.

Bah... snodig diskusjon...

 

Personlig operer jeg/vi alltid med multi-layer apps. så hvor data er eller hvordan ting lagres blir helt irrelevant for UI laget.

 

[uI app(s)] <-> [server App] <-> [DataStore(s)]

 

UI app'en kan således (uten at den vet noe) motta data fra flere fysiske datastore's (SQL servere) og flatfil lagere.

 

Vi opererer i tillegg med masterserver og slaveserver(e) for å enklere kunne øke antallet UI apps.

Det er bra, og fortsett med det. Men akkurat hvordan applikasjoner er designet er ikke poenget her [i mine poster iallefall]. Det du derimot sier der at det ikke er så nøye hvordan dataene er lagret, som er greia, sålenge du får tak i dem igjen, og klarer å håndtere en løsere koblet langringstruktur.

Her er hyggelig lesestoff om denormalisering:

InfoQ Denormalization

Martin Fowler om at EBay kjører uten databasetransaksjoner:

Transactionless

Og til slutt, Mnesia DBMS til Erlang:

Mmmmmnesia

@krigun:

 

Da vil jeg påstå at bruken av JSR-170/JSR-283 som "content repository" lag mellom applikasjonslaget og lagringsdelen, som her kan være database, flatfiler eller kombinasjon, vil gi en langt bedre fleksibilitet. Det er nemlig slik at i nettløsninger er det data med struktur som egner seg 100 % for typisk databaselogikk, f.eks brukerdata, mens andre data har andre karakteristikker.

 

Problemet er at JSR-170/JSR-283 pr dato bare finnes for Java, selv om man har kommet langt med en PHP versjon og arbeidet er startet i det små med en versjon i Ruby.

Veldig interessant, var faktisk ikke klar over de spesifikasjonene (lese lese). Takk

Det har sikkert sine fordeler, men det lille jeg så på CouchDB, så sliter jeg med å se hvordan man har relasjoner her. Tipper det er opp til egen kode å fikse relasjoner.

Ja, og det er akkurat dette CouchDB ikke håndterer i det hele tatt; det er ikke en relasjonsdatabase.

Og så begynner noen med ORM og annet faenskap, kun for å slippe sql i grunn - av typen select * ... Så ender du opp med å bruke mye tid og krefter på å lære kvasisql implementert av noen luringer.

La oss ikke snakke om ORM her, blir så ufine diskusjoner

Og da er vi over på det som er styrken til rdbms, for jeg vedder på at oracle gruser denne når kompleksiteten øker littegran.

La meg presentere noen eksempler. Hvis vi på den ene siden har en RDBMS, i BCNF hvor forretningslogikken er fanget i stored procedures. Her trenger man bare a sette sammen enkel kode "utenfor databasen" for å ha et litt mer vennlig grensesnitt til forretningslogikken. Dette fungerer veldig bra hvis du på forhånd har kravspecen skåret ut i stein, og vet at antallet brukere ikke vil overstige N brukere.

PÅ den andre ekstreme siden, så har vi en applikasjon som lagrer alt løst i dokumenter (CouchDB), hvor du på forhånd ikke helt vet hvilke krav som kommer "neste uke", og antallet brukere er fullstendig ute i det blå (husker vel hvilke problemer Twitter hadde). Applikasjonen har mye høyere kompleksitet, men er dermed også mye enklere å endre fra dag til dag da man ikke har låst seg fast i ett databaseskjema. Dataene ligger ikke på ett og samme sted, asynkrone operasjoner, osv. Er selfølgelig endel ubesvarte spørsmål her, og jeg skal være den første til å innrømme at CouchDB ikke er god "all rounder" som dagans RDBMS er, men i mine øyne er det iallefall en god start.

PostgreSQL, MySQL... It's all the same. Dagene til relasjonsdatabaser er forbi uansett.

 

Er det ikke fornuftig å begrunne et slik påstand.

Tenk deg da; du lagrer [i flesteparten av tilfellene] ALT på ett sted, og det du lagrer henger på en eller annen måte tett sammen med noe annet som du lagrer. ALT er satt inn i en firkantet boks, med predefinert schema, låser, replikering for å håndtere maskinfeil og whatnot. Jeg kan være enig i at noen ganger er det veldig fint med en relasjonsdatabase, men å prøve å jobbe smidig mot noe så satt som en RDBMS er bare håpløst.

Velkommen CouchDB.

PostgreSQL, MySQL... It's all the same. Dagene til relasjonsdatabaser er forbi uansett.

Jeg mente at du kan integrere native kode MED Java (JNI). OpenGL appleten linket til ovenfor gjør akkurat dette. Så Google har laget en plugin som bruker Python til dette istedenfor. Flott.