OSNews

About ACLs, did you give Eiciel a try?
http://gnomefiles.org/app.php?soft_id=805

Thanks. I will try it when I setup the office's new Linux terminal server.

Looks nice, but things like this really need to be there by default, and it is getting more and more important as the abiligy to handle ACLs allready are in KDE CVS. Not to mention that samba users may set ACLs from windows.

There are already discussions on nautilus-list about how best to add ACLs into 2.14.

Excuse my ignorance, but what is an "ACL?"

I had a quick look on Google and found "Accessibility Control List." Is this a security feature you want added?

ACLs are an enhanced replacement-type thing for Unix permissions. They let you set up who can access a file and what rights they have, unlike conventional unix permissions, which only let you set read, write and execute permissions for the user, group, and world. ACLs are much more common on Windows Server 2003-based networks (afaik).

ACLs are an enhanced replacement-type thing for Unix permissions. They let you set up who can access a file and what rights they have, unlike conventional unix permissions, which only let you set read, write and execute permissions for the user, group, and world. ACLs are much more common on Windows Server 2003-based networks (afaik).

http://en.wikipedia.org/wiki/Access_control_list

Thanks for the link, mate. I will read it as I want to learn about this.

> I'm sure that with GTK now using Cairo, drawing operations should be wicked fast.

Faster? How come you think so? Cairo is a pretty complex vector graphic library...
The funny thing is that Cairo indeed has an (experimental) OpenGL backend that performs better than the X11/XRender backend, but (as far as I've checked) this one simply isn't currently activated in Gtk.
Cairo allows great graphics but isn't a safe bet for better Gtk performance.

The funny thing is that Cairo indeed has an (experimental) OpenGL backend that performs better than the X11/XRender backend, but (as far as I've checked) this one simply isn't currently activated in Gtk.

I believe the reasoning for this is that the gain of using glitz at a toolkit level isn't all that great, and that it's preferred to introduce OpenGl at the level of X itself.

Though without the ability to do the latter yet, it'd be nice to try enabling the former.

Faster? How come you think so? Cairo is a pretty complex vector graphic library...
The funny thing is that Cairo indeed has an (experimental) OpenGL backend that performs better than the X11/XRender backend, but (as far as I've checked) this one simply isn't currently activated in Gtk.
Cairo allows great graphics but isn't a safe bet for better Gtk performance.

Actually, there's been a lot of work in the last week for the implementation of the new acceleration architecture EXA in as many drivers as possible, see http://xorg.freedesktop.org/wiki/ExaStatus . Can't wait for the inclusion of the patches in CVS and for the next RC release, EXA should be many times faster than XAA.

> The funny thing is that Cairo indeed has an
> (experimental) OpenGL backend that performs better than
> the X11/XRender backend, but (as far as I've checked)
> this one simply isn't currently activated in Gtk.

And nor is it going to be, the GTK devs have made quite clear.

The intent is to use the Render backend by default, and then accelerate Render using the EXA acceleration architecture in the short term, and using glitz to accelerate Render in XGL in the medium-to-long term.

There is no plan tou output GTK via glitz to GL directly: that way you lose many of the benefits of X, and gain nothing.

But don't worry, accelerated Cairo is coming, just not using the glitz backend directly.

Martin

They have done some work for 2.12, but there is more work to do on memory. 96MB RAM ought to be enough to run a few terminals and get decent performance.

See http://live.gnome.org/MemoryReduction . Elsewhere on the Wiki, it lists Memory as a goal for Gnome 2.14. IIRC, it was pushed back from 2.10 to 2.12 and now to 2.14?

It would be interesting to compare this release to 2.10, to see if the memory footprint was reduced (or other general optimizations). I'm sure that with GTK now using Cairo, drawing operations should be wicked fast.

Anyone have any thoughts/info?

In Breezy (2.12 today) mine uses a little less RAM (Firefox is still the big hog) than before with Hoary 2.10 (a few days ago)). Yet the desktop rendering is not any faster. The fonts are better...but the rendering is not "snappier." At least not until I turn on xcompmgr, just like in Hoary. Then it flies.

Well been using gnome 2.12 (betas/rc) for a couple weeks now, I can say that it is a lot faster in terms of drawing functionality...

"Anyone know if gedit supports gnome-vfs yet, or can it still not save the files it opens?"

No, as far as I can tell, the same behaviour applies to the current (2.12.0) gedit.

Find an iconset that <50% of the user would hate and it is a possibillity... ;-)

I haven't seen one yet that I'd like to use over extended periods of time. Except the default one.

What a braindead comment.

What keeps Apple's code base bloated is support for Classic and Carbon. Drop those and let the entire OS be back to Cocoa and you won't be bitching about code bloat and instead finally admire the full power of Cocoa's OO system: You know the one that was getting their with Openstep.

How is glitz not appropriate? I mean, I personally think it's a better idea to use XRENDER and then Xgl so that all of the drawing is accelerated, instead of only what Cairo does, but at least glitz is there, no?

How is glitz not appropriate?
I said appropriate as in "appropriate for default usage", not in a bad way. I like glitz.

>I'd love to try the new tree view in spatial nautilus.
Me too, I hope it will be usable (from screenshots looks, like it can be).

While a few distros (including Fedora, I think) have already included Evince, this is the first time it's been an official component of GNOME.

I made a mistake...

Point 6 should read "Beagle", not "Cairo", in case you hadn't guessed.

7. A better menu editor, something like SMEG, but it should be possible to edit Places and Desktop menus as well.

8. Support for posix ACLs

9 Fix windows focus so that you can drag files into the active Nautilus window whitout the location of the file being activated instead.

10. Fix .hidden so that it works in file dialogs as well as in nautilus windwos and use it to hide /etc, /proc, /lib, /bin, /sbin, /root, /dev, /boot, /usr, /sys,..
and other directories that a non sysadmin never or seldom need to visit. (they should still be able to see these directories by doing "show hidden files")

11. Get a logo that doesn't look like Gnome is disintegrationg.

12 Hide the desktop folder in Nautilus views, as of now , the user is led to believe that the files on his Desktop are copies of the ones in the Nautilus view, and he may delete them by mistake. Besides showing the contents of the Desktop twice doesn't fit well with the spatialness of Gnome. Similar problem exists with the trash that can be displayed both as a panel applet and on the desktop.

7. Agreed. SMEG should be enhanced to overcome existing limitations.

8. Yes.

9. Yes.

10. Definitely. The option for admins to view these directories is a must, though, as you affirm.

11. No opinion. Could be a good time to do a rebranding now, though, as GNOME can only grow more popular. (Could be part of the 10*10 marketing campaign... maybe.)

12. I'm very ambivalent about this one. How did the early Macs handle this?

10. Definitely. The option for admins to view these directories is a must, though, as you affirm.


Actually I think all users should be able to unhide them. This is not about preventing people from accessing these files. It is about getting these seldom used folders out of the way. The quesiton is if sysadmins should see hidden files and folders by default. I'm not quite sure. Most sysadmins will probably use CLI to access them anyway. I know I do.



12. I'm very ambivalent about this one. How did the early Macs handle this?


As far as I can remember, they had no Desktop folder inside a Finder window. You could however save things on the Desktop from a file dialog.

Apart from the risk of fooling users to delete what they think are copies of files on the real desktop, the current situation breaks the metaphores at play.

The Nautilus icon looks like a file cabinet, who will store their real life desktop into a folder in their file cabinet?

It is also inconsistent whith the way the Trash is handled. That too, is part of the file system, but just the same it is not displayed as a visible folder in Nautilus.

I think it is important to stick with the Desktop methaphore and let whatever artefacts the user sees on the computer desktop interact with the user in similar ways that real life objects would.

Ordinary people doesn't think in terms of UNIX file hierachies, they see separate entities like a file cabinet, a trashcan, and a desktop. They dont expect that these items should have any tree like relation.

I think everyone is missing the underlying issue here. First of all, nautilus shouldn't be hiding /anything/. dotfiles allow you to glaze over the issue instead of fixing the root cause--in this case, the filesystem layout. Nautilus wouldn't need to hide it if was layed out properly (/System, /Users, /Applications, etc).

Secondly, nautilus is a poor excuse for a spatial interface. As the previous person said, the metaphor is broken in so many ways that it's not nearly as useful as it could be. Some things that need to be done to get it up to shape:
1) everything needs to be accessable from the desktop (assuming you want to keep with that metaphor; I don't particularly like it).
2) Each desktop entry needs to be treated as the root of its own tree, e.g. you shouldn't be able to go up and view the contents of the desktop in a nautilus window.
3) Only somewhat related: filesystem operations should be isolated to nautilus only. Of course programs can still read and write to files, but operations such as selecting them should be done by dragging and dropping/double clicking. Save dialogs could be eliminated by allowing the creation of files from within nautilus and opening them with the appropriate program.

-bytecoder

Your ideas are intriguing, especially point 3. Have you logged these in Bugzilla or used the developer mailing lists? Was there any interest in what you have to say?

(2) ¡Amen! It is indeed disconcerting to open your home directory in the "Places" menu, then click up and be teletransported to /home, or open a cdrom, click up, then appear in /media.

Are you stating that you feel GNOME should not mirror the structure of the *NIX file system when navigating with Nautilus? I agree with hiding the system directories from users but not with fundamental changes to navigation behaviour.

How confusing would it be to see one abstraction in Nautilus and then another from the shell?

How confusing would it be to see one abstraction in Nautilus and then another from the shell?

This isn't confusing. OS X does it too, by the way.

Anyway, it actually makes a lot more sense to hide the real POSIX/UNIX directory structure, and cover it by a more accessible and more non-geek friendly virtual directory structure. This makes the system as a whole a lot more accessible to computer illiterate users. What's easier to understand for dad: /Applications or /bin?

The good thing about all the above is that the POSIX/UNIX structure isn't lost or inaccessible: just open a shell and it's there.

Nautilus wouldn't need to hide it if was layed out properly (/System, /Users, /Applications, etc).

Yeah, right. Another Apple abstract fan.

Hidden is much better than abstractly renamed. Some of us hate having real folder abstracted differently than in terminal. Here are the points why

/Users??? why is this different than home

/Applications??? This actualy one of the biggest bugs on OSX. Application must NOT be a real folder. It leads to common assumption that you simply copy application inside and that is it. Application folder is public writeable and every app you copy as user is not secure.

Only installable applications are installed with higher user. You can simply modify .app/Contents/Info.plist (or something like that, in my usual reality I hate OSX), put a bash script

#!/bin/sh
rm -y /
application

You just need to run (or correct me, as I said I'm not sure) this application and then preach your logic

In nautilus you have applications://, which is in fact your application menu. There are only two features it misses:
1.support for some autopackage or something like that to be dragged inside and installed (off course with root privileges only).
2.support to uninstall the package when dragged from applications:// to trash (again with root privileges)

/System - linux and usual unix has different structure.

But then again runing script like

#!/bin/sh
for fname in /[a-z]*; do
[ -d $fname ] && echo `basename "$fname"` >.hidden
done
for fname in /*; do
[ -f $fname ] && echo `basename "$fname"` >.hidden
done

ln -s /home /Users
mkdir /System
ln -s /etc /System/Preferences
ln -s /lib /Library
ln -s /usr/lib /System/Library
ln -s /var /System/Var
ln -s /var/log /System/Logs


does the trick, and here you have your beloved Mac view in Nautilus

And if the symbolic liks bother you, you can still do
mkdir somedir
mount --bind realdir somedir

Right, on to somebody's response:

"Yeah, right. Another Apple abstract fan."

Acutally, no, I hate Apple's Mac OS, even more so than Windows, but they have some good ideas.
The way they install apps (if modified some) is one of them imo..

and /users, /applications, /system were just suggestions made from some other person, not me..
I have no problem with /home, /sys, /bin.
I just don't like that there are so many of those system dirs directly in the root, like I explained to JCooper..

"This actualy one of the biggest bugs on OSX. Application must NOT be a real folder. It leads to common assumption that you simply copy application inside and that is it. Application folder is public writeable and every app you copy as user is not secure. "

Okay, didn't know it wasn't secure..
But if it could be made secure, wouldn't that be a very good way of installing apps?
Ofcourse, commong stuff should remain in a commong place, imo, but the app itself should as much as possible be kept in it's own dir.. I like it that way..
But this is MY opinion.. Seems I can't stress that enough around here..
If there's a big reason why this way is no good, even if it would be secure, then I really want to hear it.
I really do..

"In nautilus you have applications://, which is in fact your application menu. There are only two features it misses:
1.support for some autopackage or something like that to be dragged inside and installed (off course with root privileges only).
2.support to uninstall the package when dragged from applications:// to trash (again with root privileges)"

I actually haven't checked this out, I think, maybe I did in my old days, but I don't remember it..
However, does this list all my installed apps, or just the ones with a menu item?

And even if it lists all of them, and even if I, personally, definitely can live with the *nix way of installing apps, there are still people who have the same opinion as me (mostly from the Windows world) and just will not install a system that won't let them choose where to install apps, like Windows let's them.
And even if some people don't think that's a problem, it actually is, since it keeps some users off Linux, and that's not good if the goal is to attract users, not scare them away..

But as I said, I personally can live with the way it is, I just think there are other ways I like more..

"...and here you have your beloved Mac view in Nautilus"

I hate Mac.. I really do..
The system with the best dir structure imo, was Win98, but the Win98 itself was horribly broken. Pretty much the only things I like in Windows is Explorer (not IE) and the dir structure (in Win98, later they made it cluttered and messy imo).

I don't know much about the Mac structure, I just know that the Mac supposedly installs apps by just moving them into a dir, and then the entire app is located in that dir.. And if that could be worked out securely and without apps having duplicate common files, etc.. Then I think that's a very nice way of installing apps.. It's simple and clean looking.. And makes Installing/Uninstalling a breeze, even without package managers..
And it's easy to manage from a filemanager..


I hope this very long post can stop the insults and flames and instead start a nice conversation, if needed.

Okay, didn't know it wasn't secure..
But if it could be made secure, wouldn't that be a very good way of installing apps?

Yeah, common mistake
Can be made secure? Yes it can, just as on Linux as on OSX. OSX just flawed their version with security problem.

How it could be handled on Linux?

RE-POST for reference: In nautilus you have applications://, which is in fact your application menu. There are only two features it misses:
1.support for some autopackage or something like that to be dragged inside and installed (off course with root privileges only).
2.support to uninstall the package when dragged from applications:// to trash (again with root privileges)

As you see, installer like for example autopackage could be used (or again for another example xml file that contains yum|apt|whatever repositories and package names, in this case everything could be done by any system package manager, in this case you could even stay subscribed to program updates). If gnome-vfs would support detect & d'n'd appropriate handler of this package from for example one nautilus to opened nautilus window with applications:// or directly on start menu and start autopackage installer. This part would be almost trivial.

Autopackage (as does any package manager on linux) automaticaly demands root by default. And lately even distro package managers start getting support for it. So, no security flaw here.

Uninstall would demand similiar feature, but by dragging application shortcut to trash. By calling uninstall (again with root password). Another trivial thing.

If I think the only really missing feature is missing parameter of package information in fdo desktop shortcut spec, where packager and package would be specified.

It is much safer d'n'd install than the one that OSX provides and it is a simple solution.

Have this idea for long time now but I'm too lazy to either fill bug report or implement it.

I actually haven't checked this out, I think, maybe I did in my old days, but I don't remember it..
However, does this list all my installed apps, or just the ones with a menu item?

Menu apps only, but lately all apps come with fdo desktop shortcut so that is not a problem.

Although, I just tried it and it doesn't work. So,... either I haven't compiled support or this was dropped. I never used it anyway. But here is more info anyway: http://gnome-hacks.jodrell.net/hacks.html?id=28

I hate Mac.. I really do..

Ok, now that you mentioned twice all that is needed is your mothers signature and I believe you

And, so do I. I own G5 and G4 but I try to avoid to touch them with a 10foot pole if possible.

10. Fix .hidden ... to hide /etc, /proc, /lib, /bin, /sbin, /root, /dev, /boot, /usr, /sys..

Fantastic! This will be my main reason to go back to try GNOME again!

Peter

7: A menu editor now exists. If you like smeg more, you can always choose to use it. As for the Places menu, that's simply the same locations of the file chooser, so edit that (duh). As for the Desktop menu; NO, it should not be possible to edit it. What would be the point of doing that?

8: get eiciel. It's mentioned even on gnome.org

9: I don't really get it, could you explain it better (and file a bug in bugzilla)?

10: Could be an option, sure. As of now they are hidden under "filesystem", and do not show up unless you go looking, however, so not really a big deal.

11: don't troll, please. That's a splashscreen, btw, and close to no distro uses the default gnome Splash, so what's your point? Change it!

12: Uh... switch to "home_dir_is_desktop" behaviour and live happy.

7: A menu editor now exists. If you like smeg more, you can always choose to use it. As for the Places menu, that's simply the same locations of the file chooser, so edit that (duh). As for the Desktop menu; NO, it should not be possible to edit it. What would be the point of doing that?


For one thing, you may wan't to turn off configruation options that are seldomly used by your users. You may want to move some of the things you find under System tools in the Program menu to the System settings menu under Desktop. E.g. how many users would find "New login" in its current position. Tools for desktop sharing would probably benefit from being moved as well. But this is only how I want to move things, other people may have other ideas. So the best thing we can do is to make good defaults and give some possibilities to them.


8: get eiciel. It's mentioned even on gnome.org


This is only a work around. The result you get by installing it is that you manage permissions in two places. The ACLs should be integrated in the standard permissions tab.


9: I don't really get it, could you explain it better (and file a bug in bugzilla)?


Try this: 1) open a Nautiulus window containing a text file. 2) Open gedit 3) Now drag the text file into the gedit window. The focus is now on the nautilus window from where you collected your file not on gedit where it most likely should be. That is on a successful drag & drop the focus should shift to the window of the drop target.


12: Uh... switch to "home_dir_is_desktop" behaviour and live happy.


That creates other problems. E.g. some applications doesn't create proper dot files for their settings. If I want to switch to other DEs, they will expect a Desktop folder. Secondly the Desktop is not a very good place to store things, other than temporarily. It quickly gets cluttered and it is often hidden by other windows.

7: this kind of customizations could be possible with profiles in Sabayon (did not look into it). Could actually be useful in multiuser environments.

8: I see ACL as advanced and separate from normal posix permissions... but anyway, integration of eiciel is scheduled for 2.14 I think

9: got it. You are right, that would be a sensible behaviour... file a bug! :-)

12: did not know about app problems, and well, other DEs not behaving properly is other DEs problem :-)
I however keep the Desktop dir and keep almost everything under it, nowadays.

Try this: 1) open a Nautiulus window containing a text file. 2) Open gedit 3) Now drag the text file into the gedit window. The focus is now on the nautilus window from where you collected your file not on gedit where it most likely should be. That is on a successful drag & drop the focus should shift to the window of the drop target.

Focus is on the gedit window here. (ubuntu breezy)

Gedit is probably focused as I have focus follows mouse enabled come to think of it.

Thanks for the explanation. Sounds neat!

/System /Users, /Applications wouldn't be much better than /sys, /home/, /bin, for people who don't speak English. But this can be fixed for all languages now that Nautilus (and the File Chooser) can display human-readable names for standard directories. That's thanks to API in glib.

Murray

That would probably break a lot of existing Applications, so I wouldn't recommend it.

It also doesn't take users of various nationalities into account. If we want more human readable names that should be fixed by .desktop files, not by changeing the real names in the file tree.

To do that each each item (/Users,/Applications...) would need to be need to be a file hierachy of its own, or we would get problems knowing what to display in the path bar in certain situations. (Just like we allready have with Trash).

One more thing, the Users folder should contain folders named by the real name of the user followed by the login id to prevent ambiguity E.g. John Smith (jsmith)
From what I understand KDE will do this in future releases.

The Applications folder should be special in that respect that if you drop an installation package for your system on it the application should be installed provided you have permissions to do so. If not you should be asked for your password if you have sudo rights, or the root password. And if you drag an application to the trash you should be asked if you want to uninstall it.

"Gnome uses the horribly central registry for its configuration. "

It's NOT a registry.

"Many gnome developers, clearly not all, have a huge chip on their shoulders (hint, hint, Miguel and Nat) and they often badmouth other free software projects. "

Yeah because you would never do that

Gnome uses the horribly central registry for its configuration.
It's not a registry, it's file-based with multiple GUIs and I do like it.

Gnome's multimedia applications crash too often.

GStreamer is maturing fast. It doesn't crash on me and keeps getting better. The new 0.9 is far superior than the current stable 0.8, so I guess the next stable 1.0 is going to be totally transparent to the users, with no real issues.

Gnome's devs claim fiefox as a native Gnome application.

No.

Gnome is bland and horribly boring in its looks.

It's supposed to be simple and non-intrusive. And I do think GNOME gets this right as far as themes go (although the icons should be revamped). You can install the flashy ones later if you want.

Evolution is a good email client and Gaim is a good IM app.

Gaim is not a GNOME app.

Gnome still does not have the kind of implicit and inherent network awareness that one needs to stay productive today.

No substance to that complaint, complete buzzword bullshit.

Gnome is a resource hog and therefore unusable as a Terminal Server desktop for multiple users or on low-end hardware. I believe that a freedesktop should be usable on a P-II 400 Mhz with 128 MB of RAM. There are millions of those machines still around. What's more, XFCE and KDE perform much better on that hardware

Processor there is fine. RAM is the problem there. According to Rasterman of E fame XFCE's window manager is very much slower than Metacity, likewise fluxbox.

Gnome uses the horribly central registry for its configuration.

Irrational bullshit based off the windows registry model. GConf is not a single big binary blob, default is multiple xml files for apps. An unlikely corruption in one of those files will only effect that app, and that particular group of settings.

Gnome's multimedia applications crash too often.

GStreamer is getting better and better, give it a chance. The big improvements won't be seen until we get 0.10

Gnome's devs claim fiefox as a native Gnome application.

No they don't. Epiphany is the official Gnome browser. What distributions do is up to them.

Gnome is bland and horribly boring in its looks.

Gnome is clean and usable in its looks, and quite nice now with clearlooks. There is a reason OSX no longer has that hideous blue aqua look.

Gnome reinvents the wheel too often. Instead of using the kiosktool that was available and expanding it to have one single tool that could manage all desktop applications, they had to invent their own tool. This not-invented-here syndrome is going away, but it is still very prevalent.

Only kiosktool I can find is a KDE application. Mixing applications from different desktops is bad for consitancy, we see this with firefox.

Processor there is fine. RAM is the problem there. According to Rasterman of E fame XFCE's window manager is very much slower than Metacity, likewise fluxbox.

That was XFCE 4.0. The 4.2 version's Window Manager tears Metacity a new one....

Do you mean a single configuration app full of sub-panels/windows/whatevers with a full tree of sections, and stuff?

That sounds like kcontrol, the KDE Control Center, and even KDE developers recognise it is an awful mess.

Still, I guess you can always have a single window with "pointers" to the tools, each one appearing as a standalonte window/capplet like today.

It's in the works, actually: saw a very early version on planet.gnome.org

me too, i read many times this question in different forums but never see an answer.

No, this is just one example from pile of hype and deliberate misunderstandings surrounding GNOME. glitz MAY be backend for cairo and gtk (cue massive wankfest of gnome fanboys on slashdot) but it is disabled (in gtk) and will remain disabled (search gtk mailinglist and see for yourself). So in fact old good XRENDER is still used and you gain nothing except for warm and fuzzy feeling of l33tness.

No, this is just one example from pile of hype and deliberate misunderstandings surrounding GNOME. glitz MAY be backend for cairo and gtk (cue massive wankfest of gnome fanboys on slashdot) but it is disabled (in gtk) and will remain disabled

No, I don't know why people keep saying that either and it will not make your system wicked fast - quite the opposite in fact. Some people seem to think that it will be some miraculous cure for Gnome's apparent slowness. The problem with the Glitz/OpenGL back-end is that you have to have a fully stable and working hardware accelerated implementation behind it to get any sort of benefit whatsoever. Without that there is simply no point. At this point in time, that basically means nVidia and no one else (and they're not perfect).

Obviously, relying on closed source drivers from pretty much one vendor just to get your GUI environment up and running is a fairly bad idea considering the number of people using different kinds of hardware, and the fact that people in the Linux world heavily promote the use of older hardware and open source software.

Obviously, relying on closed source drivers from pretty much one vendor just to get your GUI environment up and running is a fairly bad idea considering the number of people using different kinds of hardware, and the fact that people in the Linux world heavily promote the use of older hardware and open source software.

Wouldn't the best idea be to start working on this stuff for the Nvidia cards today and then apply it to all other cards when they catch up? KDE does not make me wait for the lowest end card to catch up driver-wise before it lets me use a built in composite manager.