Home Messages Index
[Date Prev][Date Next][Thread Prev][Thread Next]
Author IndexDate IndexThread Index

Re: [News] WinFS Dies (And Yet ANOTHER Feature Conceded)

begin  oe_protect.scr 
Roy Schestowitz <newsgroups@xxxxxxxxxxxxxxx> espoused:
> __/ [ TheLetterK ] on Sunday 25 June 2006 17:33 \__
> 
>> On Sun, 25 Jun 2006 10:22:00 +0100, Roy Schestowitz wrote:
>> 
>>> __/ [ TheLetterK ] on Saturday 24 June 2006 22:57 \__
>>> 
>>>> On Sat, 24 Jun 2006 22:29:45 +0100, Roy Schestowitz wrote:
>>>> 
>>>>> I won't link to MSDN, so here is the blurb (or gist):
>>>>> 
>>>>> WinFS is Dead
>>>>> 
>>>>> ,----[ Quote ]
>>>>> | The official word from the dev team is that WinFS will no longer be
>>>>> | developed as a relational filesystem, and all future betas are
>>>>> | cancelled.
>>>>> `----
>>>>> 
>>>>>                 http://digg.com/software/WinFS_is_Dead
>>>>> 
>>>>> WinFS was set to be an abstraction layer to NTFS, so interoperability
>>>>> with Linux was never a pressing issue. Hard-drive encryption in Vista is
>>>>> another matter altogther...
>>>> 
>>>> Looks like they're going to try to merge it into SQL Server. Not terribly
>>>> surprising, really.
>>> 
>>> Hmmm.... a filesystem that is dependent on a product or is accessible
>>> through a separate product. Interesting, to say the least...
>> 
>> Not really. It's function has changed now. They seem to be abandoning the
>> whole 'desktop database filesystem' notion.
> 
> 
> Yes, of course. I can recall the time when the boss said it was the "big
> thing" in Vista. Boy, will he be disappointed... I can help him migrate to
> Linux. I already had him installed some Google software and accept LaTeX and
> BibTeX. He seems as though after 40 years in computing he begins to dislike
> proprietary stuff....
> 

Microsoft's problem wasn't about having interesting ideas about where
their systems could go, it was a fundamental engineering problem - their
code-base has become totally unmanagable.  The 1990s drive for "marketing
lead companies" provided some organisations with a convenient excuse for
abandoning engineering excellence in favour of turning junk out of the
door rapidly.  Unfortunately, for many, or perhaps most, engineering
companies, the junk builds up, and the experienced engineers leave.
The next generation were not trained in how to do proper engineering,
so are unable to fix the problems, and HR have convinced themselves that
engineers are people that you "just hire".  HR can take that view, of
course, because they have no engineering background whatsoever, so are
in the fantastic position of being completely ignorant...  there's no
better place than total ignorance from which to make such decisions.

Returning to the filesystem question specifically, I think that being
able to find things on a machine is highly important, but on linux
machines, this is far easier than on windows machines, because there is
a structure to the filesystem in the first place, which is well defined
and adhered to generally.

Perhaps what could be useful would be to create a higher-layer function
to combine the capabilities of locate, dpkg -S, -L, find, fuser, ps,
w, netstat, man, info, /usr/share/doc, tcpdump, mount, /proc, file,
so that any entity which can be displayed can be identified easily,
rather like the "properties" tabs in MS Windows were intended to do,
but never really did.

Having re-read my para above, it's almost like a request for a special
shell dedicated to identifying things.  Some careful consideration about
priorities and context could help to determine the most useful output
to present to a user.

-- 
| Mark Kent   --   mark at ellandroad dot demon dot co dot uk  |
Good day to avoid cops.  Crawl to work.

[Date Prev][Date Next][Thread Prev][Thread Next]
Author IndexDate IndexThread Index