thanks for that after about an hour trying to figure out what needed to be removed from the sql server to reinstall got everything installed. still can't find where tfsreports/defaultcollections is located at. so just made a new collection.
I seriously doubt we will actually see 100 core x86-64.
I see a lot of specialization to start occuring. larebee and fusion are a couple of examples.
We may see up to 64 cores at the server level but memory contraints would be a huge issue in such a platform. especially the way that intel chips are currently designed with need for memory bandwidth for performance.
at the consumer level specialization will be much more prominant. 8 cores with 4 graphic cores and 4 gpgpu cores. as an example.
excel would benifit on some calculations with simd support so perhaps an expansion of simd processors.
The constraint really is going to be how to connect memory to those all those cores(unless we build memory onto the CPU itself.
At least if you are going to compare it to OS/x make sure you get it in order who borrowed what from whom.
Spotlight was borrowed from desktop search. Gadgets oh have been around since OS/2 days. way before konfabulator etc were even thought of. and came to windows first. (desktop x stardock) Calendar I'll give you ya. games I don't count as they typically are
removed from business installs anyway.
Current taskbar imo is an evolution of the current task bar. that aside, there have been plenty of other ideas out there that both apple and ms have borrowed from;)
MacOS does use dlls or sos. It gives the appearance that they don't exist because the application you are clicking on is actually a directory with an extension of .app. Everything the application depends on is in the directory so when
you drag it around places, everything goes with it. As for shared dlls, they are stored in the library directory. The application contains a manifest that tells it which libraries it relies on. Its all very simple.
so in theory MacOS can still suffer from dll hell unless the library directory stores multiple versions of the Library.
How come this looks very simuliar to the idea presented for the mail client with WinFS as the store.
I appears to me that Everything is being setup so that it can be easily imported onto a winFS store at a later date. With .eml, .contact and .nws as the file backed store with a schematized store.
Or more basically the Jet store currently readily available. and in wide use in current windows. (on the server side. Active directory, Exchange, client side, Outlook I believe is or was on jet store) Will be phased out and moved to a sql based storage engine
that is more integrated at the FS level. WinFS.
Would that be a fair assesment or is it too early for that to be talked about.
Basically to me Jet is being used as a place holder for some of the common store concepts with file backed systems until WinFS can be delivered.
I havn't heard the full story on how RSS is being stored in the common stoarage platform but I imagine it will have the same story. and then be easily movable to the WinFS platform.
The reason I ask, is that one of the dev's pm's ?? on the search team asks or questions if WinFS is needed at this point. And states that most of the items shown in the WinFS video is achievable in the current vista platform.
I personally believe that it is, and that is because WinFS extends the current db idea with composable ojects. The best way to look at that is that the System can start to understand the domain it is in.
A contact for example can be a client. and based on the system understanding what a client is. can be modified to prevent simple mistakes. as breaking attorny client privaledge etc.
Relationships is another thing that WinFS brings in that is very strong. with that I wonder what new paradyme that will be introduced into the UI to handle that in the future.
All in All, most everything that I have hoped for has started to show up in the client. now just add RSS aggregation that reads from the common store and you have it made.