Windows suger, är Mac bättre?

bughawk, vilken av napster klonerna såg du? När jag sökte på freshmeat hittade jag 3 styckten till GNOME, och sedan några andra (knapster t.ex)...

Tillbaka till Mac vs PC (*nix) då. Håller man på med webutveckling så har *nix en stor fördel gentemot Mac som
jag ser det. PHP t.ex. - finns det ens för Mac? Internet är ju byggt runt *nix, så det är ett naturligt val om det är Internet man är intresserad av.

Jo, håller man på med programmering och sånt på webben är Unix är ett bra val, men finns det nån bra WYSIWYG editor till Unix?

Muzzafarath

gnome-napster...

hörde att knapster var jättedåligt..

------------------
Mvh Yrin Eldfjell
>>> Hemsida <<<

Knapster fungerar faktiskt utmärkt! Fast jag kör Gnome nu, tröttnade på buggiga KDE, så jag kanske borde testa Gnome-Napster istället.

F.ö. så blev det inte Mac. Det blev Linux istället. Fast jag funderar på att gå tillbaka till Windows igen eftersom det mesta krånglar i Linux för mig. :l

När Mac OS X kommer så kanske jag skaffar en Mac och installerar det. :)

------------------
- Swey
Glömde jag säga snälla?

Swey, det låter bra. Jag hoppas Mac OS inte blir en lika stor besvikelse som Linux blev för dig. Du är välkommen med frågor och hjälp när du vill, när det gäller Mac, så hör av dig bara när det börjar närma sig.

------------------
/Petra
Oh no, they killed Kenny!

Fast jag funderar på att gå tillbaka till Windows igen eftersom det mesta krånglar i Linux för mig.

Kanske är för att du förväntar dig för mycket, för snart. Att konfigurera och kompilera en kernel är t.ex. inte direkt någonting en nybörjare föväntas klara av första veckan. Det är en av de sakerna som gör *nix extremt anpassningsbart för oss som hållit på ett tag. Operativsystemet kan anpassas alltefter som användaren utvecklas.

Men du kan köra Linux utan att kompilera om kärnan, eller kompilera programmen själv (det mesta finns som RPM, eller i annat paketformat). Du är ju då lite mer begränsad, men situationen är ju inte annorlunda i Windows (eller i MacOS - MacOS X eventuellt undantagen då). Skillnaden är att i dessa OS har du inte ens möjligheten, den dagen du behöver den. :)

------------------
Robban < robban@lipogram.com >

Att konfigurera och kompilera en kernel är t.ex. inte direkt någonting en nybörjare föväntas klara av första veckan.
Är det för mycket att förvänta sig att komma åt sin ntfs-partition första veckan? Varför ska det vara så svårt att lägga till stöd för det egentligen? Jag tycker inte det ska vara mer komplicerat än att köra ett kommando.

Men du kan köra Linux utan att kompilera om kärnan
Visst kan jag det. Nu var det dock så att jag ville ha ntfs-stöd och det var därför jag var tvungen att göra det.

Jag menade definitivt inte att kompilera om kernel var det enda som krånglade för mig. När jag t.ex. försöker installera en RPM-fil står det ouppfyllda beroenden och när det var den enda rpm-filen som fanns att ladda hem så känns det inte särskilt lätt att förstå vad man ska göra.

------------------
- Swey
Glömde jag säga snälla?

ja det där är ett helvete, alla libraries och sånt som måste uppgraderas så fort man vill installera nått nytt.

finns det nån bra lösning på det?

Är det för mycket att förvänta sig att komma åt sin ntfs-partition första veckan? Varför ska det vara så svårt att lägga till stöd för det egentligen? Jag tycker inte det ska vara mer komplicerat än att köra ett kommando.

Är det så det är i Mac? Finns det ö.h.t. stöd för NTFS i Mac?

NTFS är ju inget "native" filsystem i Linux, så jag förstår inte riktigt denna inställning. Varför skall Linux ha inbyggt stöd för NTFS? Klagar du på MS för att inte NT/W2000 har inbyggt stöd för ext2?

När jag t.ex. försöker installera en RPM-fil står det ouppfyllda beroenden och när det var den enda rpm-filen som fanns att ladda hem så känns det inte särskilt lätt att förstå vad man ska göra.

Beror på att Linux har valt en annan väg än MS. I Linux är det inte så att varje program du laddar ner innehåller alla delade filer som det programmet behöver, utan användaren förväntas installera vad som behövs separat. Har ju sina för- och nackdelar. Fördelarna är ju att filerna man laddar ner blir mindre, du riskerar inte att installationsprogrammet skriver över filer du redan har med äldre versioner samt att programmen blir väldigt enkla att avinstallera (du slipper helt enkelt det s.k. "DLL-helvetet"). Nackdelen är den du beskriver. Men jag tycker ändå fördelarna överväger nackdelarna.

När RPM vägrar installera ett paket så får du ju också reda på varför. Vilka paket som saknas. Oftast finns dessa paket på din Linux-skiva om du letar.

------------------
Robban < robban@lipogram.com >

NTFS är ju inget "native" filsystem i Linux, så jag förstår inte riktigt denna inställning.
Om det fanns Ext2-stöd för Windows skulle jag inte uppskatta om det inte gick att installera. När man installerar något nytt i Windows görs det nästan alltid automatiskt och man behöver inte gå någon kurs i hur man kompilerar om kernel.

Nu råkar det finnas NTFS-stöd för Linux och då tycker jag faktiskt det är dåligt om jag inte lyckas installera det på ett enkelt sätt. Det finns säkert en lösning men jag tycker ändå det är dåligt att det ska vara så svårt att få saker att fungera i Linux

Tänk om Linux vid installationen kunde gå igenom vilka filsystem det fanns på disken och automatiskt installera de filsystem som stöds. Så fungerar Windows för det mesta.

När RPM vägrar installera ett paket så får du ju också reda på varför.
Nja, när jag har försökt installera har det många gånger stått att diverse filer saknas och ingen information om vilket paket man ska installera.

Laddar man ned ett program tycker jag det ska stå tydligt vilka paket man måste installera för att programmet ska fungera men det gör det (nästan?) aldrig.

Många saker är bra i Linux men jag har en förmåga att bara ta upp nackdelarna. ;)

------------------
- Swey
Glömde jag säga snälla?

Nu råkar det finnas NTFS-stöd för Linux och då tycker jag faktiskt det är dåligt om jag inte lyckas installera det på ett enkelt sätt.

Nja, NTFS-stödet i kärnan är experimentellt vad jag vet, och får snarare ses som en bonus. Det finns alltså inget officiellt stöd för NTFS (och det är troligen anledningen till att RH inte skickar med NTFS-modulen från början - de är väl inte så pigga på att supporta experimentella moduler kan jag tänka).

Tänk om Linux vid installationen kunde gå igenom vilka filsystem det fanns på disken och automatiskt installera de filsystem som stöds. Så fungerar Windows för det mesta.

Så fungerar RH också. Har du en (V)FAT-partition på disken när du installerar RH så frågar installationsprogrammet om du vill kunna komma åt den från Linux (så var det i.a.f. för mig).

Min NT-installation vet inte ens om att jag har Linux och FreeBSD installerad på samma dator. De partitionerna vill Windows ö.h.t. inte kännas vid.

Nja, när jag har försökt installera har det många gånger stått att diverse filer saknas och ingen information om vilket paket man ska installera.

Då skall du få ett litet shellscript av mig. ;)

Montera din RedHat-CD och ställ dig i katalogen där alla RPM-filer finns. Skriv in följande vid BASH-prompten:

<font size="1" face="Verdana, Arial, Helvetica, sans-serif">
for f in *
> do
> if rpm -qlp $f &#0124; grep filnamn
> then
> echo $f
> fi
> done
</font>

Skriver ut vilken/vilka paket som innehåller filen filnamn.

------------------
Robban < robban@lipogram.com >

Det där fungerar ju ganska bra. Går det att göra så att man anropar den med "någonting <filnamn>"? För att slippa skriva hela skriptet varje gång.

------------------
- Swey
Skriv först, tänk sen!

Visst (börjar bli lite OT nu). :)

Lägg följande i en textfil med valfritt namn, och gör den körbar.

<font size="1" face="Verdana, Arial, Helvetica, sans-serif">
#!/bin/bash

for f in *
do
if rpm -qlp $f &#0124; grep $1
then
echo $f
fi
done
</font>

------------------
Robban < robban@lipogram.com >

Jag har kört win2000 i snart 8 månader och har hitills inte lyckats krascha systemet en enda gång, vet inte om detta är unikt men jag kan inte riktigt hålla med om att ms bara gör dåliga, kraschbenägna produkter.