mboost-dp1
unknown
Endelig!
Det er herligt at se Wine-projektet går fremaf!
Det må jeg have compilet med det samme :)
Way to go Wine-guys!
Det er herligt at se Wine-projektet går fremaf!
Det må jeg have compilet med det samme :)
Way to go Wine-guys!
#2:
Hvorfor skifte til linux hvis du alligevel anvender wine så kraftigt? Du er selvfølgelig velkommen men det er ikke nær så sjovt.
Generelt findes der alligevel så mange gode programmer som erstatter de programmer man var afhængig af i Windows.
Wine er udmærket til at emulere småprogrammer men ofte er det fejlfyldt og ikke specielt hurtigt. Hvis wine virkede for godt blev det en sovepude for softwarebranchen som derved kun behøvede at udvikle til windows :-/
Hvorfor skifte til linux hvis du alligevel anvender wine så kraftigt? Du er selvfølgelig velkommen men det er ikke nær så sjovt.
Generelt findes der alligevel så mange gode programmer som erstatter de programmer man var afhængig af i Windows.
Wine er udmærket til at emulere småprogrammer men ofte er det fejlfyldt og ikke specielt hurtigt. Hvis wine virkede for godt blev det en sovepude for softwarebranchen som derved kun behøvede at udvikle til windows :-/
#2 knasknaz
Tja, jeg har haft forsøgt mig med Wine 2 gange, uden succes. Det var ikke sådan ligetil at installere. Men jeg håber det er blevet nemmere, det er trods alt mere end et år siden.
Som #3 mikbund siger, er det kun en ide at bruge hvis man er afhængig af et bestemt program. Jeg lærte mig selv at bruge alternative (frie) programmer.
Og dog, StarCraft kørte så smukt, så smukt, sidst jeg prøvede...
Tja, jeg har haft forsøgt mig med Wine 2 gange, uden succes. Det var ikke sådan ligetil at installere. Men jeg håber det er blevet nemmere, det er trods alt mere end et år siden.
Som #3 mikbund siger, er det kun en ide at bruge hvis man er afhængig af et bestemt program. Jeg lærte mig selv at bruge alternative (frie) programmer.
Og dog, StarCraft kørte så smukt, så smukt, sidst jeg prøvede...
Det kommer på et rigtigt godt tidspunkt for ReactOS folkene. De er lige rundt om hjørnet med version 0.3, og det kunne jo nok godt skabe lidt positiv stemning, at WINE nu er blevet kategoriseret som Beta.
#2 Faktisk vil du sikkert opdage, at du kan gøre langt de fleste ting (eller flere) med native linux programmer. Programmer kørt under wine, ser også ret grimme ud, de nyeste versioner kan man dog theme, med det er meget langsomt.
Selv bruger jeg kun wine til spil som starcraft, diablo og warcraft, selv om jeg er begyndt at spille spil som ut, doom og quake (native) en del mere efter jeg gik linux.
Selv bruger jeg kun wine til spil som starcraft, diablo og warcraft, selv om jeg er begyndt at spille spil som ut, doom og quake (native) en del mere efter jeg gik linux.
Jeg fik installert wine for ikke så lang tid siden på min gentoo, for at prøve det. Det virket okay, men mIRC så lidt sjov ud engang imellem :)
Hvis man vil spille på Linux så brug Cedega, eller holder jeg mig bare til Linux alternativerne.
Hvis man vil spille på Linux så brug Cedega, eller holder jeg mig bare til Linux alternativerne.
Jeg synes godt man i artiklen kunne have givet et link til Wines Applications Database, hvor man kan se om og hvor godt et program er understøttet i Wine.
http://appdb.winehq.org/
Som sagt af udviklerne er der ikke noget stort i at man er gået over til Beta. Faktisk synes jeg selv at det er forkert at bruge betegnelserne Alpha og Beta om et program der konstant behøver at være i udvikling.
http://appdb.winehq.org/
Som sagt af udviklerne er der ikke noget stort i at man er gået over til Beta. Faktisk synes jeg selv at det er forkert at bruge betegnelserne Alpha og Beta om et program der konstant behøver at være i udvikling.
#13
Wine er ikke nødt til at være i konstant udvikling, kun sålænge win32 api'et bliver videreudviklet.
Grunden til man er gået fra alpha til beta er at grundfundamentet til Wine efterhånden er på plads, og nu vil man gerne til at fokusere på applikationsstabilitet. Dvs. man kan fra nu af forvente at applikationer der virker i en version også vil virke i næste, eller at der ihvertfald vil være fokus på at det skal være tilfældet, dette vil nok også medføre længere release cycles også selvom udviklerne gerne vil undgå det.
Wine er ikke nødt til at være i konstant udvikling, kun sålænge win32 api'et bliver videreudviklet.
Grunden til man er gået fra alpha til beta er at grundfundamentet til Wine efterhånden er på plads, og nu vil man gerne til at fokusere på applikationsstabilitet. Dvs. man kan fra nu af forvente at applikationer der virker i en version også vil virke i næste, eller at der ihvertfald vil være fokus på at det skal være tilfældet, dette vil nok også medføre længere release cycles også selvom udviklerne gerne vil undgå det.
#15 Jo, selvfølgelig er Wine nødt til at være i konstant udvikling eftersom Windows er det. Applikationsstabilitet er et vagt mål, målet må være og det har jeg da også indtryk af at det er at implementere Windows' biblioteker, der stadig ændrer sig. Der er underskud i udviklere på Wine og det er et hårdt arbejde at reimplementere alle Windows' biblioteker, måske er det derfor de nu har givet op og fokuserer på stabilitet (bare en løs tanke).
#16
De har et fundament hvorpå de kan implementere api'erne der jo er dll baserede, de har det grundlæggende fundament og vil fra nu af OGSÅ fokusere på applikationer så wine reelt kan blive brugbart for masserne.
Windows er ikke rigtigt noget moving target, selvfølgelig er der de store udgivelser, det betyder nogle ændringer, men lad os sige at målet er at understøtte samtlige applikationer windows xp idag understøtter, så er windows absolut ikke noget moving target. Iøvrigt har microsoft jo flyttet fokus til .net som er et komponent der sandsynligvis hovedsageligt vil blive fixet af andre projekter (mono og portable .gnu)
De har et fundament hvorpå de kan implementere api'erne der jo er dll baserede, de har det grundlæggende fundament og vil fra nu af OGSÅ fokusere på applikationer så wine reelt kan blive brugbart for masserne.
Windows er ikke rigtigt noget moving target, selvfølgelig er der de store udgivelser, det betyder nogle ændringer, men lad os sige at målet er at understøtte samtlige applikationer windows xp idag understøtter, så er windows absolut ikke noget moving target. Iøvrigt har microsoft jo flyttet fokus til .net som er et komponent der sandsynligvis hovedsageligt vil blive fixet af andre projekter (mono og portable .gnu)
#18
Jeg hader at udpensle ting, men fair nok :) Wine er ikke særligt interessant hvis der ikke er nogle applikationer man ved kører på det, en (LANG) liste over understøttede applikationer gør vidundere. Tidligere har man brugt alt tiden på at implementere grundlæggende biblioteker der ligger fundamentet for at kunne implementere bibliotekerne og generelt for at kunne opnå en fornuftig performance.
Dvs. før kiggede man på wine og tænkte "hvad mangler wine?" for at blive generelt brugbart. Nu kigger man i højere grad på en specifik applikation og tænker "hvad mangler wine for at kunne køre den her applikation?"
Hvorfor forskellen? Jo, fordi tidligere var det meget nemt for udviklerne at finde ting at gå igang med, de havde en liste, og det var rimeligt klart hvad der skulle forbedres. Det er nok også sandt et stykke tid endnu, men efterhånden bliver det vigtigste for wine testning og at sikre at koden ikke får tilbagefald på specifikke områder hen af vejen, for at opnå det har de brug for flere brugere, hvilket er årsagen til at man går til beta stadie.
Iøvrigt er et skift fra alpha til beta stadie stortset altid symbolsk og meget subjektivt, men det tjener et formål idet der følger en besked med: "Vi er klar folkens, kom og tæv vores software i stykker!!"
Jeg hader at udpensle ting, men fair nok :) Wine er ikke særligt interessant hvis der ikke er nogle applikationer man ved kører på det, en (LANG) liste over understøttede applikationer gør vidundere. Tidligere har man brugt alt tiden på at implementere grundlæggende biblioteker der ligger fundamentet for at kunne implementere bibliotekerne og generelt for at kunne opnå en fornuftig performance.
Dvs. før kiggede man på wine og tænkte "hvad mangler wine?" for at blive generelt brugbart. Nu kigger man i højere grad på en specifik applikation og tænker "hvad mangler wine for at kunne køre den her applikation?"
Hvorfor forskellen? Jo, fordi tidligere var det meget nemt for udviklerne at finde ting at gå igang med, de havde en liste, og det var rimeligt klart hvad der skulle forbedres. Det er nok også sandt et stykke tid endnu, men efterhånden bliver det vigtigste for wine testning og at sikre at koden ikke får tilbagefald på specifikke områder hen af vejen, for at opnå det har de brug for flere brugere, hvilket er årsagen til at man går til beta stadie.
Iøvrigt er et skift fra alpha til beta stadie stortset altid symbolsk og meget subjektivt, men det tjener et formål idet der følger en besked med: "Vi er klar folkens, kom og tæv vores software i stykker!!"
#20
Jeg går somregel gerne med på 'vi er uenige, og det er fint' konklusionerne, men jeg synes ikke rigtigt det er noget man kan være uenig om det her. Der er en væsentlig forskel imellem at skrive api'er med det mål at opnå et fundament og at skrive api'er med det mål at en applikation skal virke.
Det er der den store forskel ligger, tjek et par 'wine weekly' og se hvad de siger, de har fundamentet nu, fra nu af har de brug for virksomme applikationer og dermed brugere.
Og ja, selvfølgelig har der været folk der har fokuseret på applikationer, wine har været i brug i mange år, og wine har også haft brug for testning i mange år, men fokus er flyttet dertil nu, og det er der jeg ikke rigtigt synes vi kan være uenige.
Jeg går somregel gerne med på 'vi er uenige, og det er fint' konklusionerne, men jeg synes ikke rigtigt det er noget man kan være uenig om det her. Der er en væsentlig forskel imellem at skrive api'er med det mål at opnå et fundament og at skrive api'er med det mål at en applikation skal virke.
Det er der den store forskel ligger, tjek et par 'wine weekly' og se hvad de siger, de har fundamentet nu, fra nu af har de brug for virksomme applikationer og dermed brugere.
Og ja, selvfølgelig har der været folk der har fokuseret på applikationer, wine har været i brug i mange år, og wine har også haft brug for testning i mange år, men fokus er flyttet dertil nu, og det er der jeg ikke rigtigt synes vi kan være uenige.
#21 Alle applikationerne ville virke hvis alle bibliotekerne var reimplementerede. Derfor bør fokus være på bibliotekerne. Derfor er vi uenige. Det lyder tåbeligt at fokusere på applikationer. Det er det WineX og Crossover gør forsi de lever af at køre bestemte programmer. Wine skal bare have de skod biblioteker færdige (hvilket de ikke bliver før MS laver rettelser, altså er de i konstant udvikling). Man kan sagtens værdisætte funktioner efter hvor ofte de bliver brugt af populære applikationer, men det er ikke at sætte fokus på applikationer.
#23
Bibliotekerne er jo forhelvede ikke nemme at implementere, hvorfor tror du wine har taget saa lang tid at udvikle? Derudover er de afhaengige af hinanden, dvs. hvis der er en fejl i et bibliotek vil de andre ikke virke ordentligt, derudover implementeres bibliotekerne jo kun udfra meget begraenset dokumentation. Derfor er det en fordel at fokusere paa applikationerne saa man iterativt kan teste at tingene virker som de skal.
Derudover er der mange andre ting der har betydning for om applikationerne virker...Forskellen paa linux scheduleren og windows scheduleren er et stort problem, derudover er mange systemkald naesten umulige at implementere da de benytter sig af features der ligger i windows kernen.
Er det virkelig din reelle ide at Wine udviklerne burde gaae direkte efter at udvikle apierne og foerst til sidst fokusere paa applikationerne? Udfra et udvikler synspunkt er den fremgangsmaade en smule tvivlsom efter min erfaring, og udfra et maal om at skaffe offentlig interesse og stoette, er den helt hen i vejret.
Bibliotekerne er jo forhelvede ikke nemme at implementere, hvorfor tror du wine har taget saa lang tid at udvikle? Derudover er de afhaengige af hinanden, dvs. hvis der er en fejl i et bibliotek vil de andre ikke virke ordentligt, derudover implementeres bibliotekerne jo kun udfra meget begraenset dokumentation. Derfor er det en fordel at fokusere paa applikationerne saa man iterativt kan teste at tingene virker som de skal.
Derudover er der mange andre ting der har betydning for om applikationerne virker...Forskellen paa linux scheduleren og windows scheduleren er et stort problem, derudover er mange systemkald naesten umulige at implementere da de benytter sig af features der ligger i windows kernen.
Er det virkelig din reelle ide at Wine udviklerne burde gaae direkte efter at udvikle apierne og foerst til sidst fokusere paa applikationerne? Udfra et udvikler synspunkt er den fremgangsmaade en smule tvivlsom efter min erfaring, og udfra et maal om at skaffe offentlig interesse og stoette, er den helt hen i vejret.
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Nyheder
Gå til bund