I've seen this sucker in action at the base of the Eiffel Tower in Paris -- and about 4 years ago at that. I promise you that, despite what people may say in that article, it works quite well, although the viewable angle was painfully small back then. (I would assume that that's been fixed now with the general advances in LCD technology.) The image does appear to be true 3D. Perhaps not extremely deep (when I saw it, the "depth" was perhaps 3 "inches"), but it wasn't simply two layers; a hand, for example, had a clear progression of depth from the tip of the fingers through the palm, not just a finger layer and a palm layer. I was quite impressed at the time, and it will be neat to see such prototype technology finally become available for actual use.
I appreciate that complicated (yet perhaps intuitive) individual package selection interfaces may be really easy for you to use. But I promise you that they're not for Joe Sixpack. If you want Linux to pervade the desktop, you're going to have to compromise at least partially and go with what will be easy for the average user. Look at Mac OS X: the install process consists of clicking "OK" about eight times. If you want more fine-grained control, you got it (click "Customize"), but for the average user, he clicks OK six times or whatever and the entire install process is done for him. For 98% of users, this is exactly what's needed. For the remaining 2%, who are geeks and network admins, you can get the customization through the button; you can modify an existing OS X install and then burn an image to be copied onto a few thousand workstations of that; or you can use a utility such as Pacifist to select individual files of a package. I fail to see how an approach such as this would compromise your setup, yet clearly see how it would help the newbie.
And to those who say, "well, Joe Sixpack should learn more!" Recognize this: he's not going to. So you need to make the decision of whether you would rather he remain in ignorance on Windows or install Linux via a stupid, prettily colored interface. Your call.
If it makes you feel any better, they're also rejecting Mozilla and NS 6.2. So when you see you need Netscape Navigator 4.x, they apparently mean 4.x PERIOD, not 4.x or better.
He's been posting that comment verbaitim on pretty much every story that's been posted recently (certainly any involving Windows). It's not worth your time to bother responding.
He's not just bitching; he's working on OpenBeOS, which is architecturally far closer to BeOS than this bastard child of AtheOS, Linux and Be. By your argument, all of the GNOME people should have quit "bitching" and joined KDE. OBOS and this Linux-AtheOS-Be hybrid have very different goals (a true clone of BeOS including the architecture vs. pretty much just the user experience), and they will suit very different groups of people (OBOS will hopefully be practical for very heavy media processing, whereas this will be more suited to areas where Linux already excels). Personally, while I view this as a nice stepping stone, I am looking forward to OpenBeOS very eagerly.
When Java is run on servers, where a single program can run for an extended period of time without quitting, the JIT can often do extremely thorough optomization and get Java running nearly as fast as, and on occasion barely faster than, the equivalent C++ program. I don't find it particularly hard to believe that the next generation of JITs will be able to exceed C++ easily if they are rigorously optomizing. The problem is that user applications often don't run long enough for the JIT to do that serious optomization, and unless Sun has some very revolutionary ideas, games would suffer the same problem.
You actually get into really sticky stuff here. I used to bring up this line of argument during evolutions debates, until I was called on it. I'll explain what the deal is. In science, if we have a law, then that means that it is, for all of our knowledge, completely immutable. These almost never involve explanations of why; merely the equations that describe how two things intereact. For example, objects will always seek the lowest potential energy. That's a law. A theory, on the other hand, explains why something occurs, or gives the equations for a given example. Newton's theory of gravity happened to give us a pretty simple equation that explains what mathematical rules govern that drop in potential known as gravity, but the fact that we will seek that lower potential is a law. Theories are, in addition, often wrong; Newton's mechanics have been replaced by the quantum view of the universe, for example, which may or may not eventually yield to something like string theory. But these battling explanations do not change the fact that the phenomenon exists.
The reason that this really doesn't matter in this case is that "good" theories let us do things with them. For example, while Newton's laws of gravity aren't technically accurate, they let us put men on the moon, and while the theories of electricity actually have the current running the wrong way, that didn't prevent us from gettings lots of electric lights. Whether or not these greenhouse theories would let us control the climate (which it seems would be the logical test) is something I don't think we'll know for a long time.
Just went to check this out. Unfortunately, it appears that it in fact only has 128 registers: 32 int, 32 float, 32 string (!?) and 32 "Perl Magic Cookie," which would mean more to me if I knew Perl. On the whole, though, it does look like an interesting project. Thanks for the heads-up.
An infinite number of registers? Are you a troll, or just a crackfiend? You know nothing of assembly language, or you would be laughing as hard as I am now. If you emulate a cpu, and you design the virtual cpu in such a way that there are unlimited registers, they are no longer registers, but rather the equivalent of variables and/or pointers.
Neither troll nor crack, although if you haven't seen the AmigaDE documents I do understand why you think I might be. AmigaDE registers are 32-bit integers only which may be pointers or data. AmigaDE also has variables (data stored that must be fetched by pointer), just like every other assembly language. Without this, you couldn't have strings or complex data structures. It just so happens that it also allows you an infinite number of registers. In common use, I'd say a function uses maybe 12 or so registers on average when written in the Amiga's virtual assembly. On an x86, only 4 to 8 get to be lucky enough to be register variables. The rest will be regular variables, with all the lag associated with them. On a PowerPC, which has 32 integer registers and 32 floating registers (and 32 vector registers on a G4), you could fit them all in registers. On an x86-64 as well, you could fit all of them on there, and on an Itanium, with its 320 registers, you could probably keep all pointers and integers in register space. It's not really any different from declaring a variable "register" in C. The compiler tries to make it a register, and if it can't, it won't. Similarly, as long as a variable happens to be a 32-bit number, you can make it a register in VP, and if you're lucky enough to be on an architecture with lots of registers, it will be one. Further, if you use named registers, when the code is compiled, the assembler aggressively checks scoping to see where a specific register may be reused. When no additional registers are available, and for more complex data, you need pointers anyway, and you've got them.
Thus, they are not variables; but I suppose that, you are correct, they are not full registers, either. That said, you might want to be slightly less aggressive when you say someone's wrong. I understand why you think I'm nuts, but surely there was a more polite way to point that out.
Why are we so busy coding a clone of.NET's IL when we could be cloning Intent? Intent truly is language neutral, because its assembler is extremely low-level, and yet nicer than most ASM; indeed, it's almost a mid-level language, if there is such a thing. You have registers, but you have an infinite number of them, and you can give them names instead of referring to r823 and so on. You have looping constructs, but you also can jump around. As on.NET, you can include fully native methods in your code if you wish (and even have the VM automatically pick between a bytecode version and a native version of a function if both exist). Because of the lower-level nature than that of.NET, functional languages can be fully implemented, including tail-calls. Further, while the VM is object-oriented, objects and methods are really little more than mini-programs that run in the current stack space. (It's really tough to explain this; the best I example I can think of is shell scripts, where tasks are done by calling other programs and then parsing their output--only imagine then that this were done lower-level and was the way all programs were built, such that a program's functions were even little programs like this.) And, simlar yet better than.NET, as you run a program, the VM begins writing out a native version for the next run, but continues optomizing it. Think about all of the problems about getting a decent compiler for something like Itanium: now we'd have a VM that could continue to analyze program flow so that a program really could take advantange of an VLIW chip. The compiler doesn't need to do profiling; the JIT does, the upshot being that older programs will run faster and faster as the JIT improves, without a recompile.
What I'd kind of like to see, to be honest, is for the community to make an Intent VM and then make the C# compiler compile to that instead of IL. Throw in a.NET->Intent bytecode converter, and you've got yourself a winner, I'd think. However, I vaguely recall that there are patent problems here. Still, at least we could reimplement some of the concepts...
Re:They support MacOS^H^H^H^H^HRiscOS wrappers
on
ROX Desktop Update
·
· Score: 2
Other really nice things are the Drag-and-drop save - why the hell hasn't this caught on elsewhere?
As a general rule, it's highly inconvenient; you have to already have opened the folder where you want to save the file, and then you have to drag it around the screen until it's in a position that make it easy to drag. Depending on the windowing paradigm, this can be a pain. (In Mac OS 9.2, it borders on the impossible, since all of an application's windows are grouped together.) However, Mac OS (and NEXTSTEP before it) do provide this very functionality in the form of proxies -- those little icons in the title bar. Click and hold and you suddenly are holding the icon in your hand. Drop it on the desktop or wherever and it gets saved. One area where I do use this a lot is with web browsing and tabbed windows: I keep a tab at the bottom of the screen called "Bookmarks," and then drag the URL proxies from IE and iCab down there when I want to bookmark something. The upshot is that I can get at those links at any point, without launching a browser, and I can just drop the link onto whichever browser I want to use instead of being locked into one.
There are two caveats: first, Carbon/Classic apps do not all implement this functionality, as it was only introduced in Mac OS 8.5; and secondly, those Carbon and Classic apps that do sometimes don't have an active proxy until you've saved once, for whatever reason. However, once the proxy is active, it works just like RISC OS did, flaws and all.
Your arguments are kind of moot. The kernel system in OS X will get 0% CPU and essentially be entirely cached to disk if it doesn't do anything for awhile, but if you still don't like that, just use Darwin, which has no such graphics layer. Add in fink (http://fink.sourceforge.net/) and you can apt-get pretty much anything you need without a compile. Am I missing something?
Sorry for doubting, but you didn't mention you used to work at Apple on the OS X Intel port.:) Obviously that would change things a bit, to say the least. My one question, though, if you happen to know the answer, is why Apple hasn't bothered to give the Darwin community the source now, since they would still like it tremendously and it would be very helpful. I'm asking as a question of logistics, not truth.
Darwin has already been ported to x86, and I think it supports a rather large set of hardware.
Currently, while Darwin does run on Intel, it's limited to only a few Intel motherboards and essentially one harddisk controller. Check out the installation notes.
The real problem porting would be Quartz. From what I understand, Quartz is rather heavily optimized for AltiVec.
Actually, while Quartz got a number of AltiVec optomizations in 10.1, it actually runs perfectly fine on G3 computers as long as they have a decent graphics card, so I doubt this would be a real problem. Besides that, Apple is working on optimizing Quartz essentially by making use of chips' 3D hardware, which will, if successful, have the rather amusing effect of essentially putting Quartz on top of OpenGL. The important thing to remember in any case is that Quartz is still a very new graphics system that is still only capable of really making use a fairly small subset of what most graphics chips could do for it, and such benefits would be cross-platform. (For example, Classic offloads scrolling to the graphics chip, and a number of high-quality publishing cards allowed it even to offload font routines and more. Quartz can't do any of that yet (although Apple is definitely working on it). In other words, Quartz is still not very tied-down to any particular hardware. So I wouldn't view that as a point of concern.
Apple has already ported Mac OS X to Intel. And I don't just mean the Darwin open source foundation. The entire operating system including Cocoa, Carbon, Quartz and Aqua runs and runs well on Intel CPUs. At one point there was also an Alpha port but that was discontinued well before Mac OS X went beta.
Where'd you learn this? The last non-PPC port of OS X was Rhapsody DR2, to my knowledge, which lacked Aqua, Quartz, and Carbon. (It was, at that point, still essentially OPENSTEP 5 with a Platinum interface and QuickTime Media Layer injected, which at the time included QuickDraw GX and QuickDraw 3D.) It ran only on Intel and PowerPC. After that release, Jobs announced that Rhapsody was DBA (Dead Before Arrival) and announced his new Mac OS X scheme, which included the fact that the new operating system would not run on Intel. Mac OS X DP1 and later did not run on Intel hardware. And at no point did I hear anything about Alpha, and find it highly unlikely if for no other reason than due to the Darwin sources that were initially released.
As you may remember, when Darwin was first released, many people wanted it to run on Intel, and this ended up being a massive job that still isn't finished. It wasn't that anything had been removed; it's that it simply hadn't been maintained at all since the old Mach 2.5 version, so the foundation, while there, was simply horrendously out of date. Had Apple continued Intel ports, and especially if they had done an Alpha port, it seems as though that code would have been included as well. Recently, in fact, as Darwin's been gotten to limp along on a few varieties of Intel motherboards (and "limp" is definitely the right word here), Apple's been helping a bit with the Intel port, but, again, they're having as much trouble as anyone. No "Here's a secret250,000-line patch to make it work." Just problem solving line by line, conflict by conflict. Given all that, I've always regarded the "OS X is secretely running on Intel" rumor as just that. A rumor.
Unless you've got evidence otherwise, then another argument against OS X on Intel is simply that, despite the rumors, it doesn't exist.
Apple typically makes a much greater profit per unit of software than per unit of hardware. There have been years when Apple's entire profit margin has been from its software division(s).
Unless you have a source I'm not aware of, then I'll assert that that's just wrong. Until Jobs took over, all software at Apple was available for free except for the products that came out of Clarus, so what you're saying is that Clarus held up Apple. That's a pretty big lump to swallow. Further, even now, Apple really has only a few major software products that have the potential to bring in money: Mac OS X ($129), whose sales have tapered; QuickTime Pro ($29); Final Cut Pro ($999); AppleWorks (still available for $69 but also shipping now with all new computers); and DVD Studio Pro. The rest of their software products are given away free--including their kick-ass developer tools, i* software, Mac OS X upgrades, QuickTime Streaming Server, etc. Again, I find it highly unlikely that those pieces of software sustain Apple's profits.
Furthermore, however, the profit margins on Apple hardware are generally quite large. Excluding the iMac and iBook (whose profit margins are extremely low; something like $40 on the old iMacs and $50 on the 12.1" iBooks) Apple pulls in $200+ profits on each computer and $250+ profit on their monitors minimum. Now notice that of the products I listed earlier only two are over $300 for the consumer, and tell me that the profit per unit is higher for software. In fact, if you check out some of Apple's more recent financials, the hardware profits outflank software products by a massive majority, something in the order of about 5:1.
Unless you've got a source, I've got to label you as either a troll or a wishful thinker.
A few years back there was a game, I think it was called Virus or something like that. It would scan your directory structure and make a map for the FPS world based on that.
So if you were standing in the C: room and unleashed a flury of rockets, was that equivalent to rm -rf/?
You know what's funny? I've been saying that the desktop was doomed, that it was going to be replaced by specialty devices, for a long time now--far longer than I'm willing to admit. I've now become convinced that we're just not going to see it--entirely. What I think you'll see instead is something not at all far from Apple's digital hub strategy. In 10-20 years, we'll probably use PDAs for many of our documents and our scheduling, we'll use digital cameras for photos, specialized players for audio and possibly movies, consoles for video games, and so on. But you have to make those all talk together some way. This is the whole point of Apple's newer computers, the reason why they're spending so much time on i* software. That's where Linux ought to be headed. And for that, the desktop is still very important.
As for embedded devices, I'd actually really rather not see Linux there. I'd rather see a kernel better geared to embedded devices. Something extremely small, modular and effect, similar to 3DO's now defunct M2: extremely compact, fully reentrant kernel, a unique memory design where applications could read memory everywhere but write only in their own space, a file system similar to the Newton's, etc. Then let Linux be the digital hub. Hell, Linux already makes a good server, and is that not what we're looking at it becoming in the future? Imagine a world where your house is wirelessly networked, and the job of the desktop is essentially to keep everything syncrhonized. That's a server job. It's also one where you still need good desktop software. Sounds like an ideal place for Linux to me.
So the desktop wars may be in some sense over, but we'll still be using desktops for a long time to come, and I think that if Linux wants to compete, it needs to ensure it can go there.
GCC 3.0 isn't capable of compiling KDE. That will take GCC 3.1, which isn't out (at least as far as I know). Probably a bad idea on a KDE-based distro...
I'll second that. I'm in Indiana. I have a Verizon cell, and a number of my friends have Sprints. While I think Sprint might be a bit cheaper, their coverage is downright lousy compared to Verizon. It's easy to go into roaming with the Spring sometimes just by crossing the street, whereas I've gone into roaming with Verizon exactly once, when I was truly out in the middle of nowhere. I've also never lost a signal, while the Sprint users here seem to lose them reasonably often.
Verizon may offer poor cell phone service elsewhere, and certainly their customer support can be a royal pain, but at least in Indy and apparently NYC they're one of the best cell carriers available.
I'd really refrain from editing the prefs.js file directly. Instead, just create a file in the same directory called user.js and store your custom preferences there. user.js is parsed after prefs.js , and is not modified by the GUI when you alter preferences, so if you mess up it's much easier to fix. (And, conversely, you're guaranteed that the GUI won't mess it up for you.)
Serious question: does anyone know if they really DO use AOL at AOL? I.e., whether AOL is used for email and browsing within AOL headquarters? It would strike me as very unfriendly to a corporate environment, but on the other hand, most companies try to use their own products wherever possible.
Slashdot Mirror
I've seen this sucker in action at the base of the Eiffel Tower in Paris -- and about 4 years ago at that. I promise you that, despite what people may say in that article, it works quite well, although the viewable angle was painfully small back then. (I would assume that that's been fixed now with the general advances in LCD technology.) The image does appear to be true 3D. Perhaps not extremely deep (when I saw it, the "depth" was perhaps 3 "inches"), but it wasn't simply two layers; a hand, for example, had a clear progression of depth from the tip of the fingers through the palm, not just a finger layer and a palm layer. I was quite impressed at the time, and it will be neat to see such prototype technology finally become available for actual use.
Who are you targeting?
I appreciate that complicated (yet perhaps intuitive) individual package selection interfaces may be really easy for you to use. But I promise you that they're not for Joe Sixpack. If you want Linux to pervade the desktop, you're going to have to compromise at least partially and go with what will be easy for the average user. Look at Mac OS X: the install process consists of clicking "OK" about eight times. If you want more fine-grained control, you got it (click "Customize"), but for the average user, he clicks OK six times or whatever and the entire install process is done for him. For 98% of users, this is exactly what's needed. For the remaining 2%, who are geeks and network admins, you can get the customization through the button; you can modify an existing OS X install and then burn an image to be copied onto a few thousand workstations of that; or you can use a utility such as Pacifist to select individual files of a package. I fail to see how an approach such as this would compromise your setup, yet clearly see how it would help the newbie.
And to those who say, "well, Joe Sixpack should learn more!" Recognize this: he's not going to. So you need to make the decision of whether you would rather he remain in ignorance on Windows or install Linux via a stupid, prettily colored interface. Your call.
If it makes you feel any better, they're also rejecting Mozilla and NS 6.2. So when you see you need Netscape Navigator 4.x, they apparently mean 4.x PERIOD, not 4.x or better.
He's been posting that comment verbaitim on pretty much every story that's been posted recently (certainly any involving Windows). It's not worth your time to bother responding.
He's not just bitching; he's working on OpenBeOS, which is architecturally far closer to BeOS than this bastard child of AtheOS, Linux and Be. By your argument, all of the GNOME people should have quit "bitching" and joined KDE. OBOS and this Linux-AtheOS-Be hybrid have very different goals (a true clone of BeOS including the architecture vs. pretty much just the user experience), and they will suit very different groups of people (OBOS will hopefully be practical for very heavy media processing, whereas this will be more suited to areas where Linux already excels). Personally, while I view this as a nice stepping stone, I am looking forward to OpenBeOS very eagerly.
When Java is run on servers, where a single program can run for an extended period of time without quitting, the JIT can often do extremely thorough optomization and get Java running nearly as fast as, and on occasion barely faster than, the equivalent C++ program. I don't find it particularly hard to believe that the next generation of JITs will be able to exceed C++ easily if they are rigorously optomizing. The problem is that user applications often don't run long enough for the JIT to do that serious optomization, and unless Sun has some very revolutionary ideas, games would suffer the same problem.
You actually get into really sticky stuff here. I used to bring up this line of argument during evolutions debates, until I was called on it. I'll explain what the deal is. In science, if we have a law, then that means that it is, for all of our knowledge, completely immutable. These almost never involve explanations of why; merely the equations that describe how two things intereact. For example, objects will always seek the lowest potential energy. That's a law. A theory, on the other hand, explains why something occurs, or gives the equations for a given example. Newton's theory of gravity happened to give us a pretty simple equation that explains what mathematical rules govern that drop in potential known as gravity, but the fact that we will seek that lower potential is a law. Theories are, in addition, often wrong; Newton's mechanics have been replaced by the quantum view of the universe, for example, which may or may not eventually yield to something like string theory. But these battling explanations do not change the fact that the phenomenon exists.
The reason that this really doesn't matter in this case is that "good" theories let us do things with them. For example, while Newton's laws of gravity aren't technically accurate, they let us put men on the moon, and while the theories of electricity actually have the current running the wrong way, that didn't prevent us from gettings lots of electric lights. Whether or not these greenhouse theories would let us control the climate (which it seems would be the logical test) is something I don't think we'll know for a long time.
Neither of which, incidentally, is as smart as fighting fire with, say, water.
Just went to check this out. Unfortunately, it appears that it in fact only has 128 registers: 32 int, 32 float, 32 string (!?) and 32 "Perl Magic Cookie," which would mean more to me if I knew Perl. On the whole, though, it does look like an interesting project. Thanks for the heads-up.
Thus, they are not variables; but I suppose that, you are correct, they are not full registers, either. That said, you might want to be slightly less aggressive when you say someone's wrong. I understand why you think I'm nuts, but surely there was a more polite way to point that out.
Why are we so busy coding a clone of .NET's IL when we could be cloning Intent? Intent truly is language neutral, because its assembler is extremely low-level, and yet nicer than most ASM; indeed, it's almost a mid-level language, if there is such a thing. You have registers, but you have an infinite number of them, and you can give them names instead of referring to r823 and so on. You have looping constructs, but you also can jump around. As on .NET, you can include fully native methods in your code if you wish (and even have the VM automatically pick between a bytecode version and a native version of a function if both exist). Because of the lower-level nature than that of .NET, functional languages can be fully implemented, including tail-calls. Further, while the VM is object-oriented, objects and methods are really little more than mini-programs that run in the current stack space. (It's really tough to explain this; the best I example I can think of is shell scripts, where tasks are done by calling other programs and then parsing their output--only imagine then that this were done lower-level and was the way all programs were built, such that a program's functions were even little programs like this.) And, simlar yet better than .NET, as you run a program, the VM begins writing out a native version for the next run, but continues optomizing it. Think about all of the problems about getting a decent compiler for something like Itanium: now we'd have a VM that could continue to analyze program flow so that a program really could take advantange of an VLIW chip. The compiler doesn't need to do profiling; the JIT does, the upshot being that older programs will run faster and faster as the JIT improves, without a recompile.
.NET->Intent bytecode converter, and you've got yourself a winner, I'd think. However, I vaguely recall that there are patent problems here. Still, at least we could reimplement some of the concepts...
What I'd kind of like to see, to be honest, is for the community to make an Intent VM and then make the C# compiler compile to that instead of IL. Throw in a
There are two caveats: first, Carbon/Classic apps do not all implement this functionality, as it was only introduced in Mac OS 8.5; and secondly, those Carbon and Classic apps that do sometimes don't have an active proxy until you've saved once, for whatever reason. However, once the proxy is active, it works just like RISC OS did, flaws and all.
Your arguments are kind of moot. The kernel system in OS X will get 0% CPU and essentially be entirely cached to disk if it doesn't do anything for awhile, but if you still don't like that, just use Darwin, which has no such graphics layer. Add in fink (http://fink.sourceforge.net/) and you can apt-get pretty much anything you need without a compile. Am I missing something?
Sorry for doubting, but you didn't mention you used to work at Apple on the OS X Intel port. :) Obviously that would change things a bit, to say the least. My one question, though, if you happen to know the answer, is why Apple hasn't bothered to give the Darwin community the source now, since they would still like it tremendously and it would be very helpful. I'm asking as a question of logistics, not truth.
Actually, while Quartz got a number of AltiVec optomizations in 10.1, it actually runs perfectly fine on G3 computers as long as they have a decent graphics card, so I doubt this would be a real problem. Besides that, Apple is working on optimizing Quartz essentially by making use of chips' 3D hardware, which will, if successful, have the rather amusing effect of essentially putting Quartz on top of OpenGL. The important thing to remember in any case is that Quartz is still a very new graphics system that is still only capable of really making use a fairly small subset of what most graphics chips could do for it, and such benefits would be cross-platform. (For example, Classic offloads scrolling to the graphics chip, and a number of high-quality publishing cards allowed it even to offload font routines and more. Quartz can't do any of that yet (although Apple is definitely working on it). In other words, Quartz is still not very tied-down to any particular hardware. So I wouldn't view that as a point of concern.
As you may remember, when Darwin was first released, many people wanted it to run on Intel, and this ended up being a massive job that still isn't finished. It wasn't that anything had been removed; it's that it simply hadn't been maintained at all since the old Mach 2.5 version, so the foundation, while there, was simply horrendously out of date. Had Apple continued Intel ports, and especially if they had done an Alpha port, it seems as though that code would have been included as well. Recently, in fact, as Darwin's been gotten to limp along on a few varieties of Intel motherboards (and "limp" is definitely the right word here), Apple's been helping a bit with the Intel port, but, again, they're having as much trouble as anyone. No "Here's a secret250,000-line patch to make it work." Just problem solving line by line, conflict by conflict. Given all that, I've always regarded the "OS X is secretely running on Intel" rumor as just that. A rumor.
Unless you've got evidence otherwise, then another argument against OS X on Intel is simply that, despite the rumors, it doesn't exist.
Furthermore, however, the profit margins on Apple hardware are generally quite large. Excluding the iMac and iBook (whose profit margins are extremely low; something like $40 on the old iMacs and $50 on the 12.1" iBooks) Apple pulls in $200+ profits on each computer and $250+ profit on their monitors minimum. Now notice that of the products I listed earlier only two are over $300 for the consumer, and tell me that the profit per unit is higher for software. In fact, if you check out some of Apple's more recent financials, the hardware profits outflank software products by a massive majority, something in the order of about 5:1.
Unless you've got a source, I've got to label you as either a troll or a wishful thinker.
You know what's funny? I've been saying that the desktop was doomed, that it was going to be replaced by specialty devices, for a long time now--far longer than I'm willing to admit. I've now become convinced that we're just not going to see it--entirely. What I think you'll see instead is something not at all far from Apple's digital hub strategy. In 10-20 years, we'll probably use PDAs for many of our documents and our scheduling, we'll use digital cameras for photos, specialized players for audio and possibly movies, consoles for video games, and so on. But you have to make those all talk together some way. This is the whole point of Apple's newer computers, the reason why they're spending so much time on i* software. That's where Linux ought to be headed. And for that, the desktop is still very important.
As for embedded devices, I'd actually really rather not see Linux there. I'd rather see a kernel better geared to embedded devices. Something extremely small, modular and effect, similar to 3DO's now defunct M2: extremely compact, fully reentrant kernel, a unique memory design where applications could read memory everywhere but write only in their own space, a file system similar to the Newton's, etc. Then let Linux be the digital hub. Hell, Linux already makes a good server, and is that not what we're looking at it becoming in the future? Imagine a world where your house is wirelessly networked, and the job of the desktop is essentially to keep everything syncrhonized. That's a server job. It's also one where you still need good desktop software. Sounds like an ideal place for Linux to me.
So the desktop wars may be in some sense over, but we'll still be using desktops for a long time to come, and I think that if Linux wants to compete, it needs to ensure it can go there.
GCC 3.0 isn't capable of compiling KDE. That will take GCC 3.1, which isn't out (at least as far as I know). Probably a bad idea on a KDE-based distro...
Where can you still buy Win 3.11? I'm assuming it must be available somewhere for a reasonable price.
I'll second that. I'm in Indiana. I have a Verizon cell, and a number of my friends have Sprints. While I think Sprint might be a bit cheaper, their coverage is downright lousy compared to Verizon. It's easy to go into roaming with the Spring sometimes just by crossing the street, whereas I've gone into roaming with Verizon exactly once, when I was truly out in the middle of nowhere. I've also never lost a signal, while the Sprint users here seem to lose them reasonably often.
Verizon may offer poor cell phone service elsewhere, and certainly their customer support can be a royal pain, but at least in Indy and apparently NYC they're one of the best cell carriers available.
I'd really refrain from editing the prefs.js file directly. Instead, just create a file in the same directory called user.js and store your custom preferences there. user.js is parsed after prefs.js , and is not modified by the GUI when you alter preferences, so if you mess up it's much easier to fix. (And, conversely, you're guaranteed that the GUI won't mess it up for you.)
Serious question: does anyone know if they really DO use AOL at AOL? I.e., whether AOL is used for email and browsing within AOL headquarters? It would strike me as very unfriendly to a corporate environment, but on the other hand, most companies try to use their own products wherever possible.