Varför Linux?

om det nu är just utvecklare som gjort systemet för sin egen skull så vore det ju konstigt om det inte också var väl lämpat för utvecklare att använda.

Powershell vs bash igen... hmmm...
Har alltid sätt på Power'Shell' som ett skal uppe på Windows och bash som integrerat i Linux. Kanske har fel?
Powershell har gjort enorm skillad för mig iaf... speciellt när 2.0 kom, it changed my world!

Massor. Jag fick 29,7 miljoner träffar!

https://www.google.se/search?q=windows+driver+issue

Sedan skall vi inte glömma att "mörkertalet" över antalet klagande hos Windows är ... stort.
Hur många Windows-användare rapporterar strul? De flesta rycker troligen på axlarna och nöjer sig med de varnings-trianglar dem har i enhets-hanteraren (Och hur många använder enhets-hanteraren?). De flesta köper nog en ny dator, när USB-porten slutar fungera. Det bidrar mer till Windows försäljnings-statistik när den egentligen borde ha bidragit till "Driver issue" statistiken.
Jämför det med den genomsnittlige Linux-användaren. Där rapporterar användarna fel och buggar oftare genom att be om hjälp på forum, eller rentav använda sig av den inbyggda bugg-rapporteringen många distributioner idag kommer med.

Båda systemen har ett mörkertal, men den är högst troligt mycket större under Windows, än vad den är under en Linux-miljö, då de flesta "icke-kunniga / lata" användarna i regel sitter under Windows.

Sedan skall vi inte glömma att "mörkertalet" över antalet klagande hos Windows är ... stort.
Hur många Windows-användare rapporterar strul? De flesta rycker troligen på axlarna och nöjer sig med de varnings-trianglar dem har i enhets-hanteraren (Och hur många använder enhets-hanteraren?). De flesta köper nog en ny dator, när USB-porten slutar fungera. Det bidrar mer till Windows försäljnings-statistik när den egentligen borde ha bidragit till "Driver issue" statistiken.
Jämför det med den genomsnittlige Linux-användaren. Där rapporterar användarna fel och buggar oftare genom att be om hjälp på forum, eller rentav använda sig av den inbyggda bugg-rapporteringen många distributioner idag kommer med.

Båda systemen har ett mörkertal, men den är högst troligt mycket större under Windows, än vad den är under en Linux-miljö, då de flesta "icke-kunniga / lata" användarna i regel sitter under Windows.

Helt klart är det så! Linuxanvändare skriv nog mer i forum och söker hjälp på problem medans den vnaliga svenssnon windowsanvändaren antingen rycker på axlarna som du säger, ringer en vän, ringer datorsupporten osv. De som ens testar Linux är oftast mer än en vanlig svensson, det är folk som är intresserade av lite utmaningar eller som vill testa på nya saker med datorer och givetvis kommer man stöta på problem, men istället för att rycka på axlarna så skriver man flitigt i forrum vilket skapar många träffar på Google.

Om du är ute efter en privat "diskussion", skriv då inte på ett offentligt forum där alla kan läsa och bidra med lite vett.

Jo, diskussionen handlade från första början precis om vad jag som aktiv användare tycker om Linux (vilket sannolikt går hand i hand med 'varför' jag använder Linux). Inte vad du som icke-linuxanvändare tycker om vare sig Linux eller Windows, inte heller om vad jag tycker om Windows.

Men likt Beh så ångrar jag att jag matade trollen och nu är det slut med gratisluncherna på min bekostnad för er i den här tråden.

Så du menar att det lönar sig att anpassa operativsystemet istället för att lägga den tiden på att arbeta i program såsom Photoshop eller Logic pro? Förklara

Jag förstår vad du menar, men själv så tycker jag fundamentalt tvärtom!
Ett CLI är arketypen för konsekvens och logik i mina ögon. Det är därtill ofta ruskigt effektivt och kanske framför allt trivialt automatiserbart vilket skickar användbarheten upp i stratosfären. En dator har potentialen att vara så mycket mer än en "sociala medier"-terminal, men detta verkar döljas under fler och fler komplexa kosmetiska lager ju längre tiden går.

Jag får nervösa ryckningar när jag ser personer använda grafiska verktyg på horribelt ineffektiva sätt, inkluderat att spendera sin tid med att försöka få millimeterprecision på pekare för att ändra textstorlek, klicka runt och leta i menyer, växla mellan mus och tangentbord, etc. Ett textgränssnitt är ju ständigt konsekvent och deterministiskt: vad kan vara bättre än det?

Kommandoprompten i Windowsmiljö är inte öht utvecklad för att vara ett interaktivt arbetsverktyg på det sättet, utan snarare enbart som en miljö för skriptande av administratörsuppgifter, så det är ingen rättvis jämförelse. Ett modernt skal som Bash är i mina ögon en fröjd som arbetsredskap.

Därmed inte sagt att alla uppgifter måste utföras i textläge, men i många fall är det överlägset (och visst, i andra fall oanvändbart). *nix-system för skrivbordet ger valmöjligheten att använda det verktyg som passar bäst i varje situation.

Powershell är inte jämförbart med skalen i *nix, för Windows är inte byggt kring ett enda gränssnitt, och definitivt inte textfiler. Det handlar inte om huruvida det finns tab completion eller inte, utan det handlar om vad systemet tillhandahåller för möjligheter. Jag skrev längre om detta en annan gång på forumet.

"Kanske" inte, men sedan Unix start på 60-talet så ser jag inga "mördande" alternativ för administrativa uppgifter som uppstått. Det må gå att föreställa sig tekniskt mer avancerade system, men generaliteten har ett värde i sig, och där är textfiler svåröverträffade.

Problemet är att antalet uppgifter människor kan tänka sig vilja göra med ett visst program växer exponentiellt med funktionaliteten likt antalet möjliga schackställningar växer med varje drag, så det är en omöjlighet för en programmerare att inkludera precis alla användbara funktioner i ett program. Dessutom kan en programmerare inte veta med vilka program slutanvändaren kommer vilja kombinera resultat, vilket ger ytterligare en komplexitetsgrad. Ger man enkla möjligheter för användare att själva kombinera dessa delar så tar man bort en stor begränsning.

Syftningen var inte på att alla CLI som någonsin konstruerats skulle vara bättre än GUI (jag noterade uttryckligen att det inte gällde allt), men ett system utan ett potent CLI tappar en stor möjlighet för användbarheten.

Min poäng var väl snarast att färre valmöjligheter inte måste vara ett självändamål, utan att kombinationen ofta bara är positiv. Det är vanligen inte smidigt att redigera bilder i terminalen (visserligen använder jag och många med mig ImageMagick till saker som varken Photoshop/Gimp passar till), men samtidigt så kan ett generellt CLI möjliggöra saker bortom vad GUI kan ge (vilket nu är åtminstone andra gången jag skriver i denna post, utöver i min första post, samt även vad du till sist konstaterar, så det finns nog inte mycket mer att säga).

Det jag ursprungligen reagerade på var att generellt kalla CLI för "ologiskt" och "inkonsekvent", vilket jag fortfarande anser är en beskrivning diametralt motsatt verkligheten för många uppgifter. Peka-klicka-paradigmen har sina fördelar, men textgränssnitt är av naturen exaktare. Epitet som "bökigt" och "tungrott" har jag lättare att förstå, beroende på uppgift, men att kalla CLI "inkonsekvent", i jämförelse med alla olika UI-paradigmer som finns, njae.

Powershell i ett vakuum och Bash i ett vakuum vore direkt jämförbara som verktyg, men syftet med uttalandet att de inte är (rättvist) jämförbara i ett vidare perspektiv är att de ju inte är tänkta att agera på "egen hand" (eller ja, man kan skriva en primtalsfaktoriserare eller sorteringsalgoritmer i shell script, men det är inte rätt ), utan deras funktion beror fundamentalt på vad de har att interagera med. På den grunden så är ett system som byggts kring denna paradigm i över 40 år inte jämförbart med ett system som lagt till Powershell för att lappa en administrativ önskan.

Det viktiga för att kunna koppla samman olika delar är ju just som du säger att alla använder samma gränssnitt. Postulaten är 1. att det gränssnitt som bäst lämpar sig för detta är det enklaste som fortfarande är funktionellt, och 2. att text är detta gränssnitt. Att det känns "tråkigt" och "omodernt" förtar inte att det fungerar för sitt syfte.

Vad gäller ineffektiviteten i textöverföring kontra dedikerada datatyper så är det något som närpå öht inte spelar in i skalets funktion: det är inte tänkt att vara en högprestandaberäknare (prestanda är givetvis inte negativt, men det är långt ifrån primärt); behöver man prestanda så använder man Perl/Python/C/C#/Java/vad som nu passar. Tunga beräkningarna sker ju i praktiken just i binärer/skript, men vad textgränssnitt möjliggör är kommunikation mellan dessa separata delar. Att basera yttre gränssnitt på text motsäger inte att ha effektiva datastrukturer där de behövs.

Nä, men det är ett falskt dilemma som inget argumenterat för heller. Det är inte "svart eller vitt", men just detta gör ju att kombinationen (för n:te gången ) måste vara det bästa: har man ett funktionellt GUI OCH ett funktionellt CLI så löser det fler problem än bara det ena.

De är meningslösa om man gör det till en "AIK vs Djurgården"-diskussion, men nog finns det insikter att hitta om vad som gör det ena systemet till mer passande än det andra i olika situationer.

Återigen så är ju detta inte något som någon argumenterat emot. Ingen förespråkar att högprestandakod för dataanalys i avancerade fysikaliska experiment måste behandla sin kod i Bashscript och sina datafiler i ASCII. Att attackera den positionen är att sparka in en öppen dörr — diskussionen startade med att kombinationen av två potenta gränssnitt är bättre än ett, och att det finns domäner där CLI mer uppenbart kan lösa ett problem gentemot GUI och vice versa.

Ja, men detta cirkulerar tillbaka till det som startade denna post: att t ex Bash och Powershell löser olika uppgifter, samt att det ena inte måste utesluta det andra.

Jag flyttar utflykten till tråden som länkades innan, då den känns mer passande där.

Ja, men varför skulle jag vilja slösa tid på att anpassa operativsystemet när jag istället kan skapa musik, spela spel eller redigera film?

Skulle säga att de två absolut största styrkorna i UNIX (och därmed Linux) är att text är grunden för allt samt att hela "shell" miljön bygger på att program tar argument som påverkar hur de behandlar data och data får man från stdin eller fil och data producerar man till stdout eller fil.

Att text är bättre än binära format blir uppenbart första gången man ska jobba med program där det finns lite eller ingen dokumentation, ingen som jobbat med programmet finns att tillgå och man har fått i uppgift rätta en bug, utöka funktionallitet eller skriva ett nytt program som hanterar samma typ av indata och producerar samma typ av utdata. Detta är inte alls ovanligt och om all data var i binärformat så har man ett problem som är långt mycket mer komplicerat framför sig.

Som det beskrivs så väl i "The Pragmatic Programmer"
Keep Knowledge in Plain Text
Plain text won't become obsolete. It helps leverage your work and simplifies debugging and testing.

Men tycker att den andra egenskapen är minst lika viktigt. Ta bara en sådan sak som att du vill packa ihop en bibliotek på en dator, komprimera det, skicka det till en annan dator, återställa data och packa upp biblioteksträdet. En helt rimlig uppgift (har använt mig väldigt ofta av detta), det kanske finns ett problem som gör allt detta men det är inte precis ett program som har en specifik uppgift.

Det är däremot inga problem att skriva en BASH rad som gör precis detta och anledningen är just att det finns små program som är skrivna som "filter", de läser data från fil/stdin, gör en transform och skriver till fil/stdout.

$ ssh <source> "tar cf - <bibliotek> | bzip2" | bunzip2 | tar xf -

Vet att man kan skriva detta kortare, men det är inte poängen. Poängen är att styrkan hos UNIX är att om alla enas om hur man hämtar och producerar data och detta är via den mest grundläggande metoden för I/O i ett OS, läsa skriva text (text i ganska vid bemärkelse här).

Vad som händer här är att man, via nätverket, går in på den andra maskinen, kör ett kommando som kommer packa ihop filerna, komprimera resultatet och skicka ut data på stdout. SSH klienten vidarebefordrar stdout data, skriver det på den lokala stdin som BASH kopplat till bunzip2. Data blir därför återställt och resultatet stoppas in i tar som därmed kan återskapa biblioteket.

Styrkan i BASH är alltså att man väldigt enkelt kan anpassa arbetsmoment till helt nya kommunikationssätt, man kan göra saker ingen tänkt på. Har själv en hel del stdin/stdout "adaptrar" som gör det möjligt att via en Linux-dator skripta uppgifter på inbyggda-system. Enda man behöver här är ett sätt att komma in på systemet (nätverk, serie-port, JTAG eller liknande) + något som kan köra funktioner på systemet. Att skripta blir sedan ett helt "vanligt" BASH-skript för en uppgift ingen tidigare ens funderat att skapa ett program för.

Läser man hur PowerShell blev till så kommer det från Microsoft-anställda som önskade "BASH" på Windows. Problemet med Windows är att det inte finns ett standardiserat sätt hur data ska konsumeras/produceras likt det som finns under UNIX. Man tittade bl.a. på CygWin men konstaterade att även om det fungerar bra för vad det gör så blir det ganska begränsat på Windows. Vad man insåg var att man måste ha något som kan interagera med COM och .Net vilket är precis vad PowerShell gör.

Så input/output metoden PowerShell använder var inte förstahandvalet utan det val man var tvungen till för att det skulle vara användbart för administrering av Windows-system. Men även om MS egna program i stort sätt uteslutande har COM/.Net gränssnitt så är det definitivt inte något som gäller generellt. PowerShell kan därför aldrig bli lika flexibelt och kraftfullt som BASH.