Sources: Intel developing next-generation Power Mac for Apple - Page 8

Considering the problems largely still exist, the document has aged better than UNIX!

The authors were by no means under any illusion that they could get people to stop using UNIX. Heck, even they couldn't stop using UNIX. The whole point of the list was for people who had to use it whether they liked it or not.

I don't recall if it's in the book, but one of the authors did praise the fact that UNIX was becoming more unified ('standardized' if you can call it that) since at least it could be pinned down and the step beyond it could hopefully be taken.

Source?

I think it's funny that you say that, because the current core of Windows has a lineage such that it was made for RISC first. I ran a RISC computer using Windows NT 4.0 for several years, it was the most dependable platform I have ever used.

Apple has made improvements to to the Unix layer. Launchd is a good example. There was resistance at first. But it's been acknowledged as being a useful advance.

Unix hasn't remained where it was. There have been other advances over the decades. None of these systems stand still.

Oddly enough, no I don't think it is...

Originally posted by JeffDM
Source? ...I think it's funny that you say that, because the current core of Windows has a lineage such that it was made for RISC first. I ran a RISC computer using Windows NT 4.0 for several years, it was the most dependable platform I have ever used.


windows NT and further OSes based on winNT codebase (afaik win2000, win2003, winxpPro???)** is the only thing microsoft has done right... but given all the security holes though \ hmmm .... **don't get all uppity with me, but if someone can clarify in a evolutionary tree type thing of current microsoft OSes based on winNT that would be great.

Heh someone wanna lock this thread???

I think its derailed so far off track it will never come back. "Sources: Intel developing next-generation Power Mac for Apple"... weird

Boy does this thread suck. I forgot that I ever posted in here.

Actually, IMHO, I think it IS. Again, I see the OS glass as half full, do you see it as half empty? It obviously works, something must be right? Again, "Nature abhors a vacuum," you must start from somewhere (i. e. what you are doing right). Start from scratch, with absolutely no previous knowledge, I DON'T THINK SO!

LOL AGREED!

I think that Programmer was referring to the fact that before you move forward you need to learn from the past. And what you learn, if you were writing code the logical is to say what went wrong and why. This gives credit to those that came before you, in that they were smart people and made mistakes. It is very possible to follow that same path, because these were smart people. We learn from our mistakes. Unix is very old, I think that Apple has done an exceptional job of forward looking, and not repeating some of the mistakes of the past. Let us face it most of what they are doing today were technologies that were considered well before OSX ever got off of the ground.

As far as Intel building the MBs, I seem to remember that they are rock solid but don't appear to use the latest technologies, a bit more tried and true. So what will be those compromises? Or is Napa and Merom chip sets cutting edge? Or more evolution with a healty dose of conserve those Watts?

I'm not sure what you means by "don't appear to use the latest technologies"?

As far as I have seen, they use all the latest and greatest.
Do you have any specific examples?

You maybe refering to the fact that they may not have the most "add-ons" such as extra RAID controllers and such which some of the more "enthusiast's" boards offer. However, if you're not a complete computer junkie, you don't miss them a bit.

Anybody who thinks Intel inside logo is not a big deal does not undesrtand what ideals Steve Jobs has stood for since the beginning. True, what makes Macs great is more than their gorgeous industrial design, but what lies beneath it: they have always been fast and far more reliable machines than their PC (Piece of Crap) counterparts. But a big Intel logo on the case would not just be a blemish but would also simbolize Apple's utter succumb to the Man. It would not simbolize a partnership between the two companies but a dominance of one over the other.

Unfortunately, fellow Mac users, all bets are off. Will Steve fold before the all mighty dollar or will he stand his ground against the cold, dry emptiness of marketing, and victoriously keep bringing users a superior computer that also reminds them of the ideal that America was founded on freedom? Freedom of thought and freedom from greed and everything that corrodes our hearts. If what we fear becomes true Apple will just become another Dell, Compaq, HP, etc...

As a creative professional I would hate having to stare at some stupid logo all the time, it would distract me from my work, and get in my way. And those who think an etched or embossed logo would be better or classier than a sticker obvioulsy don't know crap about visual design. A sticker can at least be removed (and then burned. hahaha).

Anyway, I guess we'll find out soon.

I don't think things will be as bleak as you suggest. However, perhaps except for the image thing (nee facade), Apple in most respects, is just like any other major corporation. Oops, forgot that Apple IS the current leading computer vendor that has control over both the HW and SW (Sun would be the next, I guess). IMHO, that's a good thing.

WRT, the logo (how it's branded, marketed, etcetera (the image thing)), I'd prefer something very similar to Apple's current symbol, by that I mean a symbol without words, preferably a monotone. It's clean, simple, and elegant. IMHO that's a great thing.

However, I would like to think that whatever the MACTEL branding ends up being, would be unique to that partnership (i. e. leadership in HW/SW/Industrial design). Fudge the rest of the PeeCee vendors, they get stuck with the (updated) Intel logo. IMHO, I would think both Apple and Intel would want something unique. Perhaps, the Apple logo on the sides and Apple's rebranding of the CPU (a la G3/G4/G5).

But in the end, to me, its mostly about the OS and not how the HW package (i. e. the wrapper) looks. I guess THAT would make me a real Mac fanbois .

If the new Macs were to have Intel labels or logos, wouldn't they go on the back or bottom of the unit along with the standards logo's and text (like on the base of a Mac mini)?

I think were both saying the same thing, its one of those horse and egg things .

Uuuh, I'm counting on him folding on the all mighty dollar--MINE!

Christ people. Apple sells Macs to Mac users, not Intel & Co.

I'n not sure that I understand what this part of the argument is about.

Both the good and the bad have to be examined equally.

First, you have to determine if there is something worth saving, then you have to see if the problems are so great as to overwhelm the work necessary to do so.

Sometimes, the basic ideas are good, but the implimentation is poor, or outdated. In that case, a complete reworking is required. That may simply be too much.

But if the system is basically functionable, but needs some tuning, modernization, etc., it might pay to do it.

This is true whatever it is that's being worked on. It can be software or hardware.

Decisions like this should be based on more than someone's ideals.

If an ideal is that no stickers be put on, I can see a vast amount of wasted talent going into what is a nothing area. Even if it is embossed.

Ideals should be reserved for areas such as the best, GUI, ergonomics, functionality, presentation, cost, reliability, service, software, etc.

We don't need ideals to decide whether we will have a logo on a box, or a sticker on the machine. Most people rightfully would prefer the 5 or 10% discount on the price that having that sticker might make possible.

This statement is not altogether true.

The estimate is that in 2005 (ending in Sept quarter), Apple sold about 1 million of its 4.5 million machines to Windows users. Another 3/4 million went to people who never bought a machine before.

Thid is what we need. Otherwise, Apple will be selling fewer machines each year as people get older and stop buying new machines. This was happening for several years. We DON'T need that.

It's estimated that Win buyers will be a larger number this year, as will new buyers.

Not an argument, an observation. Yes both are looked at but the bulk of the time is spent on figuring out the bad and why it went bad. If you work in a large organization this is what is done. The bad did not start out like that it went wrong, why? Was it an internal organization problem? Did external factors have any bearing on the failure and if so how much. Did we see this comming? Is so could we not react quick enough, or was it lost in translation?

You can see that in a large organization, you can fix the problem with the software or hardware but equal or more attention must be payed to the health of the organization, fixing the problem is one of scope. The problem is that the widget is no longer viable, why? If the organization is running properly it should be that all things are noticed and fixed in time. The last place you want to go is down pat on the back lane, wow we really did this well, those things should be obvious. It is the bad things that you need to identify, most are very well hidden. This is Situation Normal in a large well run organization, most of them spend their problem solving time looking internal as well as external. Bad things could happen to the person that does not identify the real problem. For example fixing the motor of a boat, while not properly identifying that the pilot had no idea where the boat or land was. Now if you are in a lake this is a small problem, if you are in an Ocean...

That can be true.

But remember that when a systen has been around for a long time, it isn't always that there are "bad" parts. They may seem bad because technology has eliminated the need for the way the system operates.

To get back to UNIX. Back when it was developed, RAM was both very expensive, and thus available, even in mainframes, in, by todays standards, very small amounts. So the system used virtual memory for most everything.

Even today, UNIX's tend to do that more than other, more modern systems. So a redesign of the memory systems is in order. That's fine. But, there's nothing "bad" about it. It just isn't required to do things that way anymore. But it doesn't sink the system either. If fact, UNIX based systems tend to have the best virtual memory systems around. And it can't go away altogether.

Besides, most of this has nothing to do with whether we are talking about a large system or organizarion or a small one.

Small bits take less work to correct, but they are also less valuble to begin with. Large bits take much more work, but thet are also much more valuble.

small organizations are the same way. They are easier to move, but have less at stake overall. If they fail, there is less loss (not to them, of course).

Large organizations move more slowly. But they have much more to lose. It isn't always good for a large organization to move too quickly on a major project. They have much at stake in present operations. Much disruption occurs. Sometimes, it;s actually cheaper, and better in the long run to make incremental changes in systems thatn it is to do a complete overhaul, which might contain major bugs.

There are numerous cases of companies and governmental agencies trying to completely overhaul their systems, only to find that they were mired in the muck.

UNIX is very much like that. It started out 40 years ago as a modern system. Today it has much legacy code, and functionality. But it has also improved over the years. Code has been dropped, and new code added. Many major OS's are still based on it. Even Linux is a copy, and not a very good one either.

True. Ideals are NOT based on the use of stickers or the use of any other media. Rather, media is used to communicate and simbolize ideals. This has been true since the early days of graphic design. Apple can use their machines as another advertising medium for a huge company like Intel, or it can keep the machine's pristine design. I would gladly pay an extra 5-10% not to be having to stare at a company's poorly designed logo while I work.

You would, and I might not mind either. I'm not constraind about price.

But, if we polled the general buying public, I'll bet they would disagree, strongly.

And that's what matters.

Or do what most UNIX programmers do: 'Fix' the user. Users must be fixed so they can use the software, no matter how convoluted the interface is.

A fresh appraisal of the desktop interface would take into account what we currently use computers for. If we use a wider use of the term "application" to mean how we use our computers, there are very few applications:

Document creation (DTP apps have a similar document-centric interface)

Console application (Many apps control some object, sometimes on a different server like IRC)

_Notices (Information display, like widgets)

I don't see why there has to be zillions of interfaces, or even zillions of programs. For example, one application is enough for all document-creation needs. Do you really need a different interface for editing photos, audio, or text? The tools or commands would change depending on the context, but there is still the concept of a document. One could reasonably expect every document to have but one window, if a window at all. Given the simplicity of the shell "application," it could easily be replaced without changing the underlying model, or even the commands/tools.

Although it had flaws, the concept of OpenDoc has awesome potential for real-world productivity gains for programmer and user alike. One problem with OpenDoc was it was only designed for document purposes, not console or notices. We can learn from this too, and create a suitable middleware API for other purposes.

I could go on, but this isn't how things are evolving. The whole UNIX paradigm since 1969 is hack&fix until something works, taking little account of what gymnastics the user has to do. This has only gotten worse with the advent of UNIX graphical programs. The creature is not evolving as one unified being, but rather mutating and spreading like a bad virus.

The methodology is what I'm attacking here. That, and the zealotry.

Open Doc was a concept in search of a market. The software industry has been there, done that and spit it out as unpalatable. Too hard to get differint sotfware vendors to place nicely together. Not that it wouldn't be nice in a perfect world that did not reflect greed, but communism is like that too, and just as successful.

Speaking as a former OpenDoc programmer and armchair economist, I would disagree on all your points.

First of all, OpenDoc had technical and marketing problems. The amount of work to get an OpenDoc 'Part' off the ground was a great technical barrier (which I only discovered in practice). The ported SOM model to Classic MacOS didn't work that well either. It was memory hungry for the times (nothing close to what a JVM eats though!). All things considered however, those technical problems would have gone away due to a) memory price and b) higher level abstractions making it easier for developers. Unfortunately Apple was bleeding red due to their Performa line disaster and pulled the plug on all projects not making money at the time. The rushed delivery was its death nell.

Second of all, you didn't need vendors to "place nicely together." The whole point of OpenDoc is if you followed the API, it would work with everything else. Vendors don't need to get along for applications to work together because they follow an IPC API.

Thirdly, the monolithic application vendors were against OpenDoc, and indeed Bill Gates at the time was interviewed and listed OpenDoc among his 10 greatest threats, but OpenDoc didn't need them to make parts anyway. This is more true now than ever.

Fourthly, Communism wouldn't work in an idealized greed-free world either. Communism fails not because of greed, but due to the inability to perform economic calculation. Ludwig von Mises proved as much when he published his essay "Economic Calculation In The Socialist Commonwealth" (1920) which became the basis for this book, "Socialism" (1922).

http://www.econlib.org/library/Mises/msS.html

The problems of OpenDoc can be directly laid at Apple's feet. Corel had a whole slew of software done or OpenDoc. So did others. But Apple dropped the ball there. The entire Copeland project went down in flames. some of it returned in small part in OS 9, but OpenDoc was allowed to die.

It's a shame really.

In a way I think it's a shame, but it could have only succeeded had it been designed differently. In spite of being middleware, the API was still monolithic in nature as every part had to implement a complete set of functions and the bento format wasn't interoperable. I suppose you could say the same about Office...

My only point in bringing it up was to challenge the whole <i>concept</i> of the application/program. If the dev environment was the interface, programs could run from that interface instead of a shell.

I just read the wikipedia entry for OpenDoc, and it's pretty good actually (especially the "Problems" and "Insider's Take" chapters):

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

I still like the concept that Apple was trying with Newton, and to a certain extent with OpenDic.

That concept was that the program was the OS, and the OS was the program. Each new program added would become part of the whole, and that you could call up whatever part you needed for a particular use. You wouldn't find a "Finder" and programs to get, but rather a "sea" of parts floating within reach, just pluck out what you wanted. Everything would just work together.

An advanced concept, but it never really got off the ground. Really too bad.

OpenDic !?!?



I liked the concept, but really must say that we are closer to the dream of OpenDoc today than we've ever been: Cocoa's Frameworks.

There was an OpenDoc word processing module, web module (CyberDog), and a few more. Well, gee, you can build your own word processing app in just a few lines of ObjC and call straight to the frameworks that offer spell-check, font management, document window management, etc. We've got WebKit. If you took OpenDoc and moved the integration process a step or two back into the application design process, then you've got it right now, pretty much.

OpenDoc, the idea of being able to build suite applications based on individual lego-like parts, was a software engineering wet dream, not something that an end user would much think about. Sure, we might like to link Word and Excel (and MS did that for us), but a very, very small number of people would want to link a CAD program to Word with super tight integration. You might want to import a drawing image and even update it when it changed, but you'd not want to draw in new walls in Word....

to me, that sounds a bit like how you work in a typical shell, with text files being a (very) primitive document standard...

Interesting for a rebuttal that you confirmed all my points. Thanks!

It's not quite the same thing. The idea wasn't to be able to build your own. Not from the users point of view. It should be transparent for the user.

The idea wasn't to link Word with a CAD program. The idea was to link PART of Word (or any text editor) to the PART of the CAD program that you needed at that moment. You could pull simple modules out as you needed them. from a menu perhaps. The way we pull the spell check into any program that can use it. Or the speech module.

But it isn't even that. Each module wouldn't necessarrily be part of one big program. Each would stand on its own, be integrated into the OS so that it could avail itself of the services of the OS natively.

So you could call a simple 2D CAD module to do a basic drawing, call a texteditor to do the descriptions and labels directly in the drawing, and then call up a spreadsheet module to enter the numbers for the costing process. Each module could be dismissed as soon as it was no longer needed, though the results would remain as part as the file you were working on. All files would fit into one extensible structure that every module could link with.

I know that this goes a bit further than the original idea, but not by much, and it does make sense. It would certainly enhance productivity, and require less memory.

Large programs like CAD/CAM are already broken into parts, but I'm talking about much finer granularity.

Good discussion following my posts -- I'm glad I posted and then didn't respond. Now that the discussion seems to have run its course I thought I would just toss in my response...


When looking at re-building a system it is usually more instructive (and more difficult) to look at the system's problems. The system's good features are usually designed into it based on good design practices/patterns, careful analysis of the requirements, and (hopefully) solid experience of the designer. The bad parts of the system are usually what was not considered or planned carefully. If you ignored the previous system and started again from scratch it is quite likely you'd go through more or less the same processes and end up with many or all of the good points... and most of the bad points.


Now this is all a discussion of generalities, and there are always exceptions. Sometimes decisions are made at random or on an intuitive whim and they turn out to work wonderfully. Equally often they turn out dreadfully. All I'm saying is that when starting the redesign or refactoring process, take a look at the bad whims and the unconsidered elements first because that is probably your most fertile ground for improvement. The good parts are already good and it is usually straightforward to re-include them in your design, the bad parts can be deeply endemic and harder to eliminate.

OpenDoc

This seemed to fail for the same reason the Taligent and Copland failed. Overly complex designs that put too much burden on the module/part developer. The intro to chapter 4 of Hillgrass' Cocoa programming book sums it up nicely -- he had a demo from one of the Taligent programmers, but when he asked for a fairly simple refinement to the demo, the Taligent guy got buried in the code needed to do it.

Much of this problem derives (pun intended) from the now dated notions about how and when to use object-oriented inheritance. NextStep was way ahead of its time in how it attacked OOD problem (or perhaps everyone was just behind the times for 10-20 years thanks to C++). I remember being quite enthused by some of the technology behind OpenDoc (SOM, in particular) until I tried to use it... then I went and found other more interesting things to do.

The rest of the problem comes from allowing too many programmers to get too caught up in the coolness of the thing they are building instead of obsessing about the coolness of what people will build with the thing they are build. This seems to happen a lot and I'm sure that almost all programmers have been guilty of it at some point in their careers (usually the early part before they learned better) -- evidently there were too many of them at Apple all at once in the early 90's.

A problem with the basic OpenDoc model (given that document-centric design is the way to go) is that its not clear that a generic system can express the potential interactions needed for satisfactorally integrated parts. It always felt a bit clunky in ways that a properly built app doesn't. And its not clear that you really want to combine all of those wonderful hypothetical things in a single document anyhow.

I'm not sure that I'd compare frameworks to OpenDoc in any way, but I do agree that frameworks looks like a much more successful software engineering paradigm.

It also didn't have the benefit of time to work out its problems. Apple's resources at the time were stretched, to say the least.

Copeland also failed because the groups working on it in their own separate areas put more emphasis into their own little worlds rather than seeing whether everything integrated. There was a great deal of secretiveness between the groups back then. Nothing successful ever comes out of uncoordinated efforts.

This is where good management comes in.

Absolutely. And it's not only the need to combine a multitude of datatypes that is questionable, it is the very fact of this multitude in the first place. There are really only a few datatypes that most people need, and so a tightly integrated suite (e.g. Office) will do just fine.

I see your point, perhaps you saw mine?

my favorite quotes are;


and,

strobe,

I'm sure many (if not most) of your OS ideas are quite good. However given the existing OS landscape (including applications and user base), starting over (I've lost count of how many times I have thought of this), while worthwhile, would be extremely difficult. In military lingo, "Lessons Learned," is extremely valuable (i. e. what do you (or can you) change going forward)).

To paraphrase Sir Isaac Newton;

The force (nee momentum) necessary to overcome the OS mass (nee inertia) would be HUMONGOUS!

or more precicely;

My'' + Cy' + Ky = F

where for linear 6-DOF rigid body motions and mass conservation, M, C, K are constants (6 by 6 matricies for mass, damping, and stiffness), F is the time dependent variable of forces and moments acting on the rigid body (6 by 1 vector), and y'', y', and y are (6 by 1 vectors for surge, sway, heave, roll, pitch, and yaw) the acceleration, velocity, and displacement of the rigid body. Usually, F is known (i. e. rocket engine thrust), and the equation is rewritten to solve for y (i. e. where is the Battlestar Galactica now).

Oh yes, absolutely. In no way do I advocate looking at only what went wrong, that would be silly. If a designer first internalizes what the problems are with the previous approach then he can search for better solutions while examining the existing ones. Having this context in fact makes the examination of what worked more useful.

This is much like going to a Stevenote aware of what he is going to announce -- it means you are much better prepared to critique it, and thus guard against the RDF. If you go in completely unawares the RDF is much more likely to sweep you off your feet.