1 |
On Mon, 10 Dec 2012 20:06:58 +0000 (UTC) |
2 |
Grant Edwards <grant.b.edwards@×××××.com> wrote: |
3 |
|
4 |
> On 2012-12-10, Alan McKinnon <alan.mckinnon@×××××.com> wrote: |
5 |
> > On Mon, 10 Dec 2012 19:06:36 +0000 (UTC) |
6 |
> > Grant Edwards <grant.b.edwards@×××××.com> wrote: |
7 |
> > |
8 |
> >> On 2012-12-10, Volker Armin Hemmann <volkerarmin@××××××××××.com> |
9 |
> >> wrote: |
10 |
> >> > Am Samstag, 8. Dezember 2012, 19:25:55 schrieb Grant: |
11 |
> >> > |
12 |
> >> >> It seems like ARM processors will destroy x86 before too long. |
13 |
> >> >> Does anyone think this won't happen? |
14 |
> >> > |
15 |
> >> > no |
16 |
> >> > |
17 |
> >> > two reasons: |
18 |
> >> > |
19 |
> >> > not enough power |
20 |
> >> > does not run x86 software |
21 |
> >> > |
22 |
> >> > the second one is a real deal breaker. |
23 |
> >> |
24 |
> >> Only until somebody invents some sort of scheme where you can |
25 |
> >> write a program using a source language that isn't tied directly |
26 |
> >> to the processor architecture. Then you'd be able to build |
27 |
> >> programs (or even OS kernels) so that they'd run on a variety of |
28 |
> >> CPU architectures! |
29 |
> > |
30 |
> > We can do that *already* |
31 |
> > |
32 |
> > java |
33 |
> > perl |
34 |
> > python |
35 |
> > dotnet |
36 |
> > and any number of other languages compiled to bytecode. There's too |
37 |
> > many to list. |
38 |
> |
39 |
> I know. :) |
40 |
> |
41 |
> And even if you stick with old-school compiled languages to C, |
42 |
> supporting multiple architectures isn't any more difficult than |
43 |
> supporting the plethora of x86-based motherboards and chipsets. |
44 |
> |
45 |
> * Apple transitioned from 68K to PPC to x86 without much problem, |
46 |
> and they don't seem to have any problem getting software to run on |
47 |
> ARM devices. |
48 |
|
49 |
Apple tightly controls the entire computer end-to-end and they know |
50 |
*exactly* what is already on the user's machine: |
51 |
|
52 |
How many kinds of video cards: 1 |
53 |
How many kinds of screens: 1 |
54 |
How many drive types: 1 |
55 |
How many optical drive types: 1 |
56 |
How many boot methods: 1 |
57 |
I could go on, but you get the point. The larger part of the variable |
58 |
factors simply don't exist for Apple to the same degree faced by |
59 |
Windows and Linux. This makes a migration several orders of |
60 |
magnitude easier for Apple. |
61 |
|
62 |
> |
63 |
> * Linux is available for non x86 platforms. :) |
64 |
|
65 |
Only by a monumental crowd-source effort never before witnessed in the |
66 |
history of engineering. |
67 |
|
68 |
When Apple migrate CPUs (they have now done it three times), they tweak |
69 |
a few compile settings, write a few new drivers for new hardware, and |
70 |
run make. A surprisingly large chunk of the code base builds fine. A |
71 |
relatively small team takes care of the rest. |
72 |
|
73 |
The same action on Linux takes somewhat longer, and considerably more |
74 |
effort while the vast army of suckers^Wvolunteers and concentrate on |
75 |
their little bit while waiting for the reverse-engineering lads to |
76 |
finish doing their thing. |
77 |
|
78 |
|
79 |
> |
80 |
> Nobody has developed significant applications in assembly language for |
81 |
> decades, so I don't see why there's a requirement to "run x86 |
82 |
> software"... |
83 |
|
84 |
I don't get your point. |
85 |
|
86 |
Are you talking about code finely-hand-tuned to run on a specific cpu? |
87 |
|
88 |
The kinds of software the average user really wants to run are very |
89 |
much tied to the hardware: |
90 |
|
91 |
kernel |
92 |
drivers |
93 |
boot code |
94 |
media players |
95 |
codecs |
96 |
|
97 |
It's true we don't hand tune each app to the cpu anymore, we hand tune |
98 |
the compiler to the cpu. |
99 |
|
100 |
> I use a couple of large, commerical Java apps under Linux and they |
101 |
> both work great. OTOH, some of the smaller "free" Java apps I've |
102 |
> tried were pretty bad... |
103 |
|
104 |
I'm not sure what you mean by this. Code quality varies, this is always |
105 |
true. |
106 |
|
107 |
The best quality proprietary code I've experienced was from Sybase. |
108 |
The worst quality proprieatry code I've experienced was from Oracle. |
109 |
This doesn't prove anything except that maybe when you bedazzle bean |
110 |
counters you can get away with anything... |
111 |
|
112 |
-- |
113 |
Alan McKinnon |
114 |
alan.mckinnon@×××××.com |