Inlägg

Tveksamt men säkert det mesta som behövs iaf vid vanligt användande.

Github har något mer modern klient; https://desktop.github.com/

Men jag kör ren bash för mitt användande, eller IDE pluginsen.

Det är dock omöjligt att vara sämre än CMD. Dock kan jag hålla med om att Powershell har sina vägar att gå, onödigt komplicerat i många fall.

Varför använder du inte nvidia drivrutinerna som finns i repo ? Lär ta bra tid innan OpenSource får igång Pascal, då Nvidia inte hjälper till i utvecklingen.

Kolla motståndet över dioden om det går, är det väldigt lågt motstånd så är den nog paj. antingen löda eller byta hela kretsen.

installera sudo sen får du också gå in i dess config med visudo och aktivear wheel för sudo gruppen som ger tillgång till alla inom "sudo" gruppen att använda sudo.

Bra läsning: https://wiki.archlinux.org/index.php/sudo

Well först så var det sökningar som krypterade och anonymiserades via Canonical som sen skickades till Amazon för att få olika produkter vid sökningar.

Dock fick de enorm kritik, folk avinstallerade pluginet eller bytte desktop. Som svar gick canonical ut med en avstängningsknapp och senare default av, dvs det blev opt in och nu slutligen saknas den helt. Många bytte dock då de förlorade förtroendet och brydde sig om integritet. Vad den större massan inte gjorde var att stöta bort all kririk med att Facebook och Google också samlar data och kallade andra för foljehattar.

Skickades från m.sweclockers.com

Förhoppningsvis kommer unity utvecklarna gå till antingen KDE, XFCE, Gnome eller Elementary eller någon annan obskyr DE. Finns nog med desktops som de kan utveckla till och underhålla istället för att köra en egen fork av hela ekosystemet.

Problemet med Unity var att de fortsatte köra med Gnome GTK men så enormt patchat där Gnome folket vare sig av politiska anledningar eller inte vägrade ta emot en patch bara för en distro's skull. Bara titta bördan att ha Arch fungera med Unity. Sedan inte tala om Compiz det borde dö för länge sedan det också.

Ubuntu kan fortfarande köra eget varför inte tema och skapa plugins etc för gnome shell, på detta vis kommer de fortfarande kunna köra sin egen stil kunna patcha uppstream och slippa ha bördan av NIH (not invented here).

Även om forks och valmöjligheter är bra så finns det en brytpunkt anser jag. MIR var mer eller mindre ett PR jippo, Wayland som suttit i development i 6+ år och Canonical går ut med "vi skall skapa eget för att vi kan bättre" detta och under tiden kasta FUD att Wayland inte går pga x och y där i slutändan inget var sant... Frågan är nu dock vad som kommer ske med Ubuntu snappy, de fick en del drag där.

Fast nu är det OS statistik där de räknar från webben. PlayStation har webbläsare likaså Xbox så att de är med statistiken är inte omöjligt dock ser det ut som de har egna useragents om de presenterar mer OS information vet jag inte.

Räknar man marknadsandelar får man avgränsa efter tycke och val så länge man kan motivera men att exkludera vissa enheter bara för att folk inte känner till det eller vet är lite tvetydligt och konstigt resonemang. En TV kan surfa in på en sida och förmodligen räknas in som Android eller Linux eller båda, skall man exkludera dessa för att många inte vet vad för OS dessa kör? Hur skall det vara med bilar som har inbyggd webbläsare som kör nått OS, exempelvis Linux på den?

Är man intresserad av marknadsandelar är det upp till intressenten att visa upp statistik och sedan ta upp vad de inkluderar eller inte. CPUer kan allt från Intel, AMD men också Tegra, Qualcomm, Samsung mm vara av intresse...

Fast vad folk känner till eller inte spelar ingen roll här. Utan det är statistiken som räknas.

Tror Linus blir glad även Microsoft med tanke på att de får licenspengar de skrämt företagen på.

Skickades från m.sweclockers.com

Beklagar verkligen,

Extern 3.5" / 2.5" hårddisk bör kunna klara av så länge den är avstängd och refreshas vart 3e år eller något för att vara säker. SSD går också men är viktigare att man refreshar.

Viktigaste är att du inte kör med en metod och enstaka utan ha flera backups redo i fall en olycka skulle vara framme.

You right.

Arch brukar hålla tillbaka Xorg när Nvidia inte har stöd för ABI'n De brukade hålla också när AMD inte kunde stödja via FGLRX men de tröttnade när de ofta var flera månader efter medans Nvidia oftast hade det redo samma dag vecka om inte dag.

Kernel är lite annorlunda, brukar finnas patchar som Canonical eller andra slänger upp och sedan patchar för att fungera. Vet att i nuläget finns det en patch för 4.10 som Canonical utvecklare har skrivit som används också av Arch.

https://git.archlinux.org/svntogit/packages.git/tree/trunk/ke...
https://git.archlinux.org/svntogit/packages.git/tree/trunk/fi...

Är inte olika drivrutiner utan packeterade för olika distron's pakethanterare. Eftersom alla inte kör med samma paket så måste man ha olika för Debian baserade, Arch baserade, Fedora, CentOS mm. Tänk dig Cola eller Pepsi, nästan samma skit när man dricker bara annan typ av förpackning.

Bästa när man installerar är att använda drivrutinen som finns i distros packethanterare, dessa brukar också vara patchade för att fungera med senaste kerneln när Nvidia inte hunnit släppa några än eller segat som exempelvis nu där de fortfarande inte har officiellt stöd för 4.9/4.10 kerneln.

Nvidia har ett par redo att installera som är färdiga för vissa distron men också en bin/run fil som går att installera på alla, problemet med en run/bin fil är att du installerar utanför pakethanterarens vetenskap vilket gör att nästa gång du kör en update på systemet kan den inte kolla om nästa kernel eller nästa xorg är kompatibel med den du installerade manuellt vilket kan sluta med att man möts av en terminal vid reboot. Oftast löses detta genom att ominstallera drivrutinen som då kompileras om till senaste kernel men ibland fungerar detta inte. Detta är absolut inget användare som inte är vana att ens röra helt enkelt och man får skylla sig själv när man går utanför ekosystemet och börjar manuellt installera saker.

Då använder du inte Nvidias egna, de har de lite svårt då Nvidia vägrar släppa dokumentation om korten samt mycket patent problem när det kommer till ljud via grafikkorten. Går nog att lösa genom att använda Nvidias egna drivrutiner om kortet har stöd från dom det säga.

Hade tidigare X-FI när den var ny, bara problem när Creative vägrade släppa uppdateringar på Windows eller fixa ljudbuggar. Xram var helt värdelöst som bara utgjorde bluescreens och deras EAX finesser höll på att dö då hårdvarumixing är en utdöende grej där allt sker i CPUn istället. Creative hade sina glansdagar under hårdvarumixing men nu spelar det ingen större roll. Allt de gör går att fixa antingen via EQ eller mjukvara. Deras äldre kort funkar utmärkt ibland i Linux men detta är då tack vare community som själva löst drivrutinerna till korten.

Ser ut som senaste beta drivrutiner har lite prestanda problem med diverse spel inklusive detta för mig

Har ni liknande problem så posta info på deras forum: https://devtalk.nvidia.com/default/topic/1001551/linux/nvidia...

Haemimont Games fick reda på att spelet gjorde en del fel och kommer fixa det i kommande uppdatering.

Så nu ser det ut som Feral gjort det igen, de har portat Mad Max till Vulkan.

Vad som krävs är att man anger lösenordet livelongandprosper i Steam och sätter vulkan_beta.

Posta gärna era förbättringar/försämringar.

Mer info finns på GOL: https://www.gamingonlinux.com/articles/mad-max-meets-vulkan-i...

Laggt in det skall se vad 9590+970 ger för svar på detta. Nackdelen är som sagt att Gsync inte fungerar i Vulkan då Nvidia inte laggt in stöd för det ännu.

Fler faser, bättre fördelning som kan ge stabil spänning under belastning. Asus samt säker andra också har också att de kan ge processorn spänning från flera olika mosfets som sedan kan stängas av och andra tar över för att hålla temperaturen nere. Asus brukar kalla det spread spektrum när man har T-Curve igång.

Ganska bra förklaring finns på EK, https://www.ekwb.com/blog/what-is-mosfet-and-why-should-you-k...

Kör du inte med föråldrade OS så skall du använda GPT. Stöd för större partitioner, kan ha fler än 4 "logiska" partitioner samt har varit "framtiden" sen urminnes tider.

Som tidigare talare, Vulkan är platformoberoende till största del. Finns en del kod som skiljer sig mellan när det kommer till fönsterhantering mm men är inget avsevärt svårt för en utvecklare.

Största fallgropen är om utvecklare använder bibliotek som är platformspecifika, då måste man hitta något liknande för resterande platformar vilket ibland kan innebära olika buggar eller helt enkelt att det inte finns för en specifik platform. Hantering av input, ljud etc är något men oftast är det motorn som hanterar detta och är de smarta så kommer de använda SDL2 eller dylikt för just inputs.

Inte för att vara petig men man simulerar inte med Wine utan översätter. Tänk dig Engelska -> Svenska, Wine översätter olika ord mm så Linux förstår hur den skall reagera när spelet frågar efter något. På Windows kommer den använda en dll för att hämta en fil och ladda till minnet, på Linux kommer den istället kalla på en .so fil som gör exakt samma sak eller så nära som möjligt.

Största problemet i Wine är att OpenGL är ganska annorlunda vilket gjort det svårt att utan förlust faktiskt översätta Direct3D till OpenGL. Hjälper inte att de bara haft 1-2 personer som faktiskt suttit i Wine och skrivit OpenGL översättningen. Andra problem är att på Windows så gör många drivrutiner olika hack för att optimera eller fixa fel som spelutvecklarna gjort, detta i sin tur kan resultera i att spelet crashar eller beter sig konstigt under Wine och utvecklarna har svårt att hitta orsaken utan hjälp från Nvidia/AMD samt spelutvecklarna. Det blir som en svart box där saker händer men man kan inte se vad. Detta är också orsaken till varför Doom men även spel som Wolfenstein som har native OpenGL där det ibland även kan fungera bättre just för att OpenGL oftast har likvärdig eller bättre prestanda under Linux när det väl fungerar korrekt.