Would this be something like how Coral indexes/caches the internet? Could it even be Added to Coral, so that you would have a very Google-esqe interface to not only find a site, but to present a copy of it to you, even if the original site is down?
The fact is, there's no point in trying to organize the information on the internet; the internet is a decentralized datamass. Since all of the data isn't constrained to even one location, data can go off and online as it chooses, adding to the symphony of discord.
If, perchance, a computer were to start caching the internet, it would be pertainant to implement an organization algorithm, and personally, I would hate to see all of the indexes. It's currently incalculable the data to metadata ratio currently in existance on the internet, but I can assure you it's probably somewhere close to 2:1 or even 1:1. HTML, XML, and stylesheets are everywhere, and images like blank.jpg, spacing and padding are just as obnoxious.
The truth is, the closest we've come to organizing the internet is the Wikipedia. All of us are pouring our webpages and content into the Wikipedia under categories and subcategories, and for the first time, there seems to be some organized way to access everything. This is very close to the computer on Star Trek, if you want to get technical.
Lastly, I'll leave with a question. If the Wikipedia is on the internet, then if we were to cache the internet, we'd have to add the wikipedia to another organizational structure right? So wouldn't we basically be adding the Wiki, to a Wiki?
Re:Why isn't this already out?
on
Next Generation X11
·
· Score: 4, Interesting
I think the real problem is, everyone knows X Windows is broken, but nobody knows what to do about it. A few reactionary people set apart to create projects like Fresco and Y-Windows, but the fact is, those are just as useless without knowing what was broken in X Windows in the first place.
As a Mac OS X user, a previous Windows user, and a current Linux Desktop user, I will not be the first to tell you that X is slooow. Windows seems more responsive than most Linux desktop distros I've used, and Mac OS X puts both to shame. Java applications on the Mac (or Windows) even seem more responsive than X Windows.
I still profess that the problem lies with the widget set/window manager not being integrated into the core, but that's just my opinion, and I'm not an expert. It just seems to me that there has to be some code that's shared between the two systems, and together, both systems generate excessive overhead that can be eliminated if we weren't so obstanant in preference of either KDE or GNOME.
To be honest, I'm surprised there hasn't been a project yet to integrate GNOME into X, which I'm surprised hasn't sparked a project to integrate KDE into X (two new forks). It'd be a nice graduate project if someone had the time, and I'd love to see what a GUI on linux could actually perform like.
Lastly, the problem comes with there being absolutely no good drivers available. Honestly, even though NVidia/ATi tries, they're not up to par with what they've got on the Windows platform, and Apple developers have had the luxury of seeing the developer's specs, so their drivers are just as impecible.
I think one of the best things that could come out of open source as of now, would be out of the ReactOS department. Find a way to use ATi's and Nvidia's drivers, then wrap them in such a way they can be used to draw X. I think that'd be an ideal solution, even if 20 people reply and tell me that this is technically unfeasable, and that licences and shit keep us from doing this legally.
using more less expensive processors works for x86 processors too. Why use an opteron 8xx when you could use a few Athlon-64s? That's the sort of approach Google takes, redundant arrays of inexpensive computers.
Frankly, you've summarized exactly what I said into two short sentences.:)
And G5's do qualify for this argument, because they are cheap, 64-bit chips, even if they do run on a different archetecure. And they've been shown to have a higher IPC (Instruction Per Cost) ratio, making them a more than ideal candidate.
I think the biggest thing that would prohibit moving to G5's is (a) Windows-only software, and (b) Simply needing more machines that Apple is capable of producing. Google, for instance, runs somewhere in the neighborhood of 300,000 machines. Apple simply can't produce volumes like that; Thousands at a time are pushing it (they seem to be going at a 750 machines per big installation rate). When Google orders machines, they most likely stay with AMD or Intel simply because the code's already there, and because it fits with what they already have. But if a company is new, evaluate Apple.
The thing is, with computers the way they are now, an 8-way system configuration is unnessicary to do the work. Name an application (pick anything). If you need 8 processors to run it, the chances of it being a parallel operation are insanely high. Any parallel operation is fitted well to distributed computing (a no brainer).
I know there are still situations where an 8-way machine could be nessicary, but these days aren't like they used to be; processors are damned fast. Applications have hit barriers to even keep these processors fed with things to do! The kinds of problems that we are solving with computers now are the kinds of problems that distribute well over hundreds of machines, as long as the network latency isn't horrible (which actually replaces the argument in the early 90's of memory latency [faster chip vs multiple slower chips], if you remember the state of "Supercomputing" then).
8-way Opterons are a waste. They'd be better off selling 4-way configurations for more expensive, and making a better profit. The kinds of companies that buy 8-way systems are the kind of companies who put together clusters, and most of these companies stick to what they know, and what they know is Intel's track record is impecible, though more expensive.
There is an argument here as well that Apple needs to make a 4-way system, but I think they've probably evaluated that option by now, and realized that any problem anyone's trying to solve can be done with 2 processors, cheaper, even if it does take more time. Time costs money, and I'm guessing someone somewhere did a time-cost projection to model the Xserve as they did. It simply isn't economically feasable to build a 8-way machine, when 4 2-way machines can do the same work.
By integrating the memory controller, they've assured low latency. DDR2 simply says they can get all of the data they need all at once, and store it in a local cache. Meanwhile, the Pentium 4 beast is a memory hungry chip; most operations the chip spends its time toiling on are operations that require a lot of data (SIMD) (why do you think they hyped it for movies and such??). This means the Pentium 4 has to hit the memory bus more often, or increase its cache size. We've already seen the Prescott go up to a 2 meg cache, and the Extreme Edition go up to an L3 cache to keep local copies of even more data, but it's simply not enough to keep the Pentium 4 competitive (not to mention it drives up the thermal profile of the chip quite a bit). The fact is it simply needs to go to local memory more often. Integrating a memory controller makes it cheaper to go to local memory, instead of waiting on the North Bridge to fetch the information from memory and send it back up the pipe. This is why A64 can go to ram, pick up huge chunks of memory at once, process it, and send it back, while Intel's Netburst chips sit and wait, idling their time away.
Processors have actually gotten too fast for their respective systems. AMD tries to get around this by bringing the memory closer to the chip. Intel's trying to get around it to bringing the memory on the chip, and Intel's approach isn't working as well as they'd hoped.
Hah, no they aren't. They are cheap in comparison to Intel's 64-bit offerings, but are definitely NOT cheap in comparison to Apple's/IBM's/(hell, I'm tempted to put Sun's) 64-bit offerings.
A single G5 will run you about $1500, including the whole computer to wrap around it, ram and all. You can go up from there, but the limiting factor is a two processor chassis. But the fact is, 4 XServes be cheapter to assemble, run, and maintain than the processors used to make one 8-way Opteron server. You can argue all that you like that shared memory will make these Opterons faster than the G5's, but in that case, you could simply throw twice the number of processors at the problem using G5's, with a relatively equal price (after you count hardware, networking equipment, etc).
The fact is, Apple really won the cheap high end server market, and they're starting to get market acceptance there as well (as far as Low-end super computing goes). Any company thinking about building a super computer really should look at their options. The only thing I think that could be really prohibitive, would be the need to run Windows on the systems, which would then make the Opteron option cheaper, but without 64-bit support, their system will hardly live up to its capabilities.
The real problem is, AMD's Opteron will probably be done and shipping by the time Intel gets 64-bit dual core Xeons out the door. Not that they couldn't go ahead and shift all of their production capacity to dual core now, and have early chips ready by the end of this year, it's more like they won't.
More and more I get my hopes up that Intel is doing research into a 64-bit enhancement for the Pentium-M, and I believe this to be the only reason we haven't seen Dual Core Pentium-M's yet. We're just now starting to see a move for the Pentium-M to the desktop, which is a good start, but without the cutting edge memory controllers present on new chipsets, it doesn't stand a chance.
I believe Intel is also probably investigating adding memory controllers to their next Xeon line, which is definitely going to extend the amount of time in which we expect to see it. Intel really would see this as defeat, but as DDR2 becomes prime, Opteron's with DDR2 controllers will be able to completely smash any Intel offering, simply because it can get the data faster, get it processed, and pumped back out, while the Intel chips still wait for the laggy north bridge memory host to allocate the resources.
Reliability will always be in Intel's court, simply because they control all factors of production, beginning to end. AMD's trying to take this approach, and by opening new fab facilities, maybe they can get into competition in other chip segments (like the Turion vs the Pentium-M). It also doesn't help that AMD is no longer making chipsets, but I believe a new fab facility will open this up as a possibility once again.
The fact is, I salute Microsoft for going this route.
I've evaluated plenty of SQL filesystems, attempted to implement my own, and with mild success, ran and tested many implementations. Here's what I found out:
SQL sucks as a filesystem. While it's great that SQL can store relations incredibly well, make finding files easier, and provide a good, intellegent backup system, its faults are with the implementation, every time.
It requires the programmer to make two choices; "Do I want to include an entire SQL engine in kernel space, or leave it in user space?" and "Do I want the 'parsing agent' to run in user space or in kernel space?".
To anyone who's ever worked with an SQL engine, the answer to the first question is obvious. If you move the entire SQL engine to kernel space, you're introducing kernel bloat in the size of 40-80 megabytes for the software itself (including caches, sql tables in ram, etc). But if you leave it in userspace, every user has to have their own copy of the software running for them, or your parser agent has to have a kernel hook that basically takes the input from the user accessing the file system, and redirect it to the SQL engine itself.
The "Parsing Agent" as it were, is a piece of code that actually rips apart the files you send to it, grabbing the content's type, and any metadata it can filter out of the file. It can then use two seperate transfers to send the file to one table, and the metadata to another. When searching for a file, it simply queries the metadata, and matches a file index to the files located in the data cache. This is how almost all modern desktop search technologies work (Google Desktop Search, Spotlight, and whatever Windows Longhorn will have).
The existance of a good parsing agent makes an SQL file system virtually irrelevant. I commend them for not wasting their time storing the whole files in an SQL database, but the metadata should be. That way, using a common API, all programs should be able to quickly find files they need to operate, making the file system more amorphous, and less rigid. Hell, if software engineers cared enough, we could get rid of the whole idea of a heirarchial file system now; simply tag incoming files with a UID, and write them to disk, making the "Parsing Agent" keep all of the metadata, and letting it deal with finding and opening files. You could have links on your desktop to commonly used searches "All files Containing the word 'Lyrics'" (a common one used during my tests).
Really, I'd love to see what Apple has in store for Spotlight, but I definitely know that Windows Longhorn is better off without WinFS the way they originally planned it.
As a freshman computer engineer, I've already developed a design process that works well for me.
It's pretty simple actually. First, draw a diagram showing work flow and data flow. This will help when you go into implementation and try to work out algorithm and memory problems (you can easily see which parts of the software will be doing more work, and which will be dealing with memory/data).
Then code.
Since a lot changes in the coding process, the original design document is now practically worthless, except that it's still conceptually correct. Now all you have to do is read through the software and create a new diagram, showing how everything works, and adding file names/line numbers to the boxes in your diagram.
Take this diagram to the beginning of this algorithm and repeat.
I find too many software engineers forgo this last, most important step, and that sucessful projects are the projects that are able to clearly keep design goals and patterns in the blue, and not hidden in a million pages of documents. For this same reason, I tend to shy away from using "Automatic Documentation Generators", and CVS systems (but that's for other reasons as well, as I really hate CVS). I also tend to "re-invent the wheel" a lot because developers forget this last step and as I may be able to make sense of their code, I simply hate the design layout of it, or the lack thereof. This happened to me when I wrote my own MP3 management software; every single implementation of an ID3 library I ran into was garbage. There were a few that were less garbagy as the rest, and I drew heavily on them for design, but re-implemented everything in a different fashion.(Why on EARTH do you need 70 objects to deal with an ID3 tag that only contains 10-20 objects itself???? I think some people need to re-take object oriented design...) [p.s. I probaby will not open source this work; it took up far too much of my time to just give away.]
It's funny as well; I often get picked on because my code takes longer to produce, even if I generate at least three times as much design information as the rest of my classmates. I also had the highest grade in my last class (the teacher would often give me 10 to 15 points simply for my design information and comments).
It's very simple really; Final Cut Pro is undergoing "not developed here" syndrome. Since it's not orginally Apple's code, it has no native support for AppleScript. To be truthful, they're probably thinking about it a lot; Apple usually takes their time before they do major reworks of products, especially ones they've purchased from other companies. Think about NextStep. It was acquired by Apple in 1997 and it took them four years to re-introduce it as Mac OS X (and IMO it was still not ready).
So my final answer is "just wait for the next version or such". They're working on it;)
I believe they meant the new Belkin device that automatically transports pictures from your digital camera to your iPod via MiniUSB port. That one was slated only to work with iPod Photos I believe, but I could be wrong.
You should also think about this: if you bought OS X 10.0 in 2001, you bought something that was a LOT like NT4; It showed that a lot of pretty new things were on the horizion, but it was slow as fuck, and buggy as can be.
10.1 brought a prettier interface, and a lot more stability, and speed. If you ask me, this was a lot like jumping from NT4, to NT4 SP4.
The biggest jump came with OS 10.2. This launched OS X forward by adding a lot of usable apps, "iLife" was finally starting to work together, the whole system began to feel like it belonged together. This was more like the jump from NT4 to Win2000 (Win2k was "ME"'s UI with the back engine from NT4, prettier, more stable, and easier to use with 9x series computers).
Along came 10.3 and another round of dozens of feature enhancements and refinements. Minus the whole "Luna" theme, this was like the jump from Win2k to WinXP.
Tiger (10.4) would be like the jump from WinXP, to WinInfinity (where Infinity represents a rough estimate to when Longhorn will retail).
If you look at it from my persepective (or any other Mac users perspective for that matter), we've gone through 3 major core overhauls in 5 years, lending to a total price of 3 x 129 = 387. If you look at the comparitive upgrades in Windows, you'd first have to price the upgrade from NT4 to 2000, then from 2000 to XP, then from XP to Longhorn. Oh, and Mac OS X runs on the same hardware all the way back, Windows XP probably has a null chance of even installing on the same hardware you ran NT4 on.
Asside from your tollingness, there are problems, and there are significant advantages to what you are suggesting. Let's go through some of them:
First of all, with a chip the size of the 386, you can almost see the components, and manufacturing flaws are really easy to detect. With a chip manufactured on.09 micron technology, not only is there no way to reliably detect manufacuring flaws, but virtually every chip manufactured on the technology will have these flaws (sure, the big companies have big sophistimacated electron microscopes to see, but that's expensive, and running one of these over every chip would get out of hand fast). With a core the size of a Pentium 4, these errors are almost guarenteed to happen in a few choice transistors that really don't do much (MMX, SSE(1-3), possibily one of the ALUs), simply out of probability. On a core the size of a 386, virtually every transistor taken down will kill that core. So even on a chip with 150 386-like cores, you're only looking at even 100 of them running perfectly.
Next, memory archetechure. You're going to need several busses to connect memory to this thing; if you arranged the processors in a cellular fashion on chip, 8 to 16 at a time hugging on to one independent memory controller, you're going to have 10-20 links to deal with, each link consisting of around a hundred pins for the actual processor itself. You're looking at very easily a 2000 pin out chip.
Next, archetecure capability. Each processor had one Integer unit, an NO onboard FPU unit. This makes the processors great at doing nothing.
And now, let's talk about the current environment. The Cell Processor (joint venture from Sony and IBM and a few others) is a processor with a Power-4-like core, with a bunch of float units tacked on to the end of it, making it extremely parallel to execute a series of operations on a lot of redundant data. They call it a "stream processor" for this reason, as it would most likely be used to process "streams" of data; a bunch of signals coming in, pixels to go out to a buffer, etc. The current dual-core projects are making it to a point where they're replicating current industry leading chips, and smashing them together on a single core. Eventually, I believe these companies will see that while this is intellegent, they need to refine the idea; stick 4 ALU/4 FPU, an SSE unit with an MMX translator front end (saves silicon), and a bunch of load store units, running them all in SMT. While this is really pretty much what is going on now (two Pentium 4's almost contain all of that), there is a lot of redundant silicon that won't ever be touched, which is wasting valuable CPU space, and producing more heat.
If we were to take your idea and run with it, I'd suggest taking a bunch of Pentium Pros (like 8 maybe), and sticking them on one die with a Pentium 4. The Pentium 4 can pick up and run any SSE/MMX code, and the 8 PPros can go to town on any huge amount of FPU/APU code. Couple this with a shared L2 cache (probably would want 2 L2's actually; one shared between all 8 PPros using the technology they're using currently with the Pentium M to turn off sections when they're not needed, and one for the Pentium 4 as MMX/SSE code will hit the L2 a hell of a lot more often), and you've got yourself one mean, number crunching machine.
One last note: Who's to say this very technology isn't already in existance? Have you ever read Digital Fortress by Dan Brown? In the book he speaks of a machine capable of cryptographically breaking all current encryption systems with a high level of simplicity. If you were to have maybe 512 of these (100) way processors, you'd easily have 51200 chips at your command to run a distributed key check algorithm over. I'm pretty sure a machine with this power (although consuming the power of a small city, and needing a cooling system like Niagra Falls, not to mention costing nearly/more than a billion dollars on getting the CPU manufacturers in Taiwan to make these chips, having people de
Why is it too bulky? It offers automated CVS/SVN support, greatly helps organize files without needlessly creating a thousand folders to store your files in, builds everything as you ask it to, and offers instant support at your fingertips. XCode is awesome if you know how to use it correctly.
But, if you are a C or Perl hacker who likes doing things from the command line, that's quite alright as well. If you're programming on the Mac, you're most likely making a GUI for something UNIXie already, so you're probably going to want to use XCode, if not for its instant support to Carbon documentation, than for source code highlighting and autocomplete (which isn't as good as Visual Studio's autocomplete, but it gets the job done).
Ah myapologies grammer nazi/troll. I'm quite a bit sick and I like to stay indoors and argue with/.ers when I'm under the weather.
CSS2 is ahead of its time. It uses the Document Object Model to draw, color, and arrange items in a way agnostic to implementation, and agnostic to content. Sure, we already have programs capable of drawing, coloring and arranging items in a document; each of them being tied inextricably to their creation-engine (Microsoft Word and Word documents, for example). Not only that, the current existant technology to do this isn't even fully forward compatible among versions (Word 7 and XP for example), and other implementations are very lack luster (though I'll hand it to PDF for being pretty good, even if the software to use PDF (read AND write) is very expensive). CSS2 is the Free Standard to do all of this, and more.
I believe a browser should be smart enough to withstand whatever's thrown at it, and if it recieves errored data, to notify the user as such, and move on. That being said, I believe as it may be Internet Explorer's fault for not implementing more than half of the standard, it is also our fault for not implementing all of the features. As Microsoft does have more of the market share, that shouldn't stop people from creating pages that don't work with Internet Explorer; they should be encouraged to do so, so that Internet Explorer would continue to evolve. If it was anyone's "fault" for the more "esoteric features" (CSS positioning as esoteric???? come on..) not being implemented in Internet Explorer, it's the Web Developers for not using the standards, and making Internet Explorer take heed. Microsoft may be huge, and gots lots of money, but they can't stop millions of web developers.
Face it. We dropped the ball. Open Source developers (hell, even Opera developers) recognized this, and promised to web developers a sanctuary where more of the standards are usable. As such, web developers (and users) are flocking to Firefox. And now that Internet Explorer is back in the game, things will get interesting. No matter which browser comes out of this new broswer war on top, we win.
On a laptop, operating system is critical to performance. On a desktop where almost everything is outrageously overpowered anyways, it doesn't matter so much. Windows XP requires ie, will not install, with less thand256MB of ram. That's silly because my desktop machine can run Debian or Fedora core 1 just fine with just 128MB of ram, and do all of the same things that I use it for.
Of course, that machine now has 1GB of ram, and runs a tiny swap, hopefully increasing the life of that machine a bit longer.. Really,I think Linux is the best option for the desktop if you can use it (most of us can't, so we use Windows). But Mac OS X Panther is probably the best operating system I've seen, all around. That's the point I'm trying to make, and that's how Apple sold their product to me.
I don't think the standard's broken persay, I just believe that programmers haven't yet implemented it completely/correctly. CSS2 is a very difficult standard to implement simply because it encompasses so much not only in code length, but in what it actually does. That being said, CSS2 is really ahead of its time (as is CSS3), but as the competition for the better browser roars up, you can bet your bottom dollar that these standards will be the key issues everyone is looking at.
I really think it's going to be a tough race verses Firefox and Internet Explorer; Microsoft has more coders out there to throw at Internet Explorer, whereas Firefox already has industry leading stamina and good developmental practices, even if some of them are contraversial (disabling itf domains support, for example). Either way, the browsers will get better, and eventually will be able to render that page without any issue, but it'll just take time.
At the time, the machine I compared it against had a smaller HD (40gb vs the 60 in my iBook), a faster processor (1.8 centrino), the same amount of memory, and a bit better screen resolution (15" display, 1280x760 or something really weird like that), and a bit of a better warrantee (3 years, which I guess I have the option of getting with Apple; Dell wanted to force it down my throat. Also, take in account this was before Dell was giving away the world with their machines..).
The thing is, I wouldn't need that much power if the damned operating system that came with it (Windows XP Pro, another few bucks on the price, regardless) would simply do its job and not require as fancy hardware. Yes, I evaluated Linux as a possibility; I run Linux on my desktop machine at home, simply because it's a bit older, and all of the stuff that came with it (by the graces of a few donating coders in the world) was supported. I knew if I got a laptop, I wouldn't be so lucky.
Also keep in mind I only evaluated Dell; by the time I saw Panther, I was sold.
Slashdot Mirror
Would this be something like how Coral indexes/caches the internet? Could it even be Added to Coral, so that you would have a very Google-esqe interface to not only find a site, but to present a copy of it to you, even if the original site is down?
The fact is, there's no point in trying to organize the information on the internet; the internet is a decentralized datamass. Since all of the data isn't constrained to even one location, data can go off and online as it chooses, adding to the symphony of discord.
If, perchance, a computer were to start caching the internet, it would be pertainant to implement an organization algorithm, and personally, I would hate to see all of the indexes. It's currently incalculable the data to metadata ratio currently in existance on the internet, but I can assure you it's probably somewhere close to 2:1 or even 1:1. HTML, XML, and stylesheets are everywhere, and images like blank.jpg, spacing and padding are just as obnoxious.
The truth is, the closest we've come to organizing the internet is the Wikipedia. All of us are pouring our webpages and content into the Wikipedia under categories and subcategories, and for the first time, there seems to be some organized way to access everything. This is very close to the computer on Star Trek, if you want to get technical.
Lastly, I'll leave with a question. If the Wikipedia is on the internet, then if we were to cache the internet, we'd have to add the wikipedia to another organizational structure right? So wouldn't we basically be adding the Wiki, to a Wiki?
I think the real problem is, everyone knows X Windows is broken, but nobody knows what to do about it. A few reactionary people set apart to create projects like Fresco and Y-Windows, but the fact is, those are just as useless without knowing what was broken in X Windows in the first place.
As a Mac OS X user, a previous Windows user, and a current Linux Desktop user, I will not be the first to tell you that X is slooow. Windows seems more responsive than most Linux desktop distros I've used, and Mac OS X puts both to shame. Java applications on the Mac (or Windows) even seem more responsive than X Windows.
I still profess that the problem lies with the widget set/window manager not being integrated into the core, but that's just my opinion, and I'm not an expert. It just seems to me that there has to be some code that's shared between the two systems, and together, both systems generate excessive overhead that can be eliminated if we weren't so obstanant in preference of either KDE or GNOME.
To be honest, I'm surprised there hasn't been a project yet to integrate GNOME into X, which I'm surprised hasn't sparked a project to integrate KDE into X (two new forks). It'd be a nice graduate project if someone had the time, and I'd love to see what a GUI on linux could actually perform like.
Lastly, the problem comes with there being absolutely no good drivers available. Honestly, even though NVidia/ATi tries, they're not up to par with what they've got on the Windows platform, and Apple developers have had the luxury of seeing the developer's specs, so their drivers are just as impecible.
I think one of the best things that could come out of open source as of now, would be out of the ReactOS department. Find a way to use ATi's and Nvidia's drivers, then wrap them in such a way they can be used to draw X. I think that'd be an ideal solution, even if 20 people reply and tell me that this is technically unfeasable, and that licences and shit keep us from doing this legally.
I'm not surprised. In all of my testing, this came out to be the most valid, working conclusion to the SQL file system idea.
using more less expensive processors works for x86 processors too. Why use an opteron 8xx when you could use a few Athlon-64s? That's the sort of approach Google takes, redundant arrays of inexpensive computers.
:)
Frankly, you've summarized exactly what I said into two short sentences.
And G5's do qualify for this argument, because they are cheap, 64-bit chips, even if they do run on a different archetecure. And they've been shown to have a higher IPC (Instruction Per Cost) ratio, making them a more than ideal candidate.
I think the biggest thing that would prohibit moving to G5's is (a) Windows-only software, and (b) Simply needing more machines that Apple is capable of producing. Google, for instance, runs somewhere in the neighborhood of 300,000 machines. Apple simply can't produce volumes like that; Thousands at a time are pushing it (they seem to be going at a 750 machines per big installation rate). When Google orders machines, they most likely stay with AMD or Intel simply because the code's already there, and because it fits with what they already have. But if a company is new, evaluate Apple.
The thing is, with computers the way they are now, an 8-way system configuration is unnessicary to do the work. Name an application (pick anything). If you need 8 processors to run it, the chances of it being a parallel operation are insanely high. Any parallel operation is fitted well to distributed computing (a no brainer).
I know there are still situations where an 8-way machine could be nessicary, but these days aren't like they used to be; processors are damned fast. Applications have hit barriers to even keep these processors fed with things to do! The kinds of problems that we are solving with computers now are the kinds of problems that distribute well over hundreds of machines, as long as the network latency isn't horrible (which actually replaces the argument in the early 90's of memory latency [faster chip vs multiple slower chips], if you remember the state of "Supercomputing" then).
8-way Opterons are a waste. They'd be better off selling 4-way configurations for more expensive, and making a better profit. The kinds of companies that buy 8-way systems are the kind of companies who put together clusters, and most of these companies stick to what they know, and what they know is Intel's track record is impecible, though more expensive.
There is an argument here as well that Apple needs to make a 4-way system, but I think they've probably evaluated that option by now, and realized that any problem anyone's trying to solve can be done with 2 processors, cheaper, even if it does take more time. Time costs money, and I'm guessing someone somewhere did a time-cost projection to model the Xserve as they did. It simply isn't economically feasable to build a 8-way machine, when 4 2-way machines can do the same work.
By integrating the memory controller, they've assured low latency. DDR2 simply says they can get all of the data they need all at once, and store it in a local cache. Meanwhile, the Pentium 4 beast is a memory hungry chip; most operations the chip spends its time toiling on are operations that require a lot of data (SIMD) (why do you think they hyped it for movies and such??). This means the Pentium 4 has to hit the memory bus more often, or increase its cache size. We've already seen the Prescott go up to a 2 meg cache, and the Extreme Edition go up to an L3 cache to keep local copies of even more data, but it's simply not enough to keep the Pentium 4 competitive (not to mention it drives up the thermal profile of the chip quite a bit). The fact is it simply needs to go to local memory more often. Integrating a memory controller makes it cheaper to go to local memory, instead of waiting on the North Bridge to fetch the information from memory and send it back up the pipe. This is why A64 can go to ram, pick up huge chunks of memory at once, process it, and send it back, while Intel's Netburst chips sit and wait, idling their time away.
Processors have actually gotten too fast for their respective systems. AMD tries to get around this by bringing the memory closer to the chip. Intel's trying to get around it to bringing the memory on the chip, and Intel's approach isn't working as well as they'd hoped.
Hah, no they aren't. They are cheap in comparison to Intel's 64-bit offerings, but are definitely NOT cheap in comparison to Apple's/IBM's/(hell, I'm tempted to put Sun's) 64-bit offerings.
A single G5 will run you about $1500, including the whole computer to wrap around it, ram and all. You can go up from there, but the limiting factor is a two processor chassis. But the fact is, 4 XServes be cheapter to assemble, run, and maintain than the processors used to make one 8-way Opteron server. You can argue all that you like that shared memory will make these Opterons faster than the G5's, but in that case, you could simply throw twice the number of processors at the problem using G5's, with a relatively equal price (after you count hardware, networking equipment, etc).
The fact is, Apple really won the cheap high end server market, and they're starting to get market acceptance there as well (as far as Low-end super computing goes). Any company thinking about building a super computer really should look at their options. The only thing I think that could be really prohibitive, would be the need to run Windows on the systems, which would then make the Opteron option cheaper, but without 64-bit support, their system will hardly live up to its capabilities.
The real problem is, AMD's Opteron will probably be done and shipping by the time Intel gets 64-bit dual core Xeons out the door. Not that they couldn't go ahead and shift all of their production capacity to dual core now, and have early chips ready by the end of this year, it's more like they won't.
More and more I get my hopes up that Intel is doing research into a 64-bit enhancement for the Pentium-M, and I believe this to be the only reason we haven't seen Dual Core Pentium-M's yet. We're just now starting to see a move for the Pentium-M to the desktop, which is a good start, but without the cutting edge memory controllers present on new chipsets, it doesn't stand a chance.
I believe Intel is also probably investigating adding memory controllers to their next Xeon line, which is definitely going to extend the amount of time in which we expect to see it. Intel really would see this as defeat, but as DDR2 becomes prime, Opteron's with DDR2 controllers will be able to completely smash any Intel offering, simply because it can get the data faster, get it processed, and pumped back out, while the Intel chips still wait for the laggy north bridge memory host to allocate the resources.
Reliability will always be in Intel's court, simply because they control all factors of production, beginning to end. AMD's trying to take this approach, and by opening new fab facilities, maybe they can get into competition in other chip segments (like the Turion vs the Pentium-M). It also doesn't help that AMD is no longer making chipsets, but I believe a new fab facility will open this up as a possibility once again.
Oh I love competition.
The fact is, I salute Microsoft for going this route.
I've evaluated plenty of SQL filesystems, attempted to implement my own, and with mild success, ran and tested many implementations. Here's what I found out:
SQL sucks as a filesystem. While it's great that SQL can store relations incredibly well, make finding files easier, and provide a good, intellegent backup system, its faults are with the implementation, every time.
It requires the programmer to make two choices; "Do I want to include an entire SQL engine in kernel space, or leave it in user space?" and "Do I want the 'parsing agent' to run in user space or in kernel space?".
To anyone who's ever worked with an SQL engine, the answer to the first question is obvious. If you move the entire SQL engine to kernel space, you're introducing kernel bloat in the size of 40-80 megabytes for the software itself (including caches, sql tables in ram, etc). But if you leave it in userspace, every user has to have their own copy of the software running for them, or your parser agent has to have a kernel hook that basically takes the input from the user accessing the file system, and redirect it to the SQL engine itself.
The "Parsing Agent" as it were, is a piece of code that actually rips apart the files you send to it, grabbing the content's type, and any metadata it can filter out of the file. It can then use two seperate transfers to send the file to one table, and the metadata to another. When searching for a file, it simply queries the metadata, and matches a file index to the files located in the data cache. This is how almost all modern desktop search technologies work (Google Desktop Search, Spotlight, and whatever Windows Longhorn will have).
The existance of a good parsing agent makes an SQL file system virtually irrelevant. I commend them for not wasting their time storing the whole files in an SQL database, but the metadata should be. That way, using a common API, all programs should be able to quickly find files they need to operate, making the file system more amorphous, and less rigid. Hell, if software engineers cared enough, we could get rid of the whole idea of a heirarchial file system now; simply tag incoming files with a UID, and write them to disk, making the "Parsing Agent" keep all of the metadata, and letting it deal with finding and opening files. You could have links on your desktop to commonly used searches "All files Containing the word 'Lyrics'" (a common one used during my tests).
Really, I'd love to see what Apple has in store for Spotlight, but I definitely know that Windows Longhorn is better off without WinFS the way they originally planned it.
As a freshman computer engineer, I've already developed a design process that works well for me.
It's pretty simple actually. First, draw a diagram showing work flow and data flow. This will help when you go into implementation and try to work out algorithm and memory problems (you can easily see which parts of the software will be doing more work, and which will be dealing with memory/data).
Then code.
Since a lot changes in the coding process, the original design document is now practically worthless, except that it's still conceptually correct. Now all you have to do is read through the software and create a new diagram, showing how everything works, and adding file names/line numbers to the boxes in your diagram.
Take this diagram to the beginning of this algorithm and repeat.
I find too many software engineers forgo this last, most important step, and that sucessful projects are the projects that are able to clearly keep design goals and patterns in the blue, and not hidden in a million pages of documents. For this same reason, I tend to shy away from using "Automatic Documentation Generators", and CVS systems (but that's for other reasons as well, as I really hate CVS). I also tend to "re-invent the wheel" a lot because developers forget this last step and as I may be able to make sense of their code, I simply hate the design layout of it, or the lack thereof. This happened to me when I wrote my own MP3 management software; every single implementation of an ID3 library I ran into was garbage. There were a few that were less garbagy as the rest, and I drew heavily on them for design, but re-implemented everything in a different fashion.(Why on EARTH do you need 70 objects to deal with an ID3 tag that only contains 10-20 objects itself???? I think some people need to re-take object oriented design...) [p.s. I probaby will not open source this work; it took up far too much of my time to just give away.]
It's funny as well; I often get picked on because my code takes longer to produce, even if I generate at least three times as much design information as the rest of my classmates. I also had the highest grade in my last class (the teacher would often give me 10 to 15 points simply for my design information and comments).
Small Mac? Perhaps the Double-Cheeseburger Mac?
Wow. Sounds like someone's trying to get us to proofread his college paper for him...
GET BACK TO WORK SLACKER.
(just kidding)
It's very simple really; Final Cut Pro is undergoing "not developed here" syndrome. Since it's not orginally Apple's code, it has no native support for AppleScript. To be truthful, they're probably thinking about it a lot; Apple usually takes their time before they do major reworks of products, especially ones they've purchased from other companies. Think about NextStep. It was acquired by Apple in 1997 and it took them four years to re-introduce it as Mac OS X (and IMO it was still not ready).
;)
So my final answer is "just wait for the next version or such". They're working on it
Grandparent said that. Postscript -> PDF, then Display PS -> Display PDF. NextStep had a lot of good ideas, Mac OS X just made them better.
I believe they meant the new Belkin device that automatically transports pictures from your digital camera to your iPod via MiniUSB port. That one was slated only to work with iPod Photos I believe, but I could be wrong.
You should also think about this: if you bought OS X 10.0 in 2001, you bought something that was a LOT like NT4; It showed that a lot of pretty new things were on the horizion, but it was slow as fuck, and buggy as can be.
10.1 brought a prettier interface, and a lot more stability, and speed. If you ask me, this was a lot like jumping from NT4, to NT4 SP4.
The biggest jump came with OS 10.2. This launched OS X forward by adding a lot of usable apps, "iLife" was finally starting to work together, the whole system began to feel like it belonged together. This was more like the jump from NT4 to Win2000 (Win2k was "ME"'s UI with the back engine from NT4, prettier, more stable, and easier to use with 9x series computers).
Along came 10.3 and another round of dozens of feature enhancements and refinements. Minus the whole "Luna" theme, this was like the jump from Win2k to WinXP.
Tiger (10.4) would be like the jump from WinXP, to WinInfinity (where Infinity represents a rough estimate to when Longhorn will retail).
If you look at it from my persepective (or any other Mac users perspective for that matter), we've gone through 3 major core overhauls in 5 years, lending to a total price of 3 x 129 = 387.
If you look at the comparitive upgrades in Windows, you'd first have to price the upgrade from NT4 to 2000, then from 2000 to XP, then from XP to Longhorn. Oh, and Mac OS X runs on the same hardware all the way back, Windows XP probably has a null chance of even installing on the same hardware you ran NT4 on.
but WHY??? You can't possibly read the text of those little icons....
Asside from your tollingness, there are problems, and there are significant advantages to what you are suggesting. Let's go through some of them:
.09 micron technology, not only is there no way to reliably detect manufacuring flaws, but virtually every chip manufactured on the technology will have these flaws (sure, the big companies have big sophistimacated electron microscopes to see, but that's expensive, and running one of these over every chip would get out of hand fast). With a core the size of a Pentium 4, these errors are almost guarenteed to happen in a few choice transistors that really don't do much (MMX, SSE(1-3), possibily one of the ALUs), simply out of probability. On a core the size of a 386, virtually every transistor taken down will kill that core. So even on a chip with 150 386-like cores, you're only looking at even 100 of them running perfectly.
First of all, with a chip the size of the 386, you can almost see the components, and manufacturing flaws are really easy to detect. With a chip manufactured on
Next, memory archetechure. You're going to need several busses to connect memory to this thing; if you arranged the processors in a cellular fashion on chip, 8 to 16 at a time hugging on to one independent memory controller, you're going to have 10-20 links to deal with, each link consisting of around a hundred pins for the actual processor itself. You're looking at very easily a 2000 pin out chip.
Next, archetecure capability. Each processor had one Integer unit, an NO onboard FPU unit. This makes the processors great at doing nothing.
And now, let's talk about the current environment. The Cell Processor (joint venture from Sony and IBM and a few others) is a processor with a Power-4-like core, with a bunch of float units tacked on to the end of it, making it extremely parallel to execute a series of operations on a lot of redundant data. They call it a "stream processor" for this reason, as it would most likely be used to process "streams" of data; a bunch of signals coming in, pixels to go out to a buffer, etc. The current dual-core projects are making it to a point where they're replicating current industry leading chips, and smashing them together on a single core. Eventually, I believe these companies will see that while this is intellegent, they need to refine the idea; stick 4 ALU/4 FPU, an SSE unit with an MMX translator front end (saves silicon), and a bunch of load store units, running them all in SMT. While this is really pretty much what is going on now (two Pentium 4's almost contain all of that), there is a lot of redundant silicon that won't ever be touched, which is wasting valuable CPU space, and producing more heat.
If we were to take your idea and run with it, I'd suggest taking a bunch of Pentium Pros (like 8 maybe), and sticking them on one die with a Pentium 4. The Pentium 4 can pick up and run any SSE/MMX code, and the 8 PPros can go to town on any huge amount of FPU/APU code. Couple this with a shared L2 cache (probably would want 2 L2's actually; one shared between all 8 PPros using the technology they're using currently with the Pentium M to turn off sections when they're not needed, and one for the Pentium 4 as MMX/SSE code will hit the L2 a hell of a lot more often), and you've got yourself one mean, number crunching machine.
One last note: Who's to say this very technology isn't already in existance? Have you ever read Digital Fortress by Dan Brown? In the book he speaks of a machine capable of cryptographically breaking all current encryption systems with a high level of simplicity. If you were to have maybe 512 of these (100) way processors, you'd easily have 51200 chips at your command to run a distributed key check algorithm over. I'm pretty sure a machine with this power (although consuming the power of a small city, and needing a cooling system like Niagra Falls, not to mention costing nearly/more than a billion dollars on getting the CPU manufacturers in Taiwan to make these chips, having people de
Why is it too bulky? It offers automated CVS/SVN support, greatly helps organize files without needlessly creating a thousand folders to store your files in, builds everything as you ask it to, and offers instant support at your fingertips. XCode is awesome if you know how to use it correctly.
But, if you are a C or Perl hacker who likes doing things from the command line, that's quite alright as well. If you're programming on the Mac, you're most likely making a GUI for something UNIXie already, so you're probably going to want to use XCode, if not for its instant support to Carbon documentation, than for source code highlighting and autocomplete (which isn't as good as Visual Studio's autocomplete, but it gets the job done).
Ah myapologies grammer nazi/troll. I'm quite a bit sick and I like to stay indoors and argue with /.ers when I'm under the weather.
CSS2 is ahead of its time. It uses the Document Object Model to draw, color, and arrange items in a way agnostic to implementation, and agnostic to content. Sure, we already have programs capable of drawing, coloring and arranging items in a document; each of them being tied inextricably to their creation-engine (Microsoft Word and Word documents, for example). Not only that, the current existant technology to do this isn't even fully forward compatible among versions (Word 7 and XP for example), and other implementations are very lack luster (though I'll hand it to PDF for being pretty good, even if the software to use PDF (read AND write) is very expensive). CSS2 is the Free Standard to do all of this, and more.
I believe a browser should be smart enough to withstand whatever's thrown at it, and if it recieves errored data, to notify the user as such, and move on. That being said, I believe as it may be Internet Explorer's fault for not implementing more than half of the standard, it is also our fault for not implementing all of the features. As Microsoft does have more of the market share, that shouldn't stop people from creating pages that don't work with Internet Explorer; they should be encouraged to do so, so that Internet Explorer would continue to evolve. If it was anyone's "fault" for the more "esoteric features" (CSS positioning as esoteric???? come on..) not being implemented in Internet Explorer, it's the Web Developers for not using the standards, and making Internet Explorer take heed. Microsoft may be huge, and gots lots of money, but they can't stop millions of web developers.
Face it. We dropped the ball. Open Source developers (hell, even Opera developers) recognized this, and promised to web developers a sanctuary where more of the standards are usable. As such, web developers (and users) are flocking to Firefox. And now that Internet Explorer is back in the game, things will get interesting. No matter which browser comes out of this new broswer war on top, we win.
On a laptop, operating system is critical to performance. On a desktop where almost everything is outrageously overpowered anyways, it doesn't matter so much. Windows XP requires ie, will not install, with less thand256MB of ram. That's silly because my desktop machine can run Debian or Fedora core 1 just fine with just 128MB of ram, and do all of the same things that I use it for.
Of course, that machine now has 1GB of ram, and runs a tiny swap, hopefully increasing the life of that machine a bit longer.. Really,I think Linux is the best option for the desktop if you can use it (most of us can't, so we use Windows). But Mac OS X Panther is probably the best operating system I've seen, all around. That's the point I'm trying to make, and that's how Apple sold their product to me.
I don't think the standard's broken persay, I just believe that programmers haven't yet implemented it completely/correctly. CSS2 is a very difficult standard to implement simply because it encompasses so much not only in code length, but in what it actually does. That being said, CSS2 is really ahead of its time (as is CSS3), but as the competition for the better browser roars up, you can bet your bottom dollar that these standards will be the key issues everyone is looking at.
I really think it's going to be a tough race verses Firefox and Internet Explorer; Microsoft has more coders out there to throw at Internet Explorer, whereas Firefox already has industry leading stamina and good developmental practices, even if some of them are contraversial (disabling itf domains support, for example). Either way, the browsers will get better, and eventually will be able to render that page without any issue, but it'll just take time.
What is the page supposed to look like when rendered???
At the time, the machine I compared it against had a smaller HD (40gb vs the 60 in my iBook), a faster processor (1.8 centrino), the same amount of memory, and a bit better screen resolution (15" display, 1280x760 or something really weird like that), and a bit of a better warrantee (3 years, which I guess I have the option of getting with Apple; Dell wanted to force it down my throat. Also, take in account this was before Dell was giving away the world with their machines..). The thing is, I wouldn't need that much power if the damned operating system that came with it (Windows XP Pro, another few bucks on the price, regardless) would simply do its job and not require as fancy hardware. Yes, I evaluated Linux as a possibility; I run Linux on my desktop machine at home, simply because it's a bit older, and all of the stuff that came with it (by the graces of a few donating coders in the world) was supported. I knew if I got a laptop, I wouldn't be so lucky. Also keep in mind I only evaluated Dell; by the time I saw Panther, I was sold.