|
|
Post by rustleg on Apr 26, 2012 5:20:10 GMT -5
One thing I noticed, it may have happened with a previous version of KNOS, not sure if I mentioned it before (and you may already have responded, I have a vague recollection of something like this - apologies if so).
When I modify a file, say I click on a text file to fire up the editor, make changes and save, Nautilus doesn't immediately update the file time. If I hit F5 it then does. Again just a nitpick, but I thought worth you knowing.
|
|
|
|
Post by Kevin McAleavey on Apr 27, 2012 3:15:51 GMT -5
One thing I noticed, it may have happened with a previous version of KNOS, not sure if I mentioned it before (and you may already have responded, I have a vague recollection of something like this - apologies if so). When I modify a file, say I click on a text file to fire up the editor, make changes and save, Nautilus doesn't immediately update the file time. If I hit F5 it then does. Again just a nitpick, but I thought worth you knowing. This one's a LONG-standing bug in Gnome. It affects Linux as well although not as severely because Linux decided on a solution that's very insecure to work around it. Unfortunately, BSD will not allow that because it represents a MAJOR security hole. What happens simply is that there is a limit on how many files can be parsed by Nautilus. Up until that limit is hit, a new file will indeed get notified and the window will be refreshed. However, once there are more files parsed than that limit, then it will no longer refresh and that's just the way Gnome's Nautilus works. For the really geeky who might read through here, here's the problem. Linux has a kernel notification of file changes called "inotify" ... it passes information between userland apps like Nautilus and the kernel API. As designed, it can pass a whole lot more than a call to refresh a screen, it can actually pass commands in its structure. Inotify therefore, since it's capable of two-way communication is dangerous if someone were to use it as a conduit to modify system data back into the kernel since it would have root permissions. The folks who designed BSD's complimentary "dnotify" function refused to provide that level of communication between API layers and so in BSD, Nautilus can't use it because while Dnotify passes data only in a single direction (out) it's also dumb as a box of bowling balls. Nautilus would not be told WHAT changed or where and Gnome's code doesn't have the ability to go look for whatever changed. Linux has a notifier library called "FAM" whereas BSD has "GAMIN" (which Linux also supports) but because the kernel refuses to allow a portal to userland in BSD for security, about all that GAMIN can do is watch file descriptors rather than communicating with the kernel. As a result, GAMIN is forced to open (and STORE because we don't support Linux file descriptors - yet another security hole) its own internal list of file descriptors on each and every file in a directory and hold open that file "handle" to watch for changes since what's seen on the userland side is secured from the kernel. However, there's a limit on how many file descriptors can be open at one time and GAMIN kisses the sidewalk after it's seen about 20,000 file descriptors (easy to achieve these days). File descriptors also eat memory and so if we were to somehow make that number larger, KNOS would run out of memory faster as well and so we stick with that limit of 20,000 in our design. But things get even worse with GAMIN. GAMIN "polls" all files when you go to open any directory and it has to open every file inside that directory to count the file descriptors and filenames. In doing so, it prevents the display of files in a window until it's finished doing so. This is the reason for the delay between opening a directory and the file icons actually showing up in the window. And it gets even worse - open file handles prevent unmounts, so that's yet another factor. Mounts of external devices have to be "polled" rather than physically opened and sometimes the "polling" misses a change. So we've got quite the balancing act going on here as well since again, we have to check security and then thumbnail the icons in GAMIN before allowing Nautilus to actually show the files. So it's definitely a bloody mess.  *IF* there were a secure means to allow a kernel notify without a potential backdoor into the kernel, then we'd go with a kernel notification like OSX went and did ... but that's dangerous as Apple users are finding out when their Java opens a kernel notification path to bypass security and we'll have none of that here. So bottom line, Nautilus will run out of file descriptors since it will parse every directory and subdirectory it sees in attempting to establish a "change notify" securely using GAMIN. I'm holding off release for a few more days and trying to see if we can increase that amount without impacting available memory or opening a security hole by having GAMIN *not* monitor certain directories that won't change anyway so we might be able to mitigate this a bit more than we did originally. Stay tuned! But Ctrl+R or F5 will refresh manually if a signal no longer comes in from GAMIN ... |
|
|
|
Post by rustleg on Apr 28, 2012 0:51:09 GMT -5
... I'm holding off release for a few more days and trying to see if we can increase that amount without impacting available memory or opening a security hole by having GAMIN *not* monitor certain directories that won't change anyway so we might be able to mitigate this a bit more than we did originally. Stay tuned! But Ctrl+R or F5 will refresh manually if a signal no longer comes in from GAMIN ... If it's a question of squeezing memory allocation elsewhere I wouldn't have thought this was warranted since it doesn't really impact the utility of any aspect of the system. I reported it only because I thought it might indicate a bug somewhere. Incidentally I was playing with the new Ubuntu 12.04 yesterday (it may replace my Mint11) and at some point the same thing happened there. |
|
|
|
Post by Kevin McAleavey on Apr 28, 2012 3:02:15 GMT -5
If it's a question of squeezing memory allocation elsewhere I wouldn't have thought this was warranted since it doesn't really impact the utility of any aspect of the system. I reported it only because I thought it might indicate a bug somewhere. Incidentally I was playing with the new Ubuntu 12.04 yesterday (it may replace my Mint11) and at some point the same thing happened there. Interesting ... A large number of folks I hang out with are highly disappointed with Ubuntu strangely enough and they're flocking to Mint ... go figure! As for the long term Gnome bug we're talking about, numerous folks have been going crazy trying to figure out the source of it and here at the KNOS Project at least, we're obsessed with even the smallest details if there's any way to solve it. We've had to clean up literally thousands of long-standing bugs in code migrated from Linux to BSD world such as Gnome and it'd still be nice if we can find a solution here as well. Just the way we do things here. We don't consider "live with it" as an acceptable solution and I haven't quite given up on this yet. There are a few other extremely minor details we're finishing up so I'm going to leave this one on the table on our end as a "try to resolve this" until everything else is nailed down. Hopefully we can nail this one too! Forgive me my obsessions there. We want to get this as absolutely proper as we possibly can given that KNOS is intended to be a relaxing and reliable experience for ordinary nontechnical people. This little thing could annoy folks and so it's significant in my book, we don't want to be like Linux. (grin) |
|
|
|
Post by rustleg on Apr 28, 2012 7:54:23 GMT -5
... A large number of folks I hang out with are highly disappointed with Ubuntu strangely enough and they're flocking to Mint ... go figure! Funnily enough I was in that camp but after looking briefly at Ubuntu 12.04 if I can get familiar with the interface, which is quite different from all others I've tried (and obviously steering towards tablets), I was initially impressed and might switch to Ubuntu. However this is off-topic, so say no more. I'm currently using KNOS only for internet banking and will have extended testing to do to make it a mainstream system for me, which could give rise to more items on the wish list, but of course this will be post KNOS9 release. However I'm very interested if it can replace my main system, although I'd probably still boot a separate image for banking. So since you're keen to make it good for ordinary folks (I think I'm a bit more technical than most but miles behind you guys and not wishing to delve into the nuts and bolts anyway) our interests would seem to converge so I'll try to do more work on this in the months ahead. |
|
|
|
Post by Kevin McAleavey on Apr 29, 2012 2:17:13 GMT -5
Making KNOS as absolutely useful as possible is what we're all about, mate! Once again, I thank you IMMENSELY for the efforts here! |
|
