|
The Ridiculous Influence of Microsoft
I've been reading with interest the various promises that the Longhorn operating system will bring to fruition (never have I seen the Microsoft PR machine so in force so early before delivery -- usually this is to stop customers who might be considering an alternative with the enticement that something great is "just around the corner". As a sidenote, if you have watched operating system promises and delivery over the years, you'll notice that the actual change delivered in most is dramatically less than that which was promised early in the product conceptual stage) -- I must confess to being both underwhelmed, and more than a little disturbed: Could someone explain the ridiculous credibility that people seem to give to any project emnating from the halls of Microsoft? I have tremendous respect for Microsoft, and they've had a lot of great products (along with a lot of horrible flops and about faces) but I really just don't get it.
XAML - This one introduced the word of the day, currently seen in large numbers from blog to shiny blog, which is "declarative". This "revolution" is basically that the elements of the interface will be stored in a "declarative" fashion -- You know, like HTML (or even a bloody resource file). Of course for the actual interoperations you largely see a standard procedural language. Excuse me if this strikes me as a variation on a theme, and something worthy of virtually no attention.
WinFS - When I see people agog over how directories will no longer matter, and no longer will people have to bother carefully naming files (instead they'll have to carefully fill out accurate metadata describing each file...), and we'll have the amazing abilities of a database backing up the file system, I don't get what all the fuss is about. Firstly, a file system _is_ a highly specialized database (NTFS even uses b-trees in great numbers) - Having a SQL style front-end on the file-system has always been a personal dream (finding files via SQL-92), but it is largely irrelevant for end consumers - they want to find files via a search utility. For that there are countless utilities, including built into Windows 2000 and beyond (or FindFast.exe previously) that index content and attributes, allowing you to find any file in the blink of an eye. NTFS allows one to add custom attributes on files, and of course certain file types have custom attributes (such as all of the extended data in a JPEG file): Again, there are utilities to index and search all of this. What does WinFS offer beyond this? Building a file system on the foundations of a database server seems like nothing more than cross-product shilling.
Neither of these are even remotely revolutionary, and of extremely little consequence to the real world. Why the hype? So far the only element of Longhorn that really interests me is a DirectX desktop utilizing vector graphics and 3 dimensions (the hardware is there now so it makes sense), but beyond that it sounds like a bunch of marketing nonsense.
As a sidenote, how many people are there are using the revolutionary voice recognition functionality widely hyped and delivered in Office XP? My guess is that less than 1% of 1% of 1% of OfficeXP customers use that feature, and I feel that I'm over-estimating.
Dennis Forbes
Saturday, November 1, 2003
If you think this is a lot of hype, wait until Apple makes it's next batch of announcements.
anon
Saturday, November 1, 2003
I've never seen anyone ever use voice recognition on their PC ever.
Matthew Lock
Saturday, November 1, 2003
About voice recognition -- I have seen once blind people using computer which was driven, among other means, by voice...
Srdjan
Saturday, November 1, 2003
The voice recognition that came with System 7 around 1994 was pretty good. You could say "Computer, Font Arial", and it would change the selected text to Arial. Then you could say "Computer, Bold Text", and it would do that. And you could say, "Computer, what time is it?" and it would speak the time in a lovely femal voice. But then you realized that it was a lot faster to just use the keyboard or look at the menu clock.
Ed the Millwright
Saturday, November 1, 2003
about voice recognition... when it gets much better, it'll be useful.
but speech synthesis works well today. why on earth doesn't windows have easy text-to-speech? it has the capability, just no good UI. Excel can do this (speak cell), but Word can't. And Windows has 'accessiblity' support, but it's useless for a normal person.
what is text to speech useful for? proofreading!
does longhorn have the text-to-speech app? (or maybe winxp has it, and i just haven't found it yet.)
mb
Saturday, November 1, 2003
I think the trend goes like this - dominant players in consumer and business software want to provide additional functionality to end users who, at the end of the day, are a little bit thick.
For this to work, they have to make everything mushy so it can be sucked up through straw, so to speak. It makes it all more accessible to search facilities. But goodness me, the effect for software developers, having to wade through all this slosh.
In summary, Microsoft is providing slightly greater functionality to users, enabled by greater complexity, as always, but this time it's also become very sloppy for the programmers working with it.
(const tchar*) &me
Saturday, November 1, 2003
Same old, same old. I try not to even comment any longer. Can you imagine the PHB, who has to contend with engineers who have shipped stuff to the field, and are having some trouble...
<sigh> if only I have partnered with Microsoft... Where is my beautiful wife? Calgon, take me away...
Oh, they have Longhorn, better than Viagra and it has virtual foolproof blah, blah, blah... I get so confused with "C: drive" computing.
Somebody please fix my world. I need a silver bullet.
Never mind...
nat ersoz
Saturday, November 1, 2003
Please, please, please, please don't put voice recognition or speech output on any computer near me.
The same morons who bombard me with their childish cell-phone ring-tones will think they have died and gone to heaven.
HeWhoMustBeConfused
Saturday, November 1, 2003
Remember Microsoft's hype surrounding a product and the quality of that product tend to be inversely proportional. In other words longhorn is loserhorn.
Obvious
Sunday, November 2, 2003
"a DirectX desktop utilizing vector graphics and 3 dimensions"
Are you kidding. Users can't handle double clicking icons on a two dimensional desktop. How the hell will they handle 3 dimensions.
Help Desk to user: No, it is the icon partially underneath that one...
obvious
Sunday, November 2, 2003
I still remember people salivating over "Cairo" which was supposed to cure cancer and butter your toast in the morning. When the hype machine couldn't take it anymore "Cairo" was demoted to "a series of upcoming technolgies". In the end we got the next version of Windows NT.
Run To The Hills
Sunday, November 2, 2003
I would guess that by "3D/vector-based" they mean something like Quartz (in Mac OS X) - i.e. nice drop shadows and the like - I don't think Microsoft would be silly enough to provide a 3D UI, leave that to startups preying on naive investors.
Walter Rumsby
Sunday, November 2, 2003
Didn't Microsoft Bob have sometihng of the 3D about it?
John Ridout
Sunday, November 2, 2003
About a database filing systems: There were several occasions I wanted that in the past, and "indexed attribute" filesystems would not have helped me.
I had several servers, and I wanted to know which users have files on which servers. That could have been done as a select statement that joins inputs from several machines.
The real strength comes with the ability to join against other databases - e.g., a select that involves both the filesystem and the HR database. But for this to go beyond theory, many programs will need to change, in a significant way.
My guess is that this feature will mostly be abused. For 99% of the uses, better search tools (Unix 'find' and 'locate') are sufficient, and don't require much software to be modified.
Ori Berger
Sunday, November 2, 2003
As I understand it AS/400's filesystem is basically a DB/2 (aka DB/400) database. Do people do the kinds of things that Ori mentions with AS/400?
Walter Rumsby
Sunday, November 2, 2003
> usually this is to stop customers who might be considering an alternative with the enticement that something great is "just around the corner".
If so, then the XAML announcement must mean that they're really worried about the Web (again).
> The real strength comes with the ability to join against other databases - e.g., a select that involves both the filesystem and the HR database.
If the benefits were so huge, we could simply write all applications as database applications.
Portabella
Sunday, November 2, 2003
The thing with speech recognition is that people tried it four or five years ago and it sucked so much they dropped it completely.
The software still sells and a combination of better programs and Moore's law mean that it is not the lemon it used to be, but it still doesn't provide significant advantages over typing. It appears that after training the program can get to a speed of about 40 words a minute, which is well below the typing speed of a secretary and round about the typing speed of the average teacher, freelance writer or whatever. However using speech recognition and then correcting everything after breaks up the workflow much more than typing does.
Stephen Jones
Sunday, November 2, 2003
I work with Language Learning software, and many of the programs have speech recognition - hélas. There is one which grades your accent from completely incomprehensible to native level. A small proportion of our students managed to get grades native level but all of us teachers wallowed in the completely incomprehensible until we learned that the trick was to try and imitiate the students. I'm told that in tne French versions the trick is to try and imitate Peter Sellers.
We used another program (which is unfortunately unavailable now because Syracuse Language Systems sold it to Vivendi who went bust and didn't leave anybody around who was prepared to sell you a copy or a few hundred). This had certain activities where you would speak into the microphone to perform certain instructions on screen. The normal man/computer conversation would go something like this:
"Turn right!
Turn right!
TURN RIGHT!
T U R N R I G H T !
TURN RIGHT FUCK YOU!"
Stephen Jones
Sunday, November 2, 2003
HeWhoMustBeConfused, make sure that there are NO WinXP/W2K3 computers around you! Otherwise warn anyone to be ready to be killed by you:)
All Programs->Accesories->Accessibility->Narrator
WildTiger
Sunday, November 2, 2003
awesome! were is my C-64???
Scot
Sunday, November 2, 2003
I have a couple of friends who are UNIX admins with voice recognition software -- they have RSI to the extent that they cannot type (or in one case hold their motorbike handlebars -- he had to sell it) and rely on the voice-rec to run things.
Some people do use it, and use it well.
Katie Lucas
Monday, November 3, 2003
To clarify my original point - yes, voice recognition is a good feature as an accessibility feature. Having said that, Office XP's largest promotional feature was voice recognition - this is how people were convinced to upgrade to XP over 2000 or earlier. I would continue to wager that tremendously few people used it beyond trying it out once for a "wow, neat" kind of use, or for accessibility reasons.
Dennis Forbes
Monday, November 3, 2003
I think Dennis is right on the money.
MS's OS model seems to be built around taking the more popular utilities of the day, bundling them with the OS, and flogging it all off as the next generation.
DiskStacker?
Defrag?
Scandisk?
Tapiwa
Monday, November 3, 2003
I think that most people are not seeing a lot of what the ‘DBMS’ storage has to offer. Certainly it *could* (and probably will) provide a convenient interface to search file attributes… but the biggest feature is that as an application developer no longer do I need to write code to store my data in a file somewhere – it can all live in the OS DBMS. Indeed, the whole concept of a user-exposed ‘file’ is vestigial and probably will only be maintained logically for supported applications (e.g. they click on an icon of a Word document which really is a bunch of rows in a DBMS table somewhere).
Practical benefits of DBMS storage are many. I no longer need to, as an application developer, deal with my own custom file formats and libraries necessary to write out, read in, and parse the data. Also, since the data is stored in a globally accessible DBMS it’s trivial to get the data from *other* applications. I could write a portal for my desktop which runs a few select statements that gathers new email headers, the contents of some of my favorite websites (“view this page offline” would pull them into my DBMS cache), etc.
Let’s say I wrote a bunch of proposals for the Johnson account. I don’t remember which document contains the data I need today, so I write a query that would get the paragraph headings of all word documents relating to the Johnson account and browsing through them I can see which I need for today’s meeting. Of course, I could also tie them into my organizer calendar to “attach” them to the 2PM meeting so I don’t have to go search.
The downside is that now it is trivially easy for viruses and worms to access data they shouldn’t, but of course this happens now without a convenient interface. If anything, now that a DBMS is in place you can take advantage of finer-grained access control rules (per-row rules could, for example, give you access to only selected parts of a Word document) which actually might make the system *more* secure.
Logical locking would enable applications and users to work on different parts of a file at a time without causing locking issues, and the DBMS could easily store old records – thereby ensuring that you have document change management built-in to any document (not just special documents nor requiring custom applications).
Copying data from OS to OS need not be a giant hassle either – DBMS data replication has existed for over a decade now and provided you’re copying from a WinFS to WinFS system you can copy the rows directly. If not, it’s not too difficult to stream it to a file as you transfer.
Obviously the hardest part is going to be migrating tons of non-WinFS applications over. Since the WinFS is applied on top of NTFS the existing apps will still be able to use the same file paradigm as before while new and updated apps will be able to take advantage of the DBMS storage.
MR
Monday, November 3, 2003
"The thing with speech recognition is that people tried it four or five years ago and it sucked so much they dropped it completely."
Desktop voice recognition isn't terribly exciting when you're dealing with an interface designed around graphical scree elements. Voice recognition, however, is much more widely deployed for telephone, help desk style applications. For better or worse.
Jim Rankin
Monday, November 3, 2003
> Practical benefits of DBMS storage are many.
... but as an application development model(*) it was roundly trounced by OO programming.
Why should things be different this time around?
* I hope it's obvious that I'm not talking about applications built *with* databases, but rather applications that are database-centric: eg, instead of exposing an API, they expose a database schema.
Portabella
Monday, November 3, 2003
"I no longer need to, as an application developer, deal with my own custom file formats and libraries necessary to write out, read in, and parse the data."
How in the world does a db backed file system relieve you of this task? The OS still gives you a "blob" and you fill it with your custom data. There is nothing about this system that in any way relieves custom data requirements.
"I don’t remember which document contains the data I need today, so I write a query that would get the paragraph headings of all word documents relating to the Johnson account and browsing through them I can see which I need for today’s meeting. Of course, I could also tie them into my organizer calendar to “attach” them to the 2PM meeting so I don’t have to go search."
Firstly, searching text presumes that either the document format is in plain-text, facilitating such searching (nothing about WinFS offers this), or that there is a utility search tool that knows how to interpret the binary format, such as Word, and seach for given text. Such features exist. As far as linking to your calendar, that's what UNCs are all about (file://..).
"Logical locking would enable applications and users to work on different parts of a file at a time without causing locking issues"
Such a scenario - that an application stores a single "whole" in many parts, is an application choice - it has nothing to do with the underlying file system. Whether it's 10 separately locked files (like an aggregate Word document), or 10 Blobs, it is absolutely no difference.
I hate to say it, but your idealistic message is exactly the sort of pie-in-the-sky dreaming that gets technologies like this far more credit than they deserve - This is not a new standard of document formats (if there was such a thing I doubt Microsoft would implement it), and virtually everything else that you said can be done in a regular filesystem - it doesn't need a RDBMS.
Dennis Forbes
Monday, November 3, 2003
“How in the world does a db backed file system relieve you of this task? The OS still gives you a "blob" and you fill it with your custom data. There is nothing about this system that in any way relieves custom data requirements.”
Well, no, you would no longer have a ‘blob’. In the case of an email, it would be a relational table (or tables) which contain from email, to email, title, body, etc.. I would INSERT INTO email VALUES( xxx. ) and select from it to generate your list.
As I said in my post if you have a legacy app it would use the same filesystem storage that it always did (so Word 2000 would still create binary files that no one can view etc.), only the new applications would use them. However for the new applications they would use relational tables (relations) to store their data. A Word document can be decomposed into sections, headings, paragraphs, sentences, etc. and then selected to reconstruct the document. Searching is then a simple matter of the engine’s full-text searching the specified field (which most SQL DBMS have, including SQL Server – I think they use the Verity product).
“Such a scenario - that an application stores a single "whole" in many parts, is an application choice - it has nothing to do with the underlying file system. Whether it's 10 separately locked files (like an aggregate Word document), or 10 Blobs, it is absolutely no difference.”
In the case of DBMS storage the application now no longer HAS to care – that’s what the DBMS is for (and why we shell out big bucks to Oracle, IBM, Microsoft, Sybase, etc.). Why reinvent the wheel?
“This is not a new standard of document formats”
From Tom’s Hardware: “What is clear, though, is that Win FS is modeled on the file system of the coming SQL server (Yukon), whose FS is based entirely on a relational database.” It is not entirely clear how deep LongHorn is going to delve into the DBMS store that Yukon can provide, but how MS is touting how this will change how applications are written it’s clear they mean a whole heck of a lot more than attribute lists in SQL. Baby steps will have to be made of course, but I think the future *is* in some sort of relational DBMS. The relational model is a generic data model and the benefits it could provide as a unified storage model are huge – someone just needs to go make it, and I’m not in the business of writing complicated DBMS. :)
Portabella you’re going to have to explain a bit more. I’ve worked on systems which are quite OO and used a SQL DBMS for storage and logic with great success. It just takes a little bit of thought.
MR
Monday, November 3, 2003
> Portabella you’re going to have to explain a bit more. I’ve worked on systems which are quite OO and used a SQL DBMS for storage and logic with great success.
So have I -- it's what I do :)
The point is that those applications are usually thought of in terms of APIs and OO design, *NOT* in terms of the DB schema, constraints, etc. This is exactly the part of the application that everyone wants to hide.
There's no reason why we couldn't *already* build all applications as database apps; I just don't see what, if anything, WinFS changes there (*). For better or worse, mainstream development has soundly rejected that model.
* I do recognize that the new database is built in to the OS and cheaper
Portabella
Monday, November 3, 2003
What you are talking about -- apps storing their data in a database -- is not at all what WinFS is about. As it is, as Portabella has mentioned, if an app wants to store its data in a database, they can go nuts and do it. If they want they can install the freely distributable MSDE (a pared down version of SQL Server).
WinFS is about replacing the file-system (the place where apps store blobs that we know of as files) with a database system, making it easier, hypothetically, to centralized and index all of the metadata. Of course I can already add a file notification on entire drives, and index all metadata. It is a nice feature, but on the grand scheme of profound technological breakthroughs, it is somewhere around a 1 out of 10.
Dennis Forbes
Monday, November 3, 2003
So people design applications with no regards as to what data they are going to use and store? That sounds like a really hard way to design applications. :)
I think the benefit to WinFS, if MS is implementing it as such, is that now every application that runs on the OS has a common DBMS that they can use and further can access everyone else’s data. It’s like constructive interference (for lack of a better term that I can think of) – the more applications that use it the more valuable it becomes.
Probably the reason that many applications don’t use one now is that they’d have to bundle a DBMS with their product that brings licensing costs and installation/maintenance headaches. If you knew the DBMS was going to be installed and running on the OS your app used I think there would be very little barriers to use.
MR
Monday, November 3, 2003
Dennis,
What definition are you operating under?
Take a look at:
http://www.zdnet.com.au/itmanager/trends/story/0,2000029592,20279929,00.htm
Pertinant quotes:
"a data storage system called WinFS"
"For nearly a decade, the company has touted the vision of a single storage system that would break down barriers between applications and serve up stored information quickly and accurately. "
“Microsoft calls WinFS ‘the next-generation storage platform for Windows (that) manages data for organising, searching and sharing.’ With WinFS, the company seeks to create a common system for finding and storing data across all types of Windows applications.”
This is, to the best of my knowledge, exactly what I’ve been discussing. If you have documents to the contrary, then please provide them. However, the "vision" I have explained is not new to MS. What I’ve discussed is what they've wanted (and been toying with in the lab) for a long, long time. They, apparently, finally think that their SQL product is good enough to try it. And even if they are not doing it right now with LongHorn I guarantee you they will at some point in the future (otherwise the SQL Server backend is pretty much useless. You don’t need a SQL engine to search meta-data only).
MR
Monday, November 3, 2003
That particular element of WinFS (you can read all about it at http://longhorn.msdn.microsoft.com/portal_nav.htm) I categorize in the "high vapourware" category - it is easier to talk about the grand ambition of universal schemas for all applications than it is to actually execute the same). The core element of WinFS, the part that is likely to actually see the light of day, is that an NTFS volume is replaced by a WinFS volume (though actually the WinFS volume is running atop a NTFS volume...) - so now when someone does a CreateFile on a WinFS volume, it's going through a RDBMS. The benefits are pretty vague, and include the indexing of metadata (or possibly content - it probably depends upon appropriate content handlers). Oracle has been doing this "RDBMS as a file server" trick for years.
Dennis Forbes
Monday, November 3, 2003
> Probably the reason that many applications don’t use one now is that they’d have to bundle a DBMS with their product that brings licensing costs and installation/maintenance headaches.
That's precisely where we disagree -- thanks for making it clear! :)
I think most applications do not use a DB because using one is complexity that they simply do not need. The licensing and installation are problems, but not major ones.
WinFS says to me that *Microsoft* really wants its developers to use the "new" DB. The last time they talked about this -- the ill-fated Cairo -- they were *really* worried about Oracle encroaching on the desktop. I assume all of the Longhorn push has similar themes.
Portabella
Monday, November 3, 2003
With regard to speech recognition, John Ousterhout wrote an interesting article on how he uses it after getting RSI:
http://home.pacbell.net/ouster/wrist.html
He uses Dragon Naturally Speaking, which he describes as "wonderful".
as
Monday, November 3, 2003
>How in the world does a db backed file system relieve you of this task? The OS still gives you a "blob" and you fill it with your custom data. There is nothing about this system that in any way relieves custom data requirements.
I have worked on systems where virtually every single file, dir and even code is stored in a database. (the pick system works this way).
As for custom data requirements? Fact is, why does Excel use a different data format then does Quicken Accounting?
I mean, if Quicken, Excel, and WinFax pro all used a common data format, then I could easily read the data from any of those applications. Further, I COULD SEND YOU any of the above data files and YOU COULD READ/USE the data WITHOUT HAVING TO install the application! My gosh, the computing practices we use right now are all wrong, and a common database format for all data is what we been lacking for so long. Can you say stone age?
Imagine, no more propriety data formats for WinFax, Quicken, Money, etc etc. Pull data from Outlook to your own cool little contact manger that YOU write! Why should I even have to install Outlook to read some outlook data that you send me? Give us all a common database to store this stuff, and we will break free from each application having to come up with their own database formats. Sure, some still will still be binary...but for the most part, any type of application data that can be stored in a common database format for ALL TO USE is a HUGE BENEFIT to all.
It is only people who have not experienced systems with a common database for everything that don’t get this huge benefit.
I mean, every game producer used to make their own sound drivers. Finally, windows standardized the sound cards. I can’t believe that windows has taken so long to come up with a standard for data?
Gosh, we can use Quicken, Oracle, JET, Excell,...whatever we want...and still get at the data, and not even have to install the application!
I mean, don’t any of you think that the ASCII standard was of any use? I am betting that standard comma delimited text files is the most common data interchange format right now....and that really getting to be a pain! Lets not get into XML!
Of course, a large part of the application is the business logic, and thus often having a Outlook contact list is not much use without the application...but at least I don’t have to do some crazy import/export garbage that we now deal with. (of course, the solution today is to use com/automation to get data in, and out..and a database system does not necessary change this requirement, but often it does).
Further, once each developer learns the data API’S, then you are DONE!. This makes for fabulous developer productivity as each new product and application has a common database approach to storage and retrieval of data. Why re-invent the wheel each time?
Simply Accounting = JET
QuickBooks = ??
Money = ??
Why every time someone makes an application do they have to come up with some data system? This is so crazy today. 20, or 30 years ago...sure fine...but not now!
Of course, the problem right now is that all those propriety formats from WinFax to Quicken to dbase currently exist, and thus most people have never experienced a OS that has this record management system built in.
This change is so very long over due...and in fact might be even too late to really realize the benefits.
How incredible would windows be with a common data format! Must we contine to tie data to each applicaton like we do now?
We would barely need email to send, and receive data. Stuff like cool peer to peer based data replication built into a system?. We could have gotten rid of a large portion of central server systems years ago with these types of systems!
Have some vision folks, as a common data format is really the Holy Grail of computing.
Albert D. Kallal
Edmonton, Alberta Canada
kallal@msn.com
http://www.attcanada.net/~kallal.msn
Albert D. Kallal
Wednesday, November 5, 2003
"Have some vision folks, as a common data format is really the Holy Grail of computing."
Do you _really_ think Microsoft will be the one to bring the world common data formats? If you truly believe this, then you are absolutely blind to history. Microsoft has generally done everything they can to obfuscate and make inaccessible their data formats (it's lock in and a forced network effect), so hearing them talk about a generic file format per WinFS is one of the most disingenous and hollow things I've heard in a long time. The generic file format for MS apps will be a blob field full of 4MB of binary encrypted data.
In any case, as I mentioned earlier, this is a task that is _much_ easier said than done. If it were to be done, an API or database-based data system is hardly a step towards the solution (although it might appear to be a false start) - Instead lets see some standardized schemas for each application or data type - THAT is a start towards this panacea. Waving ones hands and saying that putting a database under the OS even remotely makes a step in this direction is the height of absurdity (just as saying "We use open XML as our format" is no benefit if your use is undocumented and full of binary encoded fields tha are undocumented).
Dennis Forbes
Wednesday, November 5, 2003
"If you think this is a lot of hype, wait until Apple makes it's next batch of announcements."
The difference is, Apple only hypes products when they ACTUALLY EXIST.
Jim Rankin
Wednesday, November 5, 2003
> Have some vision folks, as a common data format is really the Holy Grail of computing.
And like the Holy Grail, it's probably unattainable except by the purest at heart.
First, what you are talking about is only the lowest story of the Tower of Babel: a common access method. (Note that we already *have* a common access method, namely the file API).
Once you can access the data, you still need a way to understand it, and this is a deep and thorny topic.
It's a lot of extra work to build a data format that *also* serves as an API (ie, is straightforwardly queryable, has backwards compatibility between versions, etc).
IMO, exporting data (probably in XML) is the way to go.
Portabella
Thursday, November 6, 2003
 Recent Topics
Fog Creek Home
|
