January 2005 Entries
This is by far the WORST idea I have heard in a long time. What's even worse is influential people like Robert Scoble giving it a nod.
The best thing Microsoft could do for the industry is to sell a SINGLE core, then sell add-on packs that extend the feature set.
Why don't they do this now? Because they make too much money selling you stuff you don't need.
It's part of the reason they have lost even 1% marketshare to Linux. Seriously, if you already own XP, can you just buy the Media Center Add-ons today? Hell no! Reformat and fork over another $150+ for a set of features that you would probably happily go buy for $30.
I really don't want to bash Microsoft, but for Pete's Sake, don't give them any ludicrous ideas of splitting up the OS into so many damned versions that not even the experts can keep them straight.
It's bad enough already. Let say I want to just run a webserver, I could buy Windows 2003 Server Web Edition, (which cuts a bunch of things out and restricts the license so much no one really wants it...) for about half of what I can buy Windows Server 2003 Standard. Same goes for FileServer edition, I would love to just add a FileServer option to XP without having to add SNMP, Active Directory and all the other nonsense only corporations need. In fact, I can't even buy File Server edition, perhaps, that is why mine are running Samba...
What would be better? Let me buy Windows XP Pro and ADD the modules to it that allows me to run a web server... for like $50, not the $400 they are getting for W2K3WE today.
Then it would further allow me to add stuff like Active Directory, or Data Center as a module, let me grow my system as my needs grow. I don't want to replace my entire server just to add some featureset that the lesser OS doesn't have.
After reading Scoble's blog today, I have to admit... Microsoft is doomed if they don't change the rediculously confusing approach they have to selling 12 different OS Versions at the same time. Besides that, their Legal problems would completely evaporate and it would cause them to become innovative in each area in which they wished to compete.
It would also change the whole industry. Why? because all the drivers would actually work on all the OS's because they all have the same kernel and API base.
Longhorn isn't even close to providing something like this even though it is perfectly capable of doing it. Blackcomb isn't looking down that road either. Just think, Microsoft could streamline their entire OS group into making things work even better than they already do by making an Object Oriented OS. But Object Oriented Systems are dead.
Actually I don't believe this for a minute, SOA will never fly on the grass roots level, people are just too paranoid. If they weren't then the NET computer Larry Ellison was hawking would have been a big hit, instead of a flop even after countless revisions.
We need and Object Oriented OS in the worst way, one that is the same from the ground up, one that works on every chipset by recompiling some core modules... but Hey! you say, I'm describing Linux...
No I'm not, Linux is FAR from object oriented, it's a mish-mash of small binary and text files that make no rhyme or reason when it's all put together, ALMOST nothing is common, ALMOST nothing is inherited. Sure, there are exceptions, but it's not engineered that way from the start, UNIX didn't know what OOP was when it was conceived (ok, an onion is an object, but it's still a stretch) and there are so many fallover elements into Linux that it destroys the possibility.
I don't mean there are no OOP elements Any of the Major OS's, but I can tell you with absolute certainty that none of them were architected to be an Object Oriented system to work with completely plug and play components, a common base of administration rules and the ability to run on any chip that can perform boolean math! If any of them do any of those things, they are after-thoughts.
We could make simple steps in this direction if we could just get some major players to agree to adhere to a set of standards that was duplicable and thought out from the ground up with this type of approach in mind.
An OOP OS would let you just attach anyone's word processor and it would inherit all the stuff already in the OS (or what has been replaced in it) like a textbox, a toolbar, a menu, etc. without an installation procedure at all, it would be able to just discover it.
Furthermore, it wouldn't care what you called a file (read extension), because it would know what that file was from the built-in metadata in something like XML format describing the data contained within and how to manipulate it.
But alas, I dream on for the day when “computing” actually makes sense. I suppose that since most people only think we use 10% of our brains, that using 10% of an OS is OK too.
EDIT: I forgot to mention Croquet... Perhaps the newest OS with the most potential I have seen so far, I am going to be playing with this on X.Org's new build as soon as I have a chance to get the installation done.
I found someone with whom I whole heartedly agree! And he has just received $2 million in startup capital to get his next phase of UIs put together.
For an interface feature to be humane it must be easily learned and it also must become automatic without interfering with the learning of or habituating to other features. The present blend of hard-to-learn keyboard shortcuts and difficult-to-automatize menu choices fails on both counts. Adaptive menus and other features that are changed by the system in response to your patterns of use defeat habituation (controls suddenly shift from where you have learned to expect them to be).
Normal human inertia makes it difficult to effect sweeping changes, even when the need for them is clear. It is widely recognized by users and commentators that present-day interfaces and their supporting software systems are not satisfactory, yet to many people inside the industry the need to revise our present interface protocols does not seem pressing.
Jef Raskin is doing some incredible work over at the Raskin Center for Humane Interfaces.
I have been moaning about user interfaces ever since I started using computers, the present state is one of the most barbaric designs we have had yet. I am not picking on Windows or Linux, or command lines, or even the Mac specifically, I loathe them all because they are so counter-productive I spend more time trying to change the interface than I do with any other aspect of computing.
I am currently reading his book, and really look forward to what he is going to produce over the next 18 months.
With Longhorn, XAML, Looking Glass, and all the other stuff on the horizon, they are just rehashing the same old stuff with a bit of lace wrapped around it. We are in desperate need of RADICAL change in the interface system so we can stop playing with these machines and make a giant leap forward in productivity. The TabletPC is slow to be received for One very good reason, the Interface still sucks. Try doing natural work in albeit a wonderful tool for a first real effort and you will be completely convinced that there is a long way to go before “normal“ people are going to be able to use a TabletPC.
The power of the computer most of us have on our desk or in our briefcase is only using at most 10% of its potential (sort of like our brains...), you may not completely agree with this assessment, but think hard about how much time the machine is actually sitting idle or doing tasking that has nothing to do with real productivity for you.
We are still using internal combustion engines and fossil fuels as our main source of transportation when there are obviously better and more efficient alternatives if we could just slap the entrenched masses and businesses into doing something about it, so why should computing really be any different.
Hopefully, we will break out of the Dark Ages of technology soon and launch ourselves into the next generation of technology that will appear as much like magic to us as the television and atomic energy do to a Neanderthal.
As I embark on the beginning of yet another project (they are endless you know...)
Some of the leading Patterns & Practices available for VB:
Is it just me, or do all these look really convoluted when compared to some of the Open Source patterns (i.e. java) that are out there. Most VB developers seem to have a really difficult time grasping the concept of these patterns or need to extend them so much they might as well start from scratch.
I would love to see a place where very small well thought out and tested Public Domain Patterns and Objects could be plucked for use in any VB project and know that they will work well together and across platforms (read Mono Compatible...)
I would sure use them if they existed, sifting through places like CodeProject, etc. has gotten to be a hassle and some of the licensing makes them impractical for standard use.
Don't we have an established set of objects that have become defacto public domain that we can use as a base to extend and build on so we aren't re-inventing the wheel all the time? I actually believe they should be built into all IDEs, but that's just my opinion...
While the above resources are a nice start, I think there needs to be a great deal more available to developers before we can start building on the shoulders of others who came before us. By this I don't mean to just bypass copyrighted work or ignore the work of the giants of the industry or even to discount reuse of my own past achievements and work.
What I mean is this:
Computer Science has been around long enough that we have a set of verified algorithms that are generally taught in every institute of learning to demonstrate how Object Oriented Programming works.
In most applications, whether they be designed for public or private use need to communicate with other software at some level. These communication standards are still far from standard. Developers are writing their own classes when an off-the-shelf solution is perfectly good and would make the application better suited to interact with other software if it only used a Standard Object for something as simple as an address.
Typically an Address is so generic that most people could use the same one. If there needs to be some extra fields then we should be inheriting and extending a standard object to add that item instead of creating an entirely new Object Class that is incompatible with everything else.
VB Developers are just starting to come around to the Zen of Objects.
If they see a pool of Objects that are standardized and available for plug and play use in any program, they just might start using them and the world will start innovating again instead of fighting about whose address format is better. Maybe its just human nature, after all, next time you go to Home Depot look at all the different types of Hammers and Shovels they carry. We can almost equate this scenario with the programming industry, but not quite.
If I need a specialized shovel in VB, then I can start with a crude representation of a basic shovel and extend it or polymorph it into something more suitable to the task of shoveling gravel rather than dirt.
What I would really like to see is a repository for BASE objects that are the same for everything i.e. a Person, and a set of objects extending it that anyone can freely use for writing any piece of code.
Maybe CodeGen will save us in this area and we can have a base set of object that can be generated in any language, but that is another discussion for another day.
Hopefully the new Enterprise Library will be a step in the right direction, but somehow, I doubt it.
This is really appalling; especially since I answered everything honestly.
Overall, you scored as follows:
1% scored higher (more nerdy), and
99% scored lower (less nerdy).
What does this mean? Your nerdiness is:
All hail the monstrous nerd. You are by far the SUPREME NERD GOD!!!
Now why in the heck don't I score that high on my MCP exams...
In this article by Martin LaMonica discussing the pros and cons of Binary XML, there is one thing that is important to remember...
The ONLY appeal of XML to most people is that it is Human readable. HTML and its cousins are all text based for a very, very good reason. If there really is a problem with generating huge amounts of wasted bandwidth, then wouldn't they be trying to make a Binary HTML as well?
The truth of the matter is, yes, they would, and in fact there have been several proposals for compressing HTML, but most revolve around compression for transmission such as using ZLib, an open and widely used algorithm.
If you need to compress XML, then this sort of approach makes way more sense than storing XML in a Binary format that needs a program to read. High traffic programs could just CACHE the ZLib compressed format but NEVER, I mean NEVER get rid of the Text Source of XML, to do so would just make it like any other binary format, useless for interop. Whether it is widely standardized or not you still can't simply look at the text and edit it. Hex Editors are no fun when you have to move data from one source to another. Text Based XML is so appealing and widely accepted by the world strictly because you can edit it without loading it with a special editor.
There is absolutely no reason to even consider Binary XML in my opinion, if you need to compress it, then do it during transmission, not during storage. If your file is so big it really needs compression then maybe you should consider something other than XML as a storage medium in the first place!
Blogroll Me!
Copyright © 2003-2009 H. Steele Price, IV -
All opinions are my own, not necessarily those of my employer, your mother, or any government agency.