Denna delen av 99 uppdateras inte längre utan har arkiverats inför framtiden som ett museum.
Här kan du läsa mer om varför.
Mac-nyheter hittar du på Macradion.com och forumet hittar du via Applebubblan.

Siracusa om vad som kan bli Apples nya Copland

Tråden skapades och har fått 45 svar. Det senaste inlägget skrevs .
Skriv svar
#1

John Siracusa, som inte behöver någon närmare introduktion nuförtiden, skriver om vad han tror kan bli Apples nästa Copland om de inte redan nu jobbar på att förhindra det:

Avoiding Copland 2010

För de som inte var med på den tiden så var Copland Apples kodnamn på projektet att lägga till två viktiga bitar till macens operativsystem, nämligen "memory protection" och "preemptive multitasking" (det förra går lätt att översätta, borde vara "skyddat minne", men det senare vågar jag mig inte på). Avsaknaden av dessa två finesser hade gjort att Apple hade halkat efter ordentlig när det gällde tekniska fördelar med operativsystemet. Siracusa skriver:

Classic Mac OS, as it's now known, had a decade-long honeymoon period. From its release in 1984 until 1994, it enjoyed a healthy development life that included several major revisions. But by 1994, the limitations of the OS were apparent to technophiles both inside and outside Apple. Sure, there was a lot of legacy cruft from the 80s in what was then known as System 7, but the real problems were more fundamental. These problems were so well-known that I'm sure anyone who was a "PC enthusiast" back in those days can rattle them off. Classic Mac OS lacked two very important features. Say it with me, folks:

[CENTER]Memory protection and preemptive multitasking[/CENTER]

In the early 1990s, Apple created the Copland project to add these two features to its operating system. Yes, a lot of new end-user features were going to be added as well, but memory protection and preemptive multitasking were Copland's raison d'être.

Funny story—as it turns out, it wasn't too easy to add these features to classic Mac OS while also maintaining backward compatibility with existing software. Oh, and did I mention that Apple switched processor architectures around this time as well? By 1996, the Copland project was dead, and classic Mac OS still lacked memory protection and preemptive multitasking.

Han fortsätter med att berätta vad han tror kommer att bli de två finesser som kan få dagens OS X på fall:

Here's what I think will quickly become Mac OS X's most glaring technical limitation, and what could lead to another Copland-style disaster if Apple isn't careful. Here's what Mac OS X is missing today that will be very difficult to add later without causing big problems for existing software and developers:

[CENTER]A memory-managed language and API[/CENTER]

Det hela är rätt tekniskt, men grundpoängen är att detta är bitar som Microsoft redan jobbat i flera år med och där de ligger miltals före Apple:

As was the case with the memory protection and preemptive multitasking crisis, Microsoft is way out ahead on the memory-managed language/API front. MS has its own new programming language, C#, and is working on an all-new memory-managed API to supplant the venerable C-based Win32 API. These are both projects that were started years ago, and that are finally coming to fruition today.

Jag är inte tillräckligt insatt i det tekniska bitarna för att förstå exakt vad finesserna innebär, men jag litar på att Siracusa vet vad han talar om. Om han har rätt hoppas jag Apple också jobbar på detta, så att OS X fortsätter att vara Världens Bästa OS även 2010.

Läs gärna kommentarerna efter texten också, där finns både de som håller med och de som inte gör det.

Anmäl Ändra Svara
#2
  • Oregistrerad ●
  • 2005-09-28 12:39

New APIs are extremely risky and hard to pull off, of course. Plus, Apple's just coming off a big transition, moving from the Mac Toolbox to Carbon and, for new development, to Cocoa. It's way too soon to even think about another move, right? Sure, if you're a developer. But if you're Apple, you'd damn-well better be thinking about it—not only thinking about it, but beginning work.

Det borde rimligtvis gå att göra en smooth övergång mellan manuell minneshantering och abstraherad sådan med garbage collection. Visst kommer det att kräva ändringar i API't men det har vi ju sett mellan varje 10.x stegning och hittils verkar varken de stora kanonerna (Adobe, etc) eller de mindre haft problem att hänga med i svängarna och leverera. Vem vet, de kanske tom inför memory management i samband med övergången till IntelCPU'erna..!

Anmäl Ändra Svara
#3

Frågan som historien kommer att besvara är väl hur ofta man behöver göra om ett operativsystem från scratch och hur ofta man kan bygga vidare på det man har.

Sen är det Copeland. Copland tror jag var en film.

Anmäl Ändra Svara
#4
Ursprungligen av Anders Täpp:

Sen är det Copeland. Copland tror jag var en film.

http://en.wikipedia.org/wiki/Copland

Anmäl Ändra Svara
#5
  • Medlem ●
  • 2005-09-28 16:16

Copland är uppkallat efter den amerikanske kompositören Aaron Copland.

http://en.wikipedia.org/wiki/Aaron_Copland

Anmäl Ändra Svara
#6

Skumt... jag var bombsäker på det där... har absolut inget minne av att man läste det som cop-land dvs med samma uttal som snut-ordet.

Kontrollerade innan inlägget med sökning och Apple Copeland har 6 ggr fler träffar på Google än Apple Copland. Kan det vara en felskrivning som spritt sig tro?

Anmäl Ändra Svara
#7

Om man går till wikin för copeland så avslutas första stycket:

"Apple Computer also spelled the name of their Copland project without an "e"."

Uttalet är alltså Copeland men inte stavningen. Där har det nog smugit sig in en del felstavningar och missuppfattningar genom åren.

Anmäl Ändra Svara
#8

Anders: Jag skrev faktiskt Copeland när jag skrev trådens rubrik först, innan jag postade den. Men sen kollade jag upp vad Siracusa hade skrivit och rättade mig efter honom. Så du är inte ensam om det, speciellt som, som du påpekar, uttalet var Copeland.

Anmäl Ändra Svara
#9

Adrian, du behöver inte direkt oroa dig för hans ordbajseri. Operativsystem och programmeringsspråk är inte direkt så himla tight sammankopplade som han försöker framställa det.

Unix är över 20 år gammalt.

Det han kallar "memory-managed" languages sysslade folket på MIT med på 70-talet i och med Lisp/Scheme.

Det finns en enkel tumregel, crap doesn't survive.

Anmäl Ändra Svara
#10
  • Medlem ●
  • Gävle
  • 2005-09-29 01:18
Ursprungligen av BobbyGBG:

Adrian, du behöver inte direkt oroa dig för hans ordbajseri. Operativsystem och programmeringsspråk är inte direkt så himla tight sammankopplade som han försöker framställa det.

Om du läser kommentarerna på artikeln så framgår det att det inte är riktigt så han menar, vad han syftar på är svårighetsgraden i största allmänhet, inte att det skulle vara svårt att "kila in" i operativsystemet utan att bygga ett API överhuvudtaget är en rätt komplicerad affär.

Jag håller med John i att avsaknaden av ett minneshanteringsbefriat språk och API är en av de stora nackdelarna med Mac ur en programmerares perspektiv, och därtill mer nu än för bara några år sedan, eftersom Microsofts .NET-plattform har visat hur smidigt det faktiskt kan vara att bygga "riktiga" applikationer med ett minneshanteringsfritt API och högnivåspråk (som dock, i .NET-exemplet, tillåter programmeraren att dyka ned i minneshanteringsträsket för de där få men nödvändiga minneskänsliga funktionerna).

Jag är själv programmerare, men kan inte ens föreställa mig koda Obj-C, eftersom jag har vant mig vid att jobba med språk på högre nivå. Rent procentuellt så tror jag de flesta andra programmerare tycker ungefär likadant, med tanke på att Java och .NET (som båda har inbyggd minneshantering) är de absolut mest populära utvecklingsplattformarna, samt att samtliga andra språk som snabbt ökar i popularitet (främst python, ruby, perl) också har inbyggd minneshantering.

Anmäl Ändra Svara
#11
Ursprungligen av tjogin:

Jag är själv programmerare, men kan inte ens föreställa mig koda Obj-C, eftersom jag har vant mig vid att jobba med språk på högre nivå. Rent procentuellt så tror jag de flesta andra programmerare tycker ungefär likadant, med tanke på att Java och .NET (som båda har inbyggd minneshantering) är de absolut mest populära utvecklingsplattformarna, samt att samtliga andra språk som snabbt ökar i popularitet (främst python, ruby, perl) också har inbyggd minneshantering.

Nu skall det ju faktiskt sägas att Objective C faktiskt har en minneshantering som är på en högre nivå är C++. En del av detta är lite av en illusion skapad av att API:et automatiskt har reference counting för alla objekt.

Dock så har Objective C från och med 10.4 äkta garbage collection. Den är dock inte supportad ännu men mest tyder på att det kommer att vara fullt stött i 10.5.

Om man bara använder Cocoa, vilket de flesta Mac-programmerare gör så behöver man i stort sett aldrig bry sig om minneshanteringen. Med en riktig GC så behöver man inte ens tänka på cirkulära referenser eller deras autorelease-funktion.

Du kanske skall testa Objective C innan då påstår saker om det som inte riktigt stämmer. Språket är förvånandsvärt högnivå för att vara byggt på C.

Jag är själv Javaprogrammerare och föredrar det språket framför Objective C. Dock så har du fel när du tror att minneshanteringen är lika jobbig som i C. Man behöver oftast inte lämna de funktioner som Cocoa ger dig, vilket gör att man oftast bara behöver malloc m.fl. när man integrerar mot existerande C-kod, eller man behöver mer prestanda.

Man kan ju också använda Java när man programmerar Cocoa, men Applehar ju stoppat vidareutvecklingen av Java-API:erna. Trots att jag gillar Java så kan jag förstå varför. API.erna är extremt idiotiska. De är konverterade från Objective C-API:erna vilket gör att de inte beter sig som vanliga Java-API:er skall göra. Det innebär också att Cocoa-Java inte använder t.ex. Collection utan Cocoas motsvarighet. De flesta API:erna blir dubblerade och de är inte kompatibla alls. Detta gör det enormt jobbigt om man skall integrera existerande Java-kod.

Det som skulle behövas är ett nytt Cocoa-API för Java, som är designat för hand som ett riktigtAPI skall vara. Inte som idag då det är påhängt på sidan av Objective C.

Jag vill dock också nämna att jag inte ghåller med det som skrevs i det första inlägget (jag har inte läst artikeln). Copeland var ett helt nytt operativsystem så vitt jag vet. En total omdesign som inte var bakåtkompatibel med tidigare versioner. Jag tror att de skulle lösa bakåtkompatibiliteten på liknande sätt som OSX löste OS9-kompatibiliteten med Classic.

Om man gör ett nytt API för Cocoa för ett annat språk så skulle det inte på något sätt påverka det existerande systemet på något sätt.

Anmäl Ändra Svara
#12
  • Medlem ●
  • Gävle
  • 2005-09-29 10:38
Ursprungligen av lokedhs2:

Du kanske skall testa Objective C innan då påstår saker om det som inte riktigt stämmer.

Vad har jag påstått som inte riktigt stämmer?

Ursprungligen av lokedhs2:

Dock så har du fel när du tror att minneshanteringen är lika jobbig som i C.

Det tror jag inte, och det har jag inte påstått heller?

Anmäl Ändra Svara
#13
Ursprungligen av BobbyGBG:

Adrian, du behöver inte direkt oroa dig för hans ordbajseri. Operativsystem och programmeringsspråk är inte direkt så himla tight sammankopplade som han försöker framställa det.

Unix är över 20 år gammalt.

Det han kallar "memory-managed" languages sysslade folket på MIT med på 70-talet i och med Lisp/Scheme.

Det finns en enkel tumregel, crap doesn't survive.

För att fortsätta med svengelska: With all due respect, jag har ganska högt förtroende för vad John Siracusa skriver när det gäller tekniska detaljer, så jag antar att han har rätt.

Anmäl Ändra Svara
#14
  • Medlem ●
  • Gävle
  • 2005-09-29 11:12
Ursprungligen av Adrian B:
Ursprungligen av BobbyGBG:

Adrian, du behöver inte direkt oroa dig för hans ordbajseri. Operativsystem och programmeringsspråk är inte direkt så himla tight sammankopplade som han försöker framställa det.

För att fortsätta med svengelska: With all due respect, jag har ganska högt förtroende för vad John Siracusa skriver när det gäller tekniska detaljer, så jag antar att han har rätt.

Siracusa hävdar inte att denna utmaning är svår på samma sätt som gamla Copland var, det är ett missförstånd från BobbyGBGs sida.

Anmäl Ändra Svara
#15
Ursprungligen av BobbyGBG:

Det finns en enkel tumregel, crap doesn't survive.

Tyvärr är det alltför ofta inte så. Det är snarare så att den första halvtaskiga lösningen kan bita sig kvar i decennier. Extremt bra lösningar faller bort för att de inte var först, eller för att de som har makten av politiska skäl inte satsar på det.

"Det här planet är en dröm, señor. Det flyger, señor!!!" (Citat Jaques Devos.)

Anmäl Ändra Svara
#16
Ursprungligen av BobbyGBG:

Det han kallar "memory-managed" languages sysslade folket på MIT med på 70-talet i och med Lisp/Scheme.

[...]

Mitt tips. Bygg en Smalltalk-platform ovanpå Unix grunden. Lär hålla i minst 50 år.

Han tar upp Lisp och Smalltalk i den senaste artikeln.

What about Lisp or Smalltalk, for example? Both languages are open enough to borrow and re-brand, and both are "managed" languages in the modern sense of the word.

Anmäl Ändra Svara
#17

Förstår inte kritiken. Igår installerade jag Lispworks och jag har full tillgång Cocoa utan att behöva hantera vare sig minne eller något annat.

Jag vill inte ha ett högnivå API mot OS:et - det skulle aldrig falla någon in att göra något sådant.

.Net och Java som det talas så varmt bygger sina API:s OVANPÅ lågnivå API:S.

Att sedan dra in scriptingspråk som ruby/python eller försöka jämföra Obj-C med Java är ju helt befängt.

Anmäl Ändra Svara
#18

Siracusa har följt upp sin artikel med en andra del: Avoiding Copland 2010: Part 2

In Avoiding Copland 2010, I described two Apple OS crises: one in the past (the lack of memory protection and preemptive multitasking) and one that potentially lurks in the future (the lack of a memory-managed language and API). Many readers focused on the technical details of the two features, noting how one is a change to the core OS and the other is purely additive. But the analogy I was making does not hinge on the technology. It's the circumstances that are similar.

I was looking back on the situation that led to Copland—an increasingly pressing need for Apple's OS to have features that contemporary developers would eventually come to expect—and then looking into the future in order to determine where and how Mac OS X might find itself in a similar situation.

Anmäl Ändra Svara
#19

Blir förbluffad över att han vågar sig på att levera ännu mer strunt istället för att fokusera på själva poängen, Apple behöver fundera över hur man tänker möta utvecklarnas framtida krav.

Mitt tips. Bygg en Smalltalk-platform ovanpå Unix grunden. Lär hålla i minst 50 år.

Kolla Dan Ingalls och Alan Kay sjukt imponerade projekt Squeak.

http://www.squeak.org/

Ladda ner och lek.

Anmäl Ändra Svara
#20
  • Medlem ●
  • Gävle
  • 2005-10-01 20:10
Ursprungligen av BobbyGBG:

Blir förbluffad över att han vågar sig på att levera ännu mer strunt istället för att fokusera på själva poängen, Apple behöver fundera över hur man tänker möta utvecklarnas framtida krav.

Det är ju det som hans artiklar handlar om!!!???

Anmäl Ändra Svara
#21

Nä.

Artikeln handlar om en förvirrad journalist som läst till sig vad Microsoft sysslar med på utvecklarfronten och försöker lyfta fram nya teknologier som WinFX, C#, etc. som någon slags måttstock på vad Apple måste göra i framtiden.

Anmäl Ändra Svara
#22
  • Medlem ●
  • Gävle
  • 2005-10-01 22:09
Ursprungligen av BobbyGBG:

Nä.

Artikeln handlar om en förvirrad journalist som läst till sig vad Microsoft sysslar med på utvecklarfronten och försöker lyfta fram nya teknologier som WinFX, C#, etc. som någon slags måttstock på vad Apple måste göra i framtiden.

Den förvirrade journalisten är en av världens mest ansedda Mac-kommentatörer. Att utvecklingen inom programmering alltid går mot högre språk förstår jag inte hur du möjligtvis kunnat missa.

Anmäl Ändra Svara
#23
Ursprungligen av tjogin:

Den förvirrade journalisten är en av världens mest ansedda Mac-kommentatörer. Att utvecklingen inom programmering alltid går mot högre språk förstår jag inte hur du möjligtvis kunnat missa.

Vem bryr sig om han är ansedd eller inte?

Utvecklingen har inte gått någonstans de senaste 20 åren. Vi är fortfarande kvar på 70-talet.

Det tog t.ex. 20 år innan ett mainstream-språk introducerade s.k garbage collection.

Språk som t.ex C#, Ruby och Python är inga jättekliv framåt utan snarare ett par steg åt sidan.

Anmäl Ändra Svara
#24
  • Medlem ●
  • Gävle
  • 2005-10-02 13:41
Ursprungligen av BobbyGBG:

Utvecklingen har inte gått någonstans de senaste 20 åren. Vi är fortfarande kvar på 70-talet.

Det är skillnad på att språk bara existerar och används av ett fåtal, och att majoriteten av programmerarna i världen använder dem. För tio år sedan använde inte majoriteten av alla programmerare i världen ett högnivåspråk med GC, det gör de nu. Jag antog felaktligen att detta var något du förstod.

Anmäl Ändra Svara
#25
Ursprungligen av BobbyGBG:

Blir förbluffad över att han vågar sig på att levera ännu mer strunt istället för att fokusera på själva poängen, Apple behöver fundera över hur man tänker möta utvecklarnas framtida krav.

Mitt tips. Bygg en Smalltalk-platform ovanpå Unix grunden. Lär hålla i minst 50 år.

Ah, så det är inte strunt att utlova hållbarhet i 50 år?

Ursprungligen av BobbyGBG:

Artikeln handlar om en förvirrad journalist som läst till sig vad Microsoft sysslar med på utvecklarfronten och försöker lyfta fram nya teknologier som WinFX, C#, etc. som någon slags måttstock på vad Apple måste göra i framtiden.

Förvirrad journalist? Det är en av de mest tekniskt kunniga skribenterna om mac som finns. Det betyder förstås inte automatiskt att han har rätt i allt han skriver, men det brukar oftast vara väldigt genomtänkt och tekniskt korrekt.

Jag kan inte detaljerna tillräckligt bra för att argumentera om teknikerna, men visst låter det rimligt att vi går mot högre nivåer på programmeringsspråken. Det är ju inte många som sitter kvar i assembler idag.

Men om du nu tycker att han skriver så mycket strunt, varför inte bemöta honom med dina djupa tekniska kunskaper eftersom du uppenbarligen kan mycket mer än honom? Skriv en kommentar på hans artikel och så får vi se hur man bemöter det.

Anmäl Ändra Svara
#26
Ursprungligen av tjogin:

Det är skillnad på att språk bara existerar och används av ett fåtal, och att majoriteten av programmerarna i världen använder dem. För tio år sedan använde inte majoriteten av alla programmerare i världen ett högnivåspråk med GC, det gör de nu. Jag antog felaktligen att detta var något du förstod.

Ingen idé att försöka gömma sin inkompetens bakom fånga kommentarer.

Ursprungligen av Adrian B:

Ah, så det är inte strunt att utlova hållbarhet i 50 år?

Tja, i och med att Alan Kay & Co började bygga det blev Smalltalk redan under 60-talet så har jag inga som helst problem med en sådan gissning. Du tycker att det är strunt av det enkla skälet att du inte har någon som helst aning vad jag syftar på:

History of the GUI.
http://arstechnica.com/articles/paedia/gui.ars/1

Ursprungligen av Adrian B:

Jag kan inte detaljerna tillräckligt bra för att argumentera om teknikerna, men visst låter det rimligt att vi går mot högre nivåer på programmeringsspråken. Det är ju inte många som sitter kvar i assembler idag.

Naturligtvis. Men att försöka lyfta fram ett "managed" API som något jätteviktigt i och med den närmsta framtiden problem med multipla cores i processorna känns fruktansvärt korkat.

Citat:

Men om du nu tycker att han skriver så mycket strunt, varför inte bemöta honom med dina djupa tekniska kunskaper eftersom du uppenbarligen kan mycket mer än honom? Skriv en kommentar på hans artikel och så får vi se hur man bemöter det.

Kommentarer som denna upphör aldrig att förvåna. Du saknar kunskap att avgöra om kritiken jag framför är vettig och vad gör du? Försöker lasta över ansvaret på mig?

Läs kommentarerna till hans artikel så förstår du att många redan framfört kritik - som artikelförfattaren tyvärr väljer att ignorera.

Här är en lång kommentar som du och "tjogin" kan läsa:

"From my perspective it is a little unfair to compare the recent rise of managed code / platforms to the Copland disaster. Copland happened because Apple held on to the classic MacOS, which was already very antiquated in terms of OS technology when development of Copland started.
The features that MacOS lacked and Copland should bring, like preemptive multitasking, multithreading, memory protection and good VM support were not only things that develpers were expecting - they were a technical necvessity for any modern OS which isn't necessarily true for managed code today/tomorrow.

Those features (or the lack thereof) drastically affected the user experience. Since computers and applications got more and more complex, with the computer making inroads in new areas like multimedia you could no longer have a machine that completely locked up only because _one_ application misbehaved...

The situation with managed code today is a bit different. Though, granted, it bears some resemblance too. If you talk about managed code and APIs you have to really distinguish those two, though. You mentioned C#, CLR and WinFXas examples for a amanged environment, so I'll use them too. So, why did MS develop C# and the CLR? I believe that much motivation came from the success of - and the dispute with Sun over - Java. Java was developed as a cross-platform solution, so they obviously needed a VM to make apps run unchanged on different platforms. And they did the only sane thing to do if they were to create such a thing in the first place and abstracted away most OS details -including management of application memory. Since MS didn't want to use Java, but couldn't deny its advantages, they needed something comparable to compete with Sun.

Your most valid point in favor of managed languages is the ability of managed runtimes like the CLR or the JVM to prevent applications from clobbering their own memory, and by that plugging many potential security holes. Apple really needs to something in the future here, since this is still very possible with Objective-C/Cocoa applications. And this will be the area where managed runtimes shine the most. But still, this could be done even with keeping the Objective-C language (mostly) intact in an evolutionary way (just guessing). It's not the languages, it's the runtime system that really matters.

The second advantage you get is memory management with automatic garbage collection, which helps developers focus on the task at hand and not tedious work just to make the application run correctly.

The third major component to a managed runtime is the used API, which will be an object-oriented class library in most cases, such as the Java class library or WinFX.
When you talk about abstraction, this is the area to look at. I fully agree that a more abstracted approach to most problems will win in the long run. But you don't necessarily need a managed environment for a good abstract API. And Mac OS X has a very good abstracted high level API - Cocoa. I honestly believe Cocoa can stand beside WinFX or the Java API in terms of abstraction and features if continues to evolve.

Windows on the other hand desperately needed a new API to replace the aging procedural Win32. Though there was the MFX as an object oriented alternative, it wasn't much help since the MFC essentially was a very thin wrapper around Win32 which did not provide any OS abstraction.
To make a long story short - Mac OS X has a great API and a dynamic, simple language as its primary programming language. That leaves the runtime system, which needs to evolve much further to gain "all" the advantages that the managed environments provide.

But even here there is no immediate nor short term danger that a scenario like with Copland could resurface. If Apple keeps an eye on the issue, and continues to improve the runtime libraries and compiler (perhaps over time even by sacrificing backward compatibility), they can compete with managed environments. In my opinion, garbage collecting Objective-C would be a very nice feature and a first step in the right direction. The fact that you can still write C-code can stay an advantage for quite some time, the good thing is: You don't _have_ to write C code. Why not give developers a choice?

Yes, we need evolution in the direction of managed code, but we don't need a revolution which was required at the time Copland happened.

BTW: A word on performance:

The Java model of taking away every responsibility from the developer brings some disadvantages along too. Most of them are performance-related, and I believe performance is still (and will remain) a very important feature in a software product especially in markets where Apple is strong today. Office and "enterprise" (I hate that term) applications may not suffer much if performance degrades from introducing overhead due to a managed / virtual environment, but media / real time applications certainly do. Yes, computers get faster, but there should be a balance between abstraction / automatism and efficiency."

Anmäl Ändra Svara
#27
  • Medlem ●
  • Stockholm
  • 2005-10-02 10:17

Lite OT lite nostalgi, Adam Samuels presenterar Cop(e)land:

Real 64kb:
http://www.archive.org/stream/MacClone/MacClone_64kb.rm

Real 256kb:
http://www.archive.org/stream/MacClone/MacClone_256kb.rm

Anmäl Ändra Svara
#28
  • Oregistrerad ●
  • 2005-10-02 14:29
Ursprungligen av Kambei:

Lite OT lite nostalgi, Adam Samuels presenterar Cop(e)land:

Real 64kb:
http://www.archive.org/stream/MacClone/MacClone_64kb.rm

Real 256kb:
http://www.archive.org/stream/MacClone/MacClone_256kb.rm

Det är ju fejk!!! Titta ordentligt så ser du att han inte använder musen utan bara går fram med en pilknapp eller om det är enterknappen!!!!!!

Anmäl Ändra Svara
#29
  • Medlem ●
  • Mölndal
  • 2005-10-02 23:00

Varför denna dryga attityd? Försök hålla en vänlig ton och kom med sakliga argument, så får vi andra också ut nåt av er diskussion.

Anmäl Ändra Svara
#30

Ber om ursäkt ifall mina kommentarer är lite negativt laddade men jag blir väldigt irriterad på människor som saknar förmåga att uttrycka egna åsikter och döljer sin ignorans bakom ett fånigt idoliserande av personer som t.ex. Siracusa.

Anmäl Ändra Svara
Bevaka tråden
Nytt i forumet
Debatterade nyheter
Senaste nytt
2 Hur ser ditt julpynt ut hemma?
0 3 ljusa tips för att hålla inbrottstjuvarna borta – använd smart belysning!
12 Slutet på något gammalt - början på något nytt
5 Rykte: Apple väntas lansera en uppdaterad 27" iMac i början av 2022
22 99mac blir Macradion på en helt ny plattform
1 Macradion: Vi släpper lös kraften tillsammans
0 Apple backar på den nya designen av Safari i macOS Monterey
24 Apple släpper macOS Monterey den 25 oktober
0 HomePod mini kommer i fler färger
91 Apple presenterar MacBook Pro, M1 Pro och M1 Max
4 Apple presenterar tredje generationens AirPods
2 Så här ser du Apples event ikväll
1 Apple Watch Series 7 - är det värt att uppgradera?
0 Macradion: Unleash the MF appstore
7 Detta tror vi att Apple visar upp på eventet
1 Apple förlänger sitt serviceprogram för AirPods Pro
0 Rykte: MacBook Pro har samma leverantör av miniLED-paneler som iPad Pro
3 Apple bjuder in till event den 18 oktober
1 BaseLynx: Modulär laddstation utan gränser
1 Tile håller koll på allt från plånbok till nycklar men saknar en nyckelfunktion
0 Apple överklagar domen för betalning genom tredjepartsutvecklare i App Store
Copyright © 2024. Allt innehåll tillhör Svenska Tekniknyheter AB. Citering är tillåten om källan anges. Vi reserverar oss för eventuella informationsfel.
Om 99, RSS, Kontakta oss, Feedback, Trivselregler, Teknisk information och cookies