Has Longhorn's "redefinition" pushed DX10 forward?

[davepermen]

that is about the idea. no stupid folders anymore (except if you want to), but grouping. implemented with sql-style queries.

so i can have all photos of the 11. 5. 2003, all photos where i'm on, all photos with sunshine, blabla. group, organise, sort, how ever i want. in the end, they are all simply my picts.

you can't organize like that now. you have to choose what attribute you want to group, and create folders for it. this is not really useful.

i can have such a group "Dj Tiësto" wich filters everything that has tiesto in it, another group "Radio Records" wich filters everything that is not ripped from cd, but from a radio-stream, and if i open both, i get all the dj tiësto streams.


for an idea on the power of tomorrow, check out the photo application that microsoft has in built. with image similarity, person detection, 3d view, etc.. this, but for all files.

 

[Rodéric]

That's nothing new, BeOS have BFS (Be File System) with live query since years already (since BeOS R1, in 1995(?))...
They had a database driven FS at a time @ Be, but it was too much burden, too many problem on reset and such, so they went to BFS, journalized 64bit file system with user attributes and live queries.

Like always it's all about marketing, ZERO innovation.

 

[Lezmaka]

Hrm....how often do people actually search for files, though? Seriously...I do it maybe once every couple of months. I don't see it as being that necessary to supplement the filesystem for something I don't see people doing commonly. It'd be better just to have a better search engine, one that stores data from previous searches.

http://www.winsupersite.com/reviews/longhorn_4051_05_lhue.asp

What if I wanted to see all of the documents I've created or saved that are related to Longhorn? Right now, there's no real easy way to do this. I'd have to specifically include the word Longhorn in the name of each file, and then search only by file name. Or I could search for the word Longhorn inside of documents, which would be somewhat useful, unless of course I wanted to see image files related to Longhorn.

Read the sections "Fun with metadata" and "Contacts" in that link for more info on it.


But even though WinFS won't be included in the original release, they say it's not supposed to make much of a difference for end users.

WinFS will not be included in the initial Longhorn release[/url]]One bit of bad news is that the oft-touted WinFS storage engine will not be included in Longhorn. However, there's been a bit of misconception about WinFS and which features it enables, and Sullivan was quick to clarify that. "Longhorn will still feature a very rich search experience," Sullivan said. "It's kind of a mistake to equate local search with WinFS. They are different platform elements. So local search will still happen, and we will still deliver a very compelling full text search in Longhorn, alongside new shell capabilities. This will provide some semblance of the 'Find My Stuff' experience. But it won't be the full relational store with deep integration and platform exposure via APIs. For end usrs, however, it will be the same. We will offer a very compelling user experience for local search inside of Longhorn."

I think, even with WinFS, everything will still have a set path as it is now, for backwards compatibility, but you won't have to know exactly where something is on the hard drive to be able to access it. Just like you don't necessarily have to know where something is located in a database (ie record #432) to access it.

 

[Trawler]

Going way offtopic now, but what the heck. At least I can contribute for once!

I can't say I'm a fan of the approach to using both NTFS and Yukon (that's news to me).

What's wrong with NTFS then?

I don't have a bone to pick with NTFS.

I simply take issue with any system, whether it be a small application or an OS, that uses multiple data sources when just one central store would do the trick. Just adds more points of failure. :?

 

[dksuiko]

Like always it's all about marketing, ZERO innovation.

So what's your point? BeOS is also dead. MS is attempting to bring a new filesystem to their OS. Simply because a small company who couldn't even keep themselves afloat and only delivered to a niche audience implemented a similar idea first, it does not mean that MS should be denied credit for their work. If we are to discredit a developers' work on the basis that a similar idea was implemented elsewhere, then no developer would be considered innovative as mostly everyone borrows ideas from someone else. It would be a bit rediculous to have car companies reinvent the wheel everytime they develop a new automotive model, would it not? Why demand more from Microsoft?

 

[cho]

in the conceive of SM 4.0, i notice one of them is "Render-to-cubemap in one pass versus 6", so what (and how) gpu parts should be enhance or change for reach this target ?

 

[Rodéric]

Like always it's all about marketing, ZERO innovation.

So what's your point? BeOS is also dead. MS is attempting to bring a new filesystem to their OS. Simply because a small company who couldn't even keep themselves afloat and only delivered to a niche audience implemented a similar idea first, it does not mean that MS should be denied credit for their work. If we are to discredit a developers' work on the basis that a similar idea was implemented elsewhere, then no developer would be considered innovative as mostly everyone borrows ideas from someone else. It would be a bit rediculous to have car companies reinvent the wheel everytime they develop a new automotive model, would it not? Why demand more from Microsoft?

The problem is rather than they are reproducing someone else mistake, which is fault.

(I won't even comment about the remaining of your post, because I can clearly feel anger.)

 

[KimB]

Rendering to a cubemap in one pass versus six doesn't sound very efficient to me. You may save some bus bandwidth, but you'd have a much harder time figuring out which sides of the cubemap a given vertex contributes to, and thus would need to transform each vertex six times (Well, maybe you could get away with sharing some math with opposing faces, but that's still three transformations). You wouldn't get to use bounding boxes and the like that you can use on the CPU-side to decide what geometry to send to which face.

 

[Xmas]

Rendering to a cubemap in one pass versus six doesn't sound very efficient to me. You may save some bus bandwidth, but you'd have a much harder time figuring out which sides of the cubemap a given vertex contributes to, and thus would need to transform each vertex six times (Well, maybe you could get away with sharing some math with opposing faces, but that's still three transformations).

Did you try to do the math?
You don't need to transform six times. You do the model-view transform once, determine the max absolute value of x|y|z and the sign of that value, then divide by the length of that vector to get normalized window coords. Exactly what you do to access a cube map with 3D texture coordinates. The question is rather, how to clip those triangles that span multiple sides of the cube? A single triangle can be visible on up to five sides.

You wouldn't get to use bounding boxes and the like that you can use on the CPU-side to decide what geometry to send to which face.

You obviously wouldn't need that any more because the cube map will see all geometry (in a certain range).

 

[dksuiko]

The problem is rather than they are reproducing someone else mistake, which is fault.

(I won't even comment about the remaining of your post, because I can clearly feel anger.)

Anger? My apologies, didn't mean to make you angry. Though I don't see what would cause you anger, it was just a simple disagreement with your post. So relax, we don't need to discuss it, nothing to fight over.

(*shiver* ...so edgy :? )

 

[Rodéric]

The problem is rather than they are reproducing someone else mistake, which is fault.

(I won't even comment about the remaining of your post, because I can clearly feel anger.)

Anger? My apologies, didn't mean to make you angry. Though I don't see what would cause you anger, it was just a simple disagreement with your post. So relax, we don't need to discuss it, nothing to fight over.

(*shiver* ...so edgy :? )

herm sorry, I meant I feel *your* anger ^^
well anyway I think they are making a mistake with the winFS, they'd better follow the BFS or new MacOS (made by ex Be guys I think, or at least BFS inspired) File System.

 

[dksuiko]

herm sorry, I meant I feel *your* anger ^^
well anyway I think they are making a mistake with the winFS, they'd better follow the BFS or new MacOS (made by ex Be guys I think, or at least BFS inspired) File System.

My anger? Haha, no. If I ever get caught being angry about such a trivial topic, cut my fingers off, please. (After re-reading my post, it does seem a bit aggressive, doesn't it?) In any case, I'm still wait-and-see on the whole WinFS implementation. But I'll end with that - before I further help drive this thread off-topic than I already have. Eek.

 

[Briareus]

The problem is rather than they are reproducing someone else mistake, which is fault.

(I won't even comment about the remaining of your post, because I can clearly feel anger.)

Anger? My apologies, didn't mean to make you angry. Though I don't see what would cause you anger, it was just a simple disagreement with your post. So relax, we don't need to discuss it, nothing to fight over.

(*shiver* ...so edgy :? )

herm sorry, I meant I feel *your* anger ^^
well anyway I think they are making a mistake with the winFS, they'd better follow the BFS or new MacOS (made by ex Be guys I think, or at least BFS inspired) File System.

I thought Job's company was NeXt not BeOS. Also, I know some people that claim NeXt aka Jobs ripped off their ideas and/or stole their code to build the NeXt os which had a large influence on OS.X. So you could think of Apples latest as just a rip off of someone else as well.

There are very few new ideas in software today. Progress today entails mainly commercializing stuff people thought up in the 60s-70s. It just took 30 years for hardware to catch up and make their ideas practical.

As far as WinFS goes it will allow all the application specific databases to be ripped out and handled by the OS making for much easier integration and data sharing between programs. Maybe I should start up a spyware company to focus on exploiting Longhorn users. Just think of all the information that could be extracted with easily searchable metadata of a persons life.

On Longhorn, I think people are underestimating the benefits that support for managed code and security improvements that the OS will provide.

 

[Mariner]

I thought Job's company was NeXt not BeOS.

Please, get the spelling right - NeXT

The NEXTSTEP operating system was miles ahead of both Windows and MacOS for years but the lack of sales meant that it finally fell behind in terms of features - it simply didn't have the investment that Microsoft could pump into Windows. OpenStep was later released for PCs and various Workstations but eventually NeXT was bought out by Apple and this formed much of the core of OS X. I used NeXTstations (from 1991 onwards) and later PCs running OpenStep and it was ridiculous, in the early years especially, how far ahead the OS was compared to the Windows of the time. In all the years of running NeXT software, I never had a programme crash which took down the OS - this in comparison to Windows running on top of DOS, remember, which was out at the same time! Proper SMP and Display PostScript, real WYSIWYG - sheer bliss. I almost shed a tear when I had to stop using OpenStep (only about 18 months ago!) but by then the interface had fallen a long way behind what you expect in a modern OS.

As far as I'm aware Be was set up by some people who left NeXT (a long time after the release of NeXTStep) but this doesn't have anything to do with OS X - IIRC BeOS is now open source?

 

[MfA]

Just because Be couldnt make it work doesnt mean Microsoft (or Hans Reiser) cant make it work, processors have gotten faster too.

 

[LeGreg]

As far as I'm aware Be was set up by some people who left NeXT

actually Be was founded by Jean Louis Gassée
who left Apple.

 

[mavis]

Hrm....how often do people actually search for files, though? Seriously...I do it maybe once every couple of months.

I was hoping it would have something equivalent to views (think either SQL views or the kind of filtering via meta-data you see in Outlook 2003 or Opera's M2 mail-client). Using Yukon you'd be able to create 'virtual directories' based on a view. In pseduo-sql this would be something like:

CREATE FOLDER WordDocs AS SELECT *.doc FROM C:/

This would create a 'virtual directory' (or folder) which contains every word document on your hard-drive, regardless of physical location.

In other words, you should be able to use any kind of meta-data to group together files of a similar nature. You might have MP3s strewn around your hard drive, but could create a virtual folder based on meta-data (found in ID3 tag) such as artist or genre. You might organise your photo collection into different views based on size or which camera took them etc. There are lots of interesting applications from being able to use a relatively high-level SQL-like language to query the filestore (rather like an advanced version of Index Server query language).

Wow, that really sucks!!! So much for tucking all my porn away in some obscure folder on my D: drive ...

lol

 

[davepermen]

SELECT porn FROM local_drives

RESULTS: 343245 Files found



oh oh now explain that to your mom




hehe must have been some advare that created those .. files ..

 

[Dave Baumann]

Actually, security would probably be greater overall. Its probable that whats "displayed" in explorer won't actually be the internal organisation of the files, but different views on "virtual" file structures. With a database driven file system it will be much easier to create roles and permissions hence hide particular files and folders from various groups.

 

[BRiT]

And much greater opportunity for "file-system" corruption....

Now everyone needing to troubleshoot WinFS will have to be DBAs. Brilliant! No, no, really.