There is a (possibly) easier way, though. At the end of the day, just write down a list of all the programs you used that day. Don't sweat it, just make a quick list. Do that for a week or two, and look at the results. Post those results, and your basic question ("What are the Mac equivalents of these applications?") to macslash.org, and you will get all the info you need.
Chances are you are thinking, "But what if I forget something?" Well, if it's really important to you, you won't forget it. If it *isn't* important, then it isn't, um, likely to be that important. And if it's something small but vital, chances are you'll use it on multiple days, and pick it up that way, even if you do forget it on one day.
For what it's worth, I don't see anyone bothering to put any programming time into your idea. It just isn't worth my time to do the programming for you. However, you come up with that list, and I'll very happily fill you in on whatever is out there for the Mac.
One caveat: don't expect to find open source equivalents for everything. If it isn't open source on Windows, why would it be so on the Mac? And Apple has a long history of fostering a thriving shareware community. Apple takes their lunch money and eats their lunch sometimes (Konfabulator, etc.), but overall shareware has done well on the Mac platform.
I can't really disagree with you regarding the hardware. PowerBooks *used* to be far ahead of everything else. x86 laptops have caught up in that regard, mostly. That said, I still think that the latest crop of PBs have some really nice incremental (read: small) touches that make for a nice overall computing experience. The one major thing I think is missing, though, is more screen resolution. I mean, I wouldn't say no to more processing power, but for a laptop as thin and light as a PB, the current crop has reasonable power.
However, I think this whole discussion has been sidestepping the quality control problems that Apple has been having lately. The iMac G5s burn out ridiculously frequently. Where I work we've bought a few hundred, and are seeing RMA rates north of 40%. Admittedly, they were all purchased at the same time, so it could have been just a bad run, but still, that's a *very* high figure.
Likewise, the last generation 15" PB had that white spot issue with their LCDs. As did the 14" iBook, IIRC, though to a lesser degree. The current rev of PBs have lots of trouble with the new trackpad. Older iBooks have the video board problem. PowerMac G5s had problems with the fan system. Older PowerMac G4s had *other* problems with their fan system. The list goes on. And on.
Not that I'm not an Apple fanboy myself -- my wife has an iBook, my main desktop computer at work is a Mac, and my next laptop will be a Mac. I love OS X and what it brings to the table as far as interoperability. But this whole topic just seems to be avoiding (deliberately, or from ignorance, I don't know) the issues that surround Apple systems.
Not that issues aren't prevalent for other systems, too. Don't get me started on Sony laptop (un)reliability, for instance. Or IBM ThinkPad MWAVE modem/audio cards back in the days of Windows 3.11. Or the piece-o-crap Compaq desktop systems under my desk at work.
I'm just saying we need to temper the blind adoration with a little realism here and there, that's all.
There are a fair number of typos, mainly in the text from what I saw. All the code looks good (though I haven't tested it all). It seems to me that John Goerzen made sure the code all worked, and wrote the text around it, maybe before it. Unfortunately, it looks like it was rushed to meet a deadline at some point, and the text did not get reviewed and edited as thoroughly as it might have needed.
On the other hand, the content is excellent, truly a good book. And so far, my binding hasn't broken, FWIW. But it was stiff, and doesn't want to lay flat on its own.
The book makes extensive use of Twisted in covering IMAP programming, and also in its exploration of how to design a server, specifically the asynchronous, call-back approach. It does not cover the entirety of Twisted, that would be a book all to itself.
The bonus to Mr. Goerzen's use of Twisted in IMAP is that I came away with a much better understanding of how to use Twisted generally -- I grokked Deferreds for the first time. And I'd read all (ALL) the Twisted documentation I could get my hands on prior to that. That probably gave me the proper background, but the book really kicked in to place those final pieces necessary to get what was going on in Twisted.
The book doesn't just cover "raw" network programming, but covers multiple domain-specific areas and points you to the best libraries and modules to use for the area.
Okay, I have read the book, and the review author is correct in his statement. No, the book will not teach you the OSI model, nor will it teach you general networking theory to an expert level. However, I came to the book with a general knowledge of Python and a poor-to-middlin' understanding of network programming in particular. I've built web apps using pre-existing frameworks, for example, but I've never written code to work with sockets.
Having read the book, I understand socket programming, general network programming, and could probably design and implement my own application protocol -- badly, of course, but still... Could I have done this prior to reading this book? No. Did this book make it easy to pick up the necessary background, as well as make it easy to pick up the specifics of network programming in Python? Yes.
This is a great book, and is a must-have for Python programmers.
Much more to the point, if you'd read the latest weekly newsletter, you'd have seen that 2004.2 was due on July 26th. Look for the small heading labeled "Releng".
Been there, done that, lost the contacts. It depends on how you get hit. If you're sparring in tae kwon do, you'll get kicked in the head, but not punched (generally speaking). In karate, you get both. I've lost more contacts to getting punched in the face than from anything else. The impact of the glove on your eye is enough to move the lens around on your cornea, even through a closed eyelid. The lens moves around, and it loses its suction seal on your eye -- POP! If you're lucky, it just gets painfully shoved up under your eyelid. If not, it gets shoved under your eyelid, and then falls out completely.
The result: I switched back to glasses for normal practice, and take them off to spar. I became really good at fighting "blind". It's still a handicap, though.
Actually, I switched back to glasses for everything for a few years. Last year I went looking for contacts again, and found that there are no soft contact lenses that will work for me anymore, and I can't handle the gas permeables. I've considered the surgery option, but have been concerned about structural integrity, much like the parent reply.
And yes, I have a black belt in karate, and earned lower ranks in tae kwon do. In this, if nothing else in life, I am qualified to pontificate...:)
Take a look at Trac, by Edgewall. Trac is a well-done integration of a project wiki, an issue tracker, and a repository viewer, specifically for Subversion. It works well for me, so I thought I'd plug it a bit.
Regarding wiki markup, how much markup do you really need? Developers and DBAs shouldn't have an issue learning it, and designers and customers shouldn't need to learn it. They can write plain text without losing much. The point of a wiki is to facilitate communication, not to waste time with excess markup.
Your "presentation quality" documentation probably shouldn't be written on a wiki, anyway. The content, maybe, but not the actual, end-product document. With Subversion as a dependency, you already have a source repository, so use it. Stick your docs there, and let folks make reference to them in the wiki and the issue tracker. The combination of functions, wiki, tracker and repository, is much stronger than each separately.
You want the XServe. They're not pretty -- they're intimidatingly gorgeous. They do have a GUI -- that's the software that pudge described for you. You can also accomplish everything over the command-line, or using remote management tools.
By the way, there is a small contradiction between the above claim that Python is more understandable than Perl and the claim that it has an advantage over C++ or Java because it is not as verbose as those. Typically, in increasing amount of source code, you have Perl -> Python -> (C++,Java). If you think that Python is more understandable than Perl, then by that same logic, we could conclude that C++ or Java is more understandable than Python.
There is no contradiction. Verbosity and ease of understanding are orthogonal. To the average reader, Shakespeare is verbose compared to modern English, and is less understandable.
The usual contention is that Java et al. inflate source code with unnecessary type declarations, block delimiters and other punctuation, while Python avoids these bits of syntactic fluff. Python is less verbose than Java, and as a result is more easily understood.
You also wrote:
But if you are currently using C or C++, with maybe X for graphics, or Java, then I suggest you stay with those. All three languages, with their graphics, give you a far richer toolset. Python would be a retrograde choice.
Python gives you no graphics toolkits at all, and as a result, is far from a retrograde choice. Instead, there are Pythonic wrappers for just about every extant graphics toolkit: Qt using PyQt, GTK using PyGTK, Tk using Tkinter, wxWindows via wxPython, Win32 via win32all, Aqua using PyObjC, Swing or AWT using Jython, Fox, and more. Using such a wrapper allows you to program your GUI in Python, with (generally) Pythonic GUI code, which then calls the toolkit. This kind of integration with other libraries is one of Python's strengths: program in Python, with Python's efficiency and readability, while making excellent use of available libraries for increases in speed and additional functionality.
Well, you can always dual-boot a 32-bit Windows and a 64-bit Linux/BSD. Then you can enjoy 64-bit goodness whilst still dipping a toe into your favorite games. And the Mobility Radeon 9600 that's in this laptop should go a long way towards making this laptop suitable for gaming. The processor won't hurt, either...;)
As my title says, I am going to both make a retraction and (good-naturedly) smack you at the same time. First, my apologies, I did indeed mean Mojave and wrote Gobi. Second, please PLEASE PLEASE go read the references I posted. What you've written regarding the PPC970 is just flat-out misinformed, or more accurately, under-informed. As you'll notice if you read the references, yes, the current PPC970 does indeed dissipate around 42 watts -- at 1.8GHz and 1.3V!! At 1.2GHZ and 1.1V, it only dissipates 19W!!! Which is less heat than the 7455 G4 used in the laptops prior to the current revision.
As a result, power dissipation of the CPU is not the issue that has prevented the release of a G5 laptop, or at least not entirely. What the real issues are, we can only guess. My personal guess is it's the controller chip that dissipates too much heat, and also that Steve et al. would rather create a very noticeable jump in performance by introducing laptops at substantially higher clockspeeds, rather than suffer unflattering performance comparisons with the G4 models. "Substantially higher clockspeeds", though, (say, in the same 1.6-2.0GHz range as the desktops) will indeed necessitate a die-shrink of the CPU manufacturing process. However, IBM has consistently made better progress in ramping production up than they publically estimate. In order for Steve's "3GHz within a year" prediction to come true, IBM will either have to jump 2 process cycles, from the current 0.13 micron process to 0.09 microns, and then go to 0.065 microns, or will have to pull some other nifty trick out of their sleeve to reduce the power consumption even further. N.B., IBM announced the processors at 1.4GHz-1.8GHz, and Apple is using 1.6-2.0GHz. Either Apple is overclocking beyond spec already, like they've done in the past with Moronorola CPUs, or IBM's chip has more headroom in its initial revision than IBM publically thought it would. So, a nifty trick is not at all beyond the realm of possibility.
Point being, though, that a 0.09micron CPU that runs at 2.2-2.6GHz in desktops, and dissipates a normal amount of power at those speeds, will work very nicely as a laptop processor at slower speeds, while maintaining the heat profile necessary for a laptop enclosure. And, in this case, slower speeds could very well mean 1.4GHz on up to 2.0GHz.
Stop being so brain-dead. Go read the IBM presentation on page 14 of the PDF, or read ArsTechnica's write-up, and pull your foot out of your mouth.
The G5 was indeed derived from the Power4, and was designed as a low-power chip for use in blade servers, as well as for Apple. It dissipates less heat than a similarly-clocked G4 7455, which is the model used in the PowerBooks prior to today.
The prevailing rumors say that we will see G5s in laptops in 2Q2004, and I agree with them, for the following reasons:
The desktops were (arguably) more in need of a processing power boost than the laptops
Apple designs (with IBM's assistance) the motherboard controller chip for the G5s, with the following implications:
the design takes longer to complete than if IBM were designing it by themselves (sheer conjecture, but...)
the controller chip in the G5 is currently too hot to put in a laptop
Apple must wait for a die-shrink for the controller chip before it is suitable for laptops
IBM is currently working on a shrink from 0.13 micron to 0.09 micron process for G5s
Apple could choose to build a G5 laptop running at around 1.2-1.4 GHz, but the performance gains over a similarly-clocked G4 are not high enough to justify the extra expense, especially considering pre-existing contracts with Motorola
The upshot of all this is that we will very likely see G5s in PowerBooks running at 1.4-1.8GHz, maybe higher, around the same time we see G5 desktops running around 2.4-3.0GHz. We will likely also see a transition to the IBM G3 Gobi chip, which does have Altivec, in the iBooks at some point.
Down in the lower left corner of the Apple Store is a big red sign labeled "Special Deals", wherein you will find refurbished machines for lower than just about any commercial dealer (Smalldog, for instance...) of refurbed Macs. On the other hand, you'll pay sales tax. If sales tax = $100, go to Smalldog, or similar dealers.
Refurbs are covered by Apple's standard 1-year warranty, with the option of purchasing AppleCare, so hardware issues, well, aren't an issue. Also, a standard set of software, cables, manuals, etc. are included in the box.
Well, but that is pretty much the point. The book, from what I've seen from the free version on the website, is pretty general, in that it covers using Python to process text. Yes, pretty much any text. Yes, pretty much anything you want to do with text -- parse it and extract meaning, generate it, manipulate it, you-name-it. Whether it be marked-up, semantically meaningful text, or just a blob of text.
ToEE has been discussed and Tim Cain interviewed at least once a week since the game was announced. Check out IGN, ShackNews, etc. Better yet, dare I say it, ask Google...?
Bioware slimmed down the download by not including the extra voice files. Apple's implementation of OpenGL doesn't support the calls necessary to create shiny water (sub-pixel shading, IIRC, though I probably don't...;).
Because an awful lot of Dvorak users simply remap the keys on an existing qwerty keyboard. Hard to learn on, but if you master Dvorak on a Dvorak-labeled keyboard, your touch-typing skills should carry over to the point where you don't need the labels. At that point, you can just change the keymap in the OS of whatever other computer you find yourself working on and ignore the qwerty-centric labels on the keys. Working on BIOS, though, one's touch-typing Dvorak skills won't help you because there's no such thing as a keymap utility down that far.
The acronym pretty much sums it up: CMS is a system for managing content. Not necessarily web content, and not necessarily XML. CMSs can be used to store lots of different kinds of content.
MANAGEMENT A content management system is about managing content in a systematic way. If you examine the premise, it implies a set of procedures for handling content (create, edit, view, delete, and more complex procedures built from these basics) in a systematic, structured way. From these advanced procedures arises the concept of workflow and roles: a writer creates content, an editor edits it, and a publisher decides whether to publish or not.
STRUCTURE Content is not very usable if it is unstructured. A CMS needs to be able to handle metadata regarding the content. Since XML is a thin wrapper of structure around text, which is one of the most common forms of content, a lot of CMS revolves around XML. Cocoon, though, is not a fully-fledged CMS. It is a very useful tool for taking an XML document and transforming it into a web-viewable format and serving it on the web, and thus can be used as a component of a CMS.
SIZE AND COMPLEXITY Content management systems are not terribly profitable if they require users to have technical skills in order to manipulate the content. If a system does require a great deal of technical skill to use, then the market for such a system becomes much smaller than the market for a system that allows the average secretary to manipulate content easily. A system easy enough for a secretary also needs to be robust enough to prevent said secretary from damaging the system or performing unauthorized actions. From the CMS developer's point of view, it also needs to scale so that the company is willing to purchase licenses for every secretary, and every other person, in the company.
Making easy-to-use, secure user interfaces to a scalable system that requires structure that is custom-defined for each client company and allows creation of client-defined workflows is generally considered non-trivial. Therefore, most content management systems are developed by companies which hope to sell their system to as many large companies as possible. That's why CMSs are generally large, complex and costly. They involve a high degree of business process re-engineering, similar to ERP or CRM systems.
Exceptions (to the generalization that CMSs are closed-source and high-cost) abound, of course. Zope is perhaps one of the best known open source CMS offerings, and it is scalable, can be made secure, and can have easy-to-use UIs. Making it usable for an organization is still a non-trivial task, though, as a lot of customization goes into it. Which, of course, is how Zope Corp. makes its money -- customization and deployment services.
WEB DEVELOPMENT You ask "how/if this technology can be leveraged by the average web devloper?" The answer to if is, "Certainly." And here's how: webloggers, for instance, typically use a minimal CMS to make their life easier. Check out Movable Type as an example. For another variation, put together a system with, say, Xindice as the back-end and Cocoon as the presentation service, and add in some easy-to-use XML editor and you have a basic CMS.
"TECHNOLOGY" In short, there isn't "technology" per se. Instead, there's a problem domain: capturing knowledge, structuring it, subjecting it to validation and other workflows, and then making it easy to retrieve and reuse. Any CMS is just an attempt at an answer to this problem. Certain technologies do tend to fit into the problem domain better than others -- there's a VERY large impedance mismatch between RDBMSs and "documents", though XML and documents go together like ham and cheese. Since XML fits fairly easily into the world of the web, presenting content views as HTML is a common technique.
Anything that dense and that much faster than existing memory technologies will need a different memory controller. No getting around it.
The fact that AMD built a memory controller into the Opteron is not necessarily something to be happy about. On the one hand, it greatly reduces latency of memory reads/writes, on the other hand you can't upgrade the memory speed beyond what your entire CPU supports -- you have to upgrade your entire CPU. Which means AMD has to redesign the CPU to take advantage of faster (or different types of) memory. And Opterons aren't that cheap yet...
PPC970 does not support dual cores in one chip. However, there is nothing preventing Apple from using multiple processors in a computer -- or IBM, for that matter, in its blade servers.
I was ignorant, and am now enlightened. More specifically, I was indeed thinking of MPEG-2, but only in a vague, I-should-have-checked-my-facts-first sort of way. I was under the impression that QTSS would stream various formats, but the only way to produce a QuickTime.mov was to purchase the appropriate codec from Apple. And, yes, I realize that's wrong, too. I was remembering some discussions about.mov playback under Linux, where one couldn't play certain.mov formats due to the Sorenson codec used to encode them, which was not freely available. I was under the impression that one licensed the codec from Apple. Whattheforkever, you don't really care about my rambling... for that matter, neither do I.
May I be allowed to mention that there is a significant difference between the QuickTime codecs and the QTSS, and that, while the latter is open source, the former must be purchased...?
Re:Goes Google obsolete these books?
on
Mac OS X in a Nutshell
·
· Score: 3, Interesting
You wrote:
The argument for disconnected access with books is a bit tougher with a 750page book.. Not really a mobile tool
I own the book, and it is rather small and unassuming for a book with 801 pages. It is NOT a Wrox book. It is a bit thicker than other O'Reilly Nutshell books (Perl IAN, Java IAN, Python IAN), but it is not quite as thick as Oracle IAN. I suspect they are using slimmer pages than they used to do, but they also seem to be a bit more durable.
I can't really comment on the content yet, as I've been reading through Python IAN first -- which, by the way, is amazingly good!
Slashdot Mirror
H'mm, what hardware is Linus using at the moment? Did somebody say a PowerMac G5? Why yes! That'd be right!
On PowerPC chips, support for non-x86 Linux is doing *very* well. Thank you, IBM. Yes, those would be Linux-only PowerPC-based servers for sale.
Well, at least you're honest about it... :)
There is a (possibly) easier way, though. At the end of the day, just write down a list of all the programs you used that day. Don't sweat it, just make a quick list. Do that for a week or two, and look at the results. Post those results, and your basic question ("What are the Mac equivalents of these applications?") to macslash.org, and you will get all the info you need.
Chances are you are thinking, "But what if I forget something?" Well, if it's really important to you, you won't forget it. If it *isn't* important, then it isn't, um, likely to be that important. And if it's something small but vital, chances are you'll use it on multiple days, and pick it up that way, even if you do forget it on one day.
For what it's worth, I don't see anyone bothering to put any programming time into your idea. It just isn't worth my time to do the programming for you. However, you come up with that list, and I'll very happily fill you in on whatever is out there for the Mac.
One caveat: don't expect to find open source equivalents for everything. If it isn't open source on Windows, why would it be so on the Mac? And Apple has a long history of fostering a thriving shareware community. Apple takes their lunch money and eats their lunch sometimes (Konfabulator, etc.), but overall shareware has done well on the Mac platform.
I can't really disagree with you regarding the hardware. PowerBooks *used* to be far ahead of everything else. x86 laptops have caught up in that regard, mostly. That said, I still think that the latest crop of PBs have some really nice incremental (read: small) touches that make for a nice overall computing experience. The one major thing I think is missing, though, is more screen resolution. I mean, I wouldn't say no to more processing power, but for a laptop as thin and light as a PB, the current crop has reasonable power.
However, I think this whole discussion has been sidestepping the quality control problems that Apple has been having lately. The iMac G5s burn out ridiculously frequently. Where I work we've bought a few hundred, and are seeing RMA rates north of 40%. Admittedly, they were all purchased at the same time, so it could have been just a bad run, but still, that's a *very* high figure.
Likewise, the last generation 15" PB had that white spot issue with their LCDs. As did the 14" iBook, IIRC, though to a lesser degree. The current rev of PBs have lots of trouble with the new trackpad. Older iBooks have the video board problem. PowerMac G5s had problems with the fan system. Older PowerMac G4s had *other* problems with their fan system. The list goes on. And on.
Not that I'm not an Apple fanboy myself -- my wife has an iBook, my main desktop computer at work is a Mac, and my next laptop will be a Mac. I love OS X and what it brings to the table as far as interoperability. But this whole topic just seems to be avoiding (deliberately, or from ignorance, I don't know) the issues that surround Apple systems.
Not that issues aren't prevalent for other systems, too. Don't get me started on Sony laptop (un)reliability, for instance. Or IBM ThinkPad MWAVE modem/audio cards back in the days of Windows 3.11. Or the piece-o-crap Compaq desktop systems under my desk at work.
I'm just saying we need to temper the blind adoration with a little realism here and there, that's all.
There are a fair number of typos, mainly in the text from what I saw. All the code looks good (though I haven't tested it all). It seems to me that John Goerzen made sure the code all worked, and wrote the text around it, maybe before it. Unfortunately, it looks like it was rushed to meet a deadline at some point, and the text did not get reviewed and edited as thoroughly as it might have needed.
On the other hand, the content is excellent, truly a good book. And so far, my binding hasn't broken, FWIW. But it was stiff, and doesn't want to lay flat on its own.
The book makes extensive use of Twisted in covering IMAP programming, and also in its exploration of how to design a server, specifically the asynchronous, call-back approach. It does not cover the entirety of Twisted, that would be a book all to itself.
The bonus to Mr. Goerzen's use of Twisted in IMAP is that I came away with a much better understanding of how to use Twisted generally -- I grokked Deferreds for the first time. And I'd read all (ALL) the Twisted documentation I could get my hands on prior to that. That probably gave me the proper background, but the book really kicked in to place those final pieces necessary to get what was going on in Twisted.
The book doesn't just cover "raw" network programming, but covers multiple domain-specific areas and points you to the best libraries and modules to use for the area.
Good stuff, I highly recommend the book.
Okay, I have read the book, and the review author is correct in his statement. No, the book will not teach you the OSI model, nor will it teach you general networking theory to an expert level. However, I came to the book with a general knowledge of Python and a poor-to-middlin' understanding of network programming in particular. I've built web apps using pre-existing frameworks, for example, but I've never written code to work with sockets.
Having read the book, I understand socket programming, general network programming, and could probably design and implement my own application protocol -- badly, of course, but still... Could I have done this prior to reading this book? No. Did this book make it easy to pick up the necessary background, as well as make it easy to pick up the specifics of network programming in Python? Yes.
This is a great book, and is a must-have for Python programmers.
Much more to the point, if you'd read the latest weekly newsletter, you'd have seen that 2004.2 was due on July 26th. Look for the small heading labeled "Releng".
Been there, done that, lost the contacts. It depends on how you get hit. If you're sparring in tae kwon do, you'll get kicked in the head, but not punched (generally speaking). In karate, you get both. I've lost more contacts to getting punched in the face than from anything else. The impact of the glove on your eye is enough to move the lens around on your cornea, even through a closed eyelid. The lens moves around, and it loses its suction seal on your eye -- POP! If you're lucky, it just gets painfully shoved up under your eyelid. If not, it gets shoved under your eyelid, and then falls out completely.
:)
The result: I switched back to glasses for normal practice, and take them off to spar. I became really good at fighting "blind". It's still a handicap, though.
Actually, I switched back to glasses for everything for a few years. Last year I went looking for contacts again, and found that there are no soft contact lenses that will work for me anymore, and I can't handle the gas permeables. I've considered the surgery option, but have been concerned about structural integrity, much like the parent reply.
And yes, I have a black belt in karate, and earned lower ranks in tae kwon do. In this, if nothing else in life, I am qualified to pontificate...
Take a look at Trac, by Edgewall. Trac is a well-done integration of a project wiki, an issue tracker, and a repository viewer, specifically for Subversion. It works well for me, so I thought I'd plug it a bit.
Regarding wiki markup, how much markup do you really need? Developers and DBAs shouldn't have an issue learning it, and designers and customers shouldn't need to learn it. They can write plain text without losing much. The point of a wiki is to facilitate communication, not to waste time with excess markup.
Your "presentation quality" documentation probably shouldn't be written on a wiki, anyway. The content, maybe, but not the actual, end-product document. With Subversion as a dependency, you already have a source repository, so use it. Stick your docs there, and let folks make reference to them in the wiki and the issue tracker. The combination of functions, wiki, tracker and repository, is much stronger than each separately.
You want the XServe. They're not pretty -- they're intimidatingly gorgeous. They do have a GUI -- that's the software that pudge described for you. You can also accomplish everything over the command-line, or using remote management tools.
Enjoy.
There is no contradiction. Verbosity and ease of understanding are orthogonal. To the average reader, Shakespeare is verbose compared to modern English, and is less understandable.
The usual contention is that Java et al. inflate source code with unnecessary type declarations, block delimiters and other punctuation, while Python avoids these bits of syntactic fluff. Python is less verbose than Java, and as a result is more easily understood.
You also wrote:
Python gives you no graphics toolkits at all, and as a result, is far from a retrograde choice. Instead, there are Pythonic wrappers for just about every extant graphics toolkit: Qt using PyQt, GTK using PyGTK, Tk using Tkinter, wxWindows via wxPython, Win32 via win32all, Aqua using PyObjC, Swing or AWT using Jython, Fox, and more. Using such a wrapper allows you to program your GUI in Python, with (generally) Pythonic GUI code, which then calls the toolkit. This kind of integration with other libraries is one of Python's strengths: program in Python, with Python's efficiency and readability, while making excellent use of available libraries for increases in speed and additional functionality.
Well, you can always dual-boot a 32-bit Windows and a 64-bit Linux/BSD. Then you can enjoy 64-bit goodness whilst still dipping a toe into your favorite games. And the Mobility Radeon 9600 that's in this laptop should go a long way towards making this laptop suitable for gaming. The processor won't hurt, either... ;)
As my title says, I am going to both make a retraction and (good-naturedly) smack you at the same time. First, my apologies, I did indeed mean Mojave and wrote Gobi. Second, please PLEASE PLEASE go read the references I posted. What you've written regarding the PPC970 is just flat-out misinformed, or more accurately, under-informed. As you'll notice if you read the references, yes, the current PPC970 does indeed dissipate around 42 watts -- at 1.8GHz and 1.3V!! At 1.2GHZ and 1.1V, it only dissipates 19W!!! Which is less heat than the 7455 G4 used in the laptops prior to the current revision.
As a result, power dissipation of the CPU is not the issue that has prevented the release of a G5 laptop, or at least not entirely. What the real issues are, we can only guess. My personal guess is it's the controller chip that dissipates too much heat, and also that Steve et al. would rather create a very noticeable jump in performance by introducing laptops at substantially higher clockspeeds, rather than suffer unflattering performance comparisons with the G4 models. "Substantially higher clockspeeds", though, (say, in the same 1.6-2.0GHz range as the desktops) will indeed necessitate a die-shrink of the CPU manufacturing process. However, IBM has consistently made better progress in ramping production up than they publically estimate. In order for Steve's "3GHz within a year" prediction to come true, IBM will either have to jump 2 process cycles, from the current 0.13 micron process to 0.09 microns, and then go to 0.065 microns, or will have to pull some other nifty trick out of their sleeve to reduce the power consumption even further. N.B., IBM announced the processors at 1.4GHz-1.8GHz, and Apple is using 1.6-2.0GHz. Either Apple is overclocking beyond spec already, like they've done in the past with Moronorola CPUs, or IBM's chip has more headroom in its initial revision than IBM publically thought it would. So, a nifty trick is not at all beyond the realm of possibility.
Point being, though, that a 0.09micron CPU that runs at 2.2-2.6GHz in desktops, and dissipates a normal amount of power at those speeds, will work very nicely as a laptop processor at slower speeds, while maintaining the heat profile necessary for a laptop enclosure. And, in this case, slower speeds could very well mean 1.4GHz on up to 2.0GHz.
The G5 was indeed derived from the Power4, and was designed as a low-power chip for use in blade servers, as well as for Apple. It dissipates less heat than a similarly-clocked G4 7455, which is the model used in the PowerBooks prior to today.
The prevailing rumors say that we will see G5s in laptops in 2Q2004, and I agree with them, for the following reasons:
The upshot of all this is that we will very likely see G5s in PowerBooks running at 1.4-1.8GHz, maybe higher, around the same time we see G5 desktops running around 2.4-3.0GHz. We will likely also see a transition to the IBM G3 Gobi chip, which does have Altivec, in the iBooks at some point.
Down in the lower left corner of the Apple Store is a big red sign labeled "Special Deals", wherein you will find refurbished machines for lower than just about any commercial dealer (Smalldog, for instance...) of refurbed Macs. On the other hand, you'll pay sales tax. If sales tax = $100, go to Smalldog, or similar dealers.
Refurbs are covered by Apple's standard 1-year warranty, with the option of purchasing AppleCare, so hardware issues, well, aren't an issue. Also, a standard set of software, cables, manuals, etc. are included in the box.
Well, but that is pretty much the point. The book, from what I've seen from the free version on the website, is pretty general, in that it covers using Python to process text. Yes, pretty much any text. Yes, pretty much anything you want to do with text -- parse it and extract meaning, generate it, manipulate it, you-name-it. Whether it be marked-up, semantically meaningful text, or just a blob of text.
ToEE has been discussed and Tim Cain interviewed at least once a week since the game was announced. Check out IGN, ShackNews, etc. Better yet, dare I say it, ask Google...?
Reply to cons:
;).
Bioware slimmed down the download by not including the extra voice files. Apple's implementation of OpenGL doesn't support the calls necessary to create shiny water (sub-pixel shading, IIRC, though I probably don't...
DM Client: In the Mac box...
Because an awful lot of Dvorak users simply remap the keys on an existing qwerty keyboard. Hard to learn on, but if you master Dvorak on a Dvorak-labeled keyboard, your touch-typing skills should carry over to the point where you don't need the labels. At that point, you can just change the keymap in the OS of whatever other computer you find yourself working on and ignore the qwerty-centric labels on the keys. Working on BIOS, though, one's touch-typing Dvorak skills won't help you because there's no such thing as a keymap utility down that far.
The acronym pretty much sums it up: CMS is a system for managing content. Not necessarily web content, and not necessarily XML. CMSs can be used to store lots of different kinds of content.
MANAGEMENT
A content management system is about managing content in a systematic way. If you examine the premise, it implies a set of procedures for handling content (create, edit, view, delete, and more complex procedures built from these basics) in a systematic, structured way. From these advanced procedures arises the concept of workflow and roles: a writer creates content, an editor edits it, and a publisher decides whether to publish or not.
STRUCTURE
Content is not very usable if it is unstructured. A CMS needs to be able to handle metadata regarding the content. Since XML is a thin wrapper of structure around text, which is one of the most common forms of content, a lot of CMS revolves around XML. Cocoon, though, is not a fully-fledged CMS. It is a very useful tool for taking an XML document and transforming it into a web-viewable format and serving it on the web, and thus can be used as a component of a CMS.
SIZE AND COMPLEXITY
Content management systems are not terribly profitable if they require users to have technical skills in order to manipulate the content. If a system does require a great deal of technical skill to use, then the market for such a system becomes much smaller than the market for a system that allows the average secretary to manipulate content easily. A system easy enough for a secretary also needs to be robust enough to prevent said secretary from damaging the system or performing unauthorized actions. From the CMS developer's point of view, it also needs to scale so that the company is willing to purchase licenses for every secretary, and every other person, in the company.
Making easy-to-use, secure user interfaces to a scalable system that requires structure that is custom-defined for each client company and allows creation of client-defined workflows is generally considered non-trivial. Therefore, most content management systems are developed by companies which hope to sell their system to as many large companies as possible. That's why CMSs are generally large, complex and costly. They involve a high degree of business process re-engineering, similar to ERP or CRM systems.
Exceptions (to the generalization that CMSs are closed-source and high-cost) abound, of course. Zope is perhaps one of the best known open source CMS offerings, and it is scalable, can be made secure, and can have easy-to-use UIs. Making it usable for an organization is still a non-trivial task, though, as a lot of customization goes into it. Which, of course, is how Zope Corp. makes its money -- customization and deployment services.
WEB DEVELOPMENT
You ask "how/if this technology can be leveraged by the average web devloper?" The answer to if is, "Certainly." And here's how: webloggers, for instance, typically use a minimal CMS to make their life easier. Check out Movable Type as an example. For another variation, put together a system with, say, Xindice as the back-end and Cocoon as the presentation service, and add in some easy-to-use XML editor and you have a basic CMS.
"TECHNOLOGY"
In short, there isn't "technology" per se. Instead, there's a problem domain: capturing knowledge, structuring it, subjecting it to validation and other workflows, and then making it easy to retrieve and reuse. Any CMS is just an attempt at an answer to this problem. Certain technologies do tend to fit into the problem domain better than others -- there's a VERY large impedance mismatch between RDBMSs and "documents", though XML and documents go together like ham and cheese. Since XML fits fairly easily into the world of the web, presenting content views as HTML is a common technique.
On the other hand, image
Anything that dense and that much faster than existing memory technologies will need a different memory controller. No getting around it.
The fact that AMD built a memory controller into the Opteron is not necessarily something to be happy about. On the one hand, it greatly reduces latency of memory reads/writes, on the other hand you can't upgrade the memory speed beyond what your entire CPU supports -- you have to upgrade your entire CPU. Which means AMD has to redesign the CPU to take advantage of faster (or different types of) memory. And Opterons aren't that cheap yet...
PPC970 does not support dual cores in one chip. However, there is nothing preventing Apple from using multiple processors in a computer -- or IBM, for that matter, in its blade servers.
I was ignorant, and am now enlightened. More specifically, I was indeed thinking of MPEG-2, but only in a vague, I-should-have-checked-my-facts-first sort of way. I was under the impression that QTSS would stream various formats, but the only way to produce a QuickTime .mov was to purchase the appropriate codec from Apple. And, yes, I realize that's wrong, too. I was remembering some discussions about .mov playback under Linux, where one couldn't play certain .mov formats due to the Sorenson codec used to encode them, which was not freely available. I was under the impression that one licensed the codec from Apple. Whattheforkever, you don't really care about my rambling... for that matter, neither do I.
May I be allowed to mention that there is a significant difference between the QuickTime codecs and the QTSS, and that, while the latter is open source, the former must be purchased...?
I own the book, and it is rather small and unassuming for a book with 801 pages. It is NOT a Wrox book. It is a bit thicker than other O'Reilly Nutshell books (Perl IAN, Java IAN, Python IAN), but it is not quite as thick as Oracle IAN. I suspect they are using slimmer pages than they used to do, but they also seem to be a bit more durable.
I can't really comment on the content yet, as I've been reading through Python IAN first -- which, by the way, is amazingly good!