Skip to main content

On Apples And Oranges

I am no market analyst. I would never want to be one, for that matter, so I am not.
I am, however, stalked by several thoughts on the matter of yesterday's Apple's announcement of "plans to deliver models of its Macintosh computers using Intel microprocessors".
The questions, which are bothering me are:
1. The Megabytes Myth.
Is it just me, or somebody else remember, too, that first G4, and than G5 processors were introduced as first true 64-bit processing chips (after G5s appeared, the G4s somehow were removed from the 64-bit processing scene, anybody remember that? I am still compelled by the fact, that my iMac Flat Screen is not a 64-bit processor ANYMORE, but I understand now why it's running so slow recently. It used to be a lot faster, when it was a 64-bit. Sucks.), which are incomparably better, than whimpy Intels?
From the no-market-analyst point of view, there are two explanations to this phenomenon: a) The Megabytes Myth is not a Myth, which subjectively very much appears to be true, or b) The PowerPC processor is going to follow the Betacam path, as being to expensiveve to be profitable, regardless of it's superiority.
In both cases the customers (us, that is) are getting (or were for a while) screwed by our beloved company. Pick your answer, relax, and try to enjoy it.
2. The Mac OS X+.
The fact that Apple plans to produce computers, capable of running Windows OS as well as Mac OS is very scary looking - for me, again. Although it would be very convenient from the professional point of view to run Windows natively from time to time, without resorting to painfully slow VirtualPC emulator (as I have to do, being a web designer, and designing for the web means necessity to account for 96% of the surfers, using IE for Windows), my unprofessional point of view is rather simple: for as long, as Macs were unique under the hood, they required a unique operating system to run, which resulted in a very nice one - eventually - OS X. If Apple adapts the generic technology, the need for the OS will die. Slowly and painfully (again, for us, users). Apple will make pretty machines, which will happily run Windows OS, and happily charge us for classy design and fantastic packaging, along with the overpriced support.
Guess, who are getting screwed in this scenario.
I am no market analyst. But not everything in this world is profit-oriented.
I am just a guy who used both Macs and Windows-based PCs, and liked Macs better.

Popular posts from this blog

WordPress: How to add custom fonts to a twenty seventeen child theme.

Quick help to those who have tried to find some help and failed (as I have so I have to write the code myself). Assuming that you have your virgin child theme configured and activated: here is a function which goes into the functions.php file (of your configured and activated child theme): function childtheme_twentyseventeen_fonts_url() { $replace_original_font = true; // unless you really like Libre Franklin if ($replace_original_font !== true) { $hyph = '-custom-'; } else { $hyph = '-'; }; $font_families = array( //add your Google fonts and weights (400 and 700 are defaults for normal and bold) here: 'Oswald:200,400,700', 'Lato:200,400,700', ); $query_args = array( 'family' => urlencode( implode( '|', $font_families ) ), 'subset' => urlencode( 'latin,latin-ext' ), ); $fonts_url = add_query_arg( $query_args, 'https://fonts.googleapis.com/css' ); wp_enqueue_style( 'twentyseventeen' ....

How to Make a Website Everyone Has

On The Endless Wonders Of Internet Explorer

May be somebody will stumble upon this post and save some time for him/herself. Apparently—it only become apparent after several hours of trial, cursing and error, as it usually goes with IE—, Internet Explorer (up to version 7) throws a runtime error, if you try to modify innerHTML of the dynamically created element under certain conditions. The conditions, as it always go with IE, are significantly lacking consistent logic. For starters, if you assign innerHTML to the element before you insert it into a DOM tree, the error may not come up at all, but will surface later, when you try to modify it. So far it looks like the error mostly comes up, if you change innerHTML of the block element inserted into inline element (which is not kosher in standard-compliant HTML, so it makes sense), and some nested block elements (like DIVs inside Ps—why is that considered wrong, too?—for instance). So, if one really-really need to insert a division into a paragraph, and w...