Sidde

AppleInsider | Road to Snow Leopard: twice the RAM, half the price, 64-bits

Här var en bra förklaring hur det går till, rätt bra då jag minns att jag läst det men tydligen glömt bort det och förväxlat det lite med hur det fungerar i tex Windows.

Är du absolut säker detta? Jag skulle gärna vilja ha ett bevis för att OS X är det enda systemet som med en 32bit kärna kan tillåta en process att adressera mer än 4gb.

Edit: Du har helt rätt, sålänge programmet inte körs från kernel space så ska det fungera. Jag som inte är tillräckligt uppdaterad på Snow Leopard och är för insnöad i övriga operativsystem på marknaden. Jag få skylla på att jag inte kör OS X hemma utan är Linuxifierad.

Edit 2: Jag hittade bevis själv, se post längre ner.

Inlägget innan gjorde inte det: "T ex Remote Desktop som jag inte har hittat någon Windows-motsvarighet till än".

Och sedan är det ju rätt värdelöst att jämföra äpplen och päron. Apple RDs motsvarighet är produkterna jag radade upp, allafall om vi tittar på vilket problem de löser. Medan MS RD enbart är just remote desktop.

Apple Screen Sharing och Microsoft Remote Desktop är motsvarigheter däremot.

Så säg att du har 12gb ram. Och du kör Safari i 32bit-läge och kärnan i 32bit också. Då kan dessa tillsammans bara nyttja max 4GB av samma minne. Däremot din 64bit-app kan nyttja allt adressutrymme som är över de första 4GB RAMen. Men den processen är låst till att max kunna nyttja 4GB RAM pågrund av att kärnan inte kan adressera mer än 4gb av adressutrymme. Så du kan med detta exempel max adressera 8GB RAM. Vill du nyttja dina extra 4GB RAM får du starta ett till 64bit-applikation för detta.

Du måste köra en 64bit-kärna för att en process ska kunna nyttja ett större adressutrymme för varje enskild process. Detta gör att tex ett program som Photoshop, om du vill att photoshop ska kunna nyttja mer än 4GB RAM. Måste både kärnan och photoshop vara 64bit. Om båda är 32bit konkurrerar de om samma mängd ram och då får max nyttja 4GB tillsammans. Om photoshop är 64bit kan den nyttja 4GB RAM utan att behöva dela den med andra 32bits-processer eller 64bitsprocesser för den delen om du har tillräckligt med ram.

Apples Remote Desktop är ju en barnleksak i jämförelse med IBM Tivoli, Microsoft System Center, Novell ZenWorks, Symantec Alitris etc. när det kommer till managering, fjärrstyrning, inventering, distribuering osv.

Fast det är nog en sanning med modifikation. Det finns ett väldigt bra stöd för inloggning. Men inget stöd alls för policy-styrning över olika plattformar. Men policy-styrningen från Microsoft GPOerna är ju enbart för windows som det kommer aldrig ske. Så det är väl kanske inte Apples fel, men de skulle åtminstone kunnat öppna upp apierna som policies kan föras över med så kanske produkter för att brygga Group Policies från Microsoft dyker upp. Open Directory levererar policystyrning för macarna till en viss begränsad nivå, så någon form av API finns ju.

Däremot så håller jag definitivt med att OS X inte riktigt är anpassat för större företag. Finns ett ganska marginellt utbud av applikationsdistributionsmjukvaror eller stöd för virtuella applikationer. Vilket gör att större organisationer aldrig riktigt kan leverera applikationerna på samma vis som man kan till Linux och Windows. Även stöd för olika former av smartcards osv. är begränsat.

Apples fokus är underhållning och det betyder att man kompromissat bort företagens behov.

Alltså egentligen är det ju ingen större skillnad mot hur det ser ut bland de vanligaste linuxdistrosen idag.

Suse har Yast
Ubuntu har Aptitude
Redhat har Yum.

jag skulle tro att den absoluta majoriteten av användarna kör nästan enbart sina applikationsinstallationer genom detta.

Inget säger ju att att apple måste låsa något, de behöver bara erbjuda en altenativ kanal som erbjuder installation och avinstallation, precis som i linux.
Man skulle ju kunna säga att det är rätt jäkla knöligt att packa upp en tarboll, kompilera och installera program där med. Så pass krångligt att man allafall generellt skulle kunna kalla det att begränsa användarens möjligheter att installera program. Framförallt avinstallera program också, för make uninstall är ju inte direkt en smart lösning för att bli av med installetad data. Det tar ju bara bort omodifierade installationer.

Tror ni Powerbook G5 äntligen kommer?

Det var seriöst länge sedan det var ett event utan iphonen som main focus. Detta ser jag fram emot.

Det verkar ju lite wild'n crazy. Betyder detta att jag måste raka mig?

Vi får se hur det blir, brukar ju bli så sent med mat om man ska vänta på dig. Du som sölar omkring på morgonen och är på jobbet när jag äter min lunch

Jag dyker upp, säkert strax innan 18. Eventuellt kommer jag inte att äta ute, första gången tror jag det blir då. Men jag får väl kompensera med några extra öl

Det där kan jag inte riktigt hålla med om. Visst, om du inte är van med servermjukvaror kanske det är lite knöligt. Men vet du hur en katalogtjänst fungerar så är detta inte alls så svårt. Jag talar nu bara ur personlig erfarenhet och jag kanske är lite för mycket utav en unixnörd för att göra ett bra uttalande för gemene man.

Bör vara ungefär som en macbook, tror nog att det var med lite överdrift. Men allt är ju relativt och jämför man med en Mac Pro eller liknande så blir ju maskinen lite långsammare

Tja. Jag vet inte heller riktigt vad som hänt med våra idéer. Vi har väl lite för mycket jobb och för vissa dessutom familj ibland för att få tid med allt.

Så en vanlig macpubb kan väl vara trevligt. Den 13e september byter jag dock jobb, så jag undviker gärna en pub under första arbetsveckan för att orka med. Men veckan innan fungerar säkerligen bra. Jag vet också att det finns en del mac-människor på nya arbetsplatsen, endel är även reggade här på 99. Så jag ska väl försöka få med mig lite folk också så småningom.

Trevligt med att någon ny verkar vilja dyka upp.
Välkommen yabbah, för jag tror inte jag sett dig tidigare.
Stämmer adressen i din profil, Hagag 93? Jag är själv uppväxt några hus bort på Hagag. 99. Mina föräldrar dock också flyttat därifrån sedan 5år sedan tror jag det var.