1) Games are basic to linux desktops, we need linux games, so if Con scheduler was best on games, please, incorporate those changes.
2) EGO's are a pain in the ass, it seems that Con has been refused by Linus , because he didn't take the whole history into acount, too bad, that kind of things happend in any not trivial project management. Don't let EGO's rule the ball, that's the most basic point a manager (Linus) has to respect to keep people on the project.
Image comparison can be made real fast if it's purely a graphical comparison (ie: detect duplicate/resized images). The problem is when you need to search for 'content' (ie: search 'houses' or 'cats') then the cognitive aspects of the problem results in severe limitations of the different search motors/technologies, each one has his own set of strengths/weaknes.
Visual search engines can be build very differently as you propose. The series of tasks you said (segmentation, texture propcessing, etc) are just 'logical' or 'simple' ways to treat image recognition. there are other models. The problem with image information is that:
1) is poorly defined. What is a 'shape'? for what is worth?, and
2) has a very high level of 'semantic' content, Everyboy knows what a 'face' or a 'car' is, but we cannot reduce this information to a simple set of shape/textures, there's no direct link between human 'objects' and graphical images, that's why image search by content fails so easily.
Without addressing the first point (mathematical image information definition) there's little hope for image search engines.
If what you need is just image comparison, without textual information processing there are solutions (ie: http://www.immem.com/en/). What do you mean for 'avoid the step of extracting text from them, or later OCRing'? Are you doing text or image comparisons?
To compare million images in a second on a comodity pc was already done since 2004/2005 see http://www.immem.com/en/. By now the state of the art is to compare a video stream against a 24h video pool in realtime, using this technology.
File notification was not on the kernel for historical reasons, not technical ones. File notification was not a priority at the time and so was (and still is in my opinion) poorly designed at the kernel level.
inotify is a step in the right direction (the interface looks almost right), but shares the same fundamental flaw that dnotify have, it's unable to detect changes below the desired directories, and NO, adding thousands of watches (one for subdir) is not an acceptable option, it's inefficient and a resource hog, that's why it should never be hidded inside a library.
The idea is quite simple, you tell the system to notify you when a certain branch of the filesystem is accesed/modified. That's not intrinsiquely difficult or time consuming, is just that the current kernel/filesystem abstraction does not fit well with that behaviour for historical reasons, but that should not be an excuse, threads were also a simple idea with a complex implementation, but it was considered necesary and it was done, file notification is not that different.
Inefficient, the parent poster has a point, it's a shame that linux doesn't have yet an efficient system to notify user programs of changes in file systems. Setting up a watch on every directory on the tree is an ugly and wasteful way to make what it should be a simple and logical thing. Making a library to make it simple is just the kind of coding it should never be done, design flaws should never be hidden.
The stats on my own little site (thousands page hits a day) shows a clear incremnent in Firefox usage on those last 6 months, I am not sure about being an european only trend.
Just listening the Islands LP while reading the posts...
I feel sorry for those who don't have the chance to listen old good music in the old fashioned way...
Yes, programming is not easy, and that 'simple' for-every statement could be a real can of worms, but that's programming, trying to 'protect' programmers from mistakes wont help programming as a whole.
The fact is, programmers use to know what sections of his own code could be executed in parallel, but have no easy way to use that knowledge. Let compiler writers start working on implementations (ie. on your example, warn about shared resource (count) being modified concurrently) , is my opinion that there's a big middle ground area where parallel programming could be used, as long as the tools are trivially simple to use.
Sorry,but data is never complete. Mismatches between ancien traditions and current theories about what happened at a certain time frame, use to suffer the 'not modern' syndrome.
Troy (and a lot of other important arqueological sites) was considered a mere myth, due to a miopyc s.XVIII prejudice still present due to the lack of proper philosophical studies in current education.
Software is math. Patents on software are just patenting integer numbers (or sets of integers numbers, if you wish).
So NO, software patents have no sense, no matter the use you or anyone else give to those sets of numbers (encription, compression or whaterever you wish).
Slashdot Mirror
"You don't find the grail, the grail finds you." -- The Da Vinci Code
Missing... 'In Sovier Russia.. ' preamble! :)
The only important points to me are:
1) Games are basic to linux desktops, we need linux games, so if Con scheduler was best on games, please, incorporate those changes.
2) EGO's are a pain in the ass, it seems that Con has been refused by Linus , because he didn't take the whole history into acount, too bad, that kind of things happend in any not trivial project management. Don't let EGO's rule the ball, that's the most basic point a manager (Linus) has to respect to keep people on the project.
Well, what says Wikipedia about it?
Maybe I am wrong, but for a maximal sales impact, Ubuntu should use KDE UI by default.
Image comparison can be made real fast if it's purely a graphical comparison (ie: detect duplicate/resized images). The problem is when you need to search for 'content' (ie: search 'houses' or 'cats') then the cognitive aspects of the problem results in severe limitations of the different search motors/technologies, each one has his own set of strengths/weaknes.
Visual search engines can be build very differently as you propose. The series of tasks you said (segmentation, texture propcessing, etc) are just 'logical' or 'simple' ways to treat image recognition. there are other models. The problem with image information is that:
1) is poorly defined. What is a 'shape'? for what is worth?, and
2) has a very high level of 'semantic' content, Everyboy knows what a 'face' or a 'car' is, but we cannot reduce this information to a simple set of shape/textures, there's no direct link between human 'objects' and graphical images, that's why image search by content fails so easily.
Without addressing the first point (mathematical image information definition) there's little hope for image search engines.
If what you need is just image comparison, without textual information processing there are solutions (ie: http://www.immem.com/en/). What do you mean for 'avoid the step of extracting text from them, or later OCRing'? Are you doing text or image comparisons?
To compare million images in a second on a comodity pc was already done since 2004/2005 see http://www.immem.com/en/. By now the state of the art is to compare a video stream against a 24h video pool in realtime, using this technology.
All is good and right, but... Define 'humans' please...
File notification was not on the kernel for historical reasons, not technical ones. File notification was not a priority at the time and so was (and still is in my opinion) poorly designed at the kernel level.
inotify is a step in the right direction (the interface looks almost right), but shares the same fundamental flaw that dnotify have, it's unable to detect changes below the desired directories, and NO, adding thousands of watches (one for subdir) is not an acceptable option, it's inefficient and a resource hog, that's why it should never be hidded inside a library.
The idea is quite simple, you tell the system to notify you when a certain branch of the filesystem is accesed/modified. That's not intrinsiquely difficult or time consuming, is just that the current kernel/filesystem abstraction does not fit well with that behaviour for historical reasons, but that should not be an excuse, threads were also a simple idea with a complex implementation, but it was considered necesary and it was done, file notification is not that different.
Inefficient, the parent poster has a point, it's a shame that linux doesn't have yet an efficient system to notify user programs of changes in file systems. Setting up a watch on every directory on the tree is an ugly and wasteful way to make what it should be a simple and logical thing. Making a library to make it simple is just the kind of coding it should never be done, design flaws should never be hidden.
The stats on my own little site (thousands page hits a day) shows a clear incremnent in Firefox usage on those last 6 months, I am not sure about being an european only trend.
After read the context, all I see is just childist EGO fights
The whole law/moral discussion is pathetic (Law is just coded morality). That's the faiblest point of open source, egotical/inmadure behaviour.
We all want our voting machines to run open source software - but such hardware needs to be locked in the same manner as a Tivo
False, DRM'd open source voting machines are not open al all.
Even worse, there's some 'I don't mind' attitude in most posts, it looks like we have already give up the fight for our mental habilities.
Seriously, let Google index not only that collection, but any stellar image information and launch GoogleSky.
Let's call it BigOldLinus.
Just listening the Islands LP while reading the posts... I feel sorry for those who don't have the chance to listen old good music in the old fashioned way...
A web site allows anonimous upload of a track, and returns a computed tablature for this track. Is chord computing illegal in the USA?
That's simply foolish, please someone set up such a web site to show how ridiculous is to forbid musical notations.
Not only 'girls with longer ring fingers are lesbians', but also his logical counterpart: 'boys with longer index fingers are gays'.
Yes, programming is not easy, and that 'simple' for-every statement could be a real can of worms, but that's programming, trying to 'protect' programmers from mistakes wont help programming as a whole.
The fact is, programmers use to know what sections of his own code could be executed in parallel, but have no easy way to use that knowledge. Let compiler writers start working on implementations (ie. on your example, warn about shared resource (count) being modified concurrently) , is my opinion that there's a big middle ground area where parallel programming could be used, as long as the tools are trivially simple to use.
could be to add a especifically parallel iterator keyword to programming languages, ie:
for-every a in list; do something(a); done;
The compiler then assumes that something(a) can be safely executed in parallel for every element in the list.Is not rocket science, it could lead to parallel spagheti, but is a straightforward method to promote parallel programming.
Sorry,but data is never complete. Mismatches between ancien traditions and current theories about what happened at a certain time frame, use to suffer the 'not modern' syndrome.
Troy (and a lot of other important arqueological sites) was considered a mere myth, due to a miopyc s.XVIII prejudice still present due to the lack of proper philosophical studies in current education.
So Plato was right about a great disaster 9000 years before his epoch.
Software is math. Patents on software are just patenting integer numbers (or sets of integers numbers, if you wish).
So NO, software patents have no sense, no matter the use you or anyone else give to those sets of numbers (encription, compression or whaterever you wish).