Weekly Edition
Return to the Press page
| |||||||||||||
New KDE 4 preview shows progress (Linux.com)
Linux.com reviews the
latest KDE 4 snapshot. "On Friday, the KDE Project released the
third in a series of development previews for the upcoming KDE 4.0
release. Dubbed "Kludge," the 3.80.3 release includes the Sonnet language
library, the new Dolphin file manager, and the Solid hardware
library."
(Log in to post comments)
New KDE 4 preview shows progress (Linux.com) Posted Feb 26, 2007 23:29 UTC (Mon) by ajross (subscriber, #4563) [Link] I really shouldn't ask this, as it's all but certain to start a flame war. But what's the deal with Dolphin? It's a new file manager, and apparently a simpler one, and at least superficially it looks a whole lot like Nautilus. The project web page (and the article linked above) takes great pains to point out that it is not a replacement for Konqueror. But yet, it apparently has indeed replaced Konqueror as the default file manager. So what gives? As an long-time command line guy, I've never been much a fan of Konqueror, honestly. But I've never heard anything but uniform praise from its users. I'm just curious about what the thinking (and politics) behind the decisions to write a replacement file manager and replace Konqueror were. The flames still haven't subsided from the last time the Gnome folks tried to muck with the default file manager...
file managers Posted Feb 26, 2007 23:44 UTC (Mon) by rfunk (subscriber, #4054) [Link] First, I'm a longtime command-line guy too, but I love the power Konqueror gives me. Iuse both. One thing konq gives me that the command line doesn't is iconic previews of files (especially images, but others too), so I can see at a glance what the contents of a set of files are. I also often find the tree view or the information view to be pretty handy, and I'm constantly dragging files from Konq to Gimp or attachments from Kmail to Konq. The ability to add actions to the "service menus" lets me have easy access to commonly-used command lines to operate on selected files. I don't think I'd be very likely to switch from Konq to Dolphin, but for many users Konq's busy UI is just too overwhelming. I can see how providing a simpler UI by default could be a win, as long as the more powerful one is still easy to find and get to (and doesn't wither).
file managers Posted Feb 27, 2007 0:44 UTC (Tue) by drag (subscriber, #31333) [Link] Personally I don't care about advanced GUI file managers.
Most of the features are lost on me and FUSE-based file systems are, IMO, much superior solution then Kio-slaves or Gnome-VFS. (faster, more stable (due to simplier design), able to work with everything were Kio-slaves and Gnome-vfs are kde and gnome specific)
What I like in a GUI file manager is the fact that I can open one up and get a quick visual look over the types of files and such I am dealing with. The icons and pre-views are a great way to quickly determine which files is what, then launch the file with the default application of my choice. That is were the GUI is much better then command line for me.
Something that impliments the *.desktop specification well and is easy to manage.
I almost never use a file manager outside of my home directory...
file managers Posted Feb 27, 2007 0:57 UTC (Tue) by rfunk (subscriber, #4054) [Link] "Most of the features are lost on me and FUSE-based file systems are, IMO, muchsuperior solution then Kio-slaves or Gnome-VFS." Well, I find the sftp kioslave to be extremely useful for what I do, but you can use kioslaves with FUSE (though I haven't tried it yet). http://kde.ground.cz/tiki-index.php?page=KIO+Fuse+Gateway
file managers Posted Feb 27, 2007 1:58 UTC (Tue) by drag (subscriber, #31333) [Link] Yep.
If all I used was KDE or Gnome then I wouldn't have much of a problem with using those desktop-specific items, but I tend to use stuff all over the map.
My current favorite is sshfs. It's purpose is essentially the same thing as your sftp kio-slave (isn't that 'fish://"?)
I wanted to use it to host a lot of files so I tested the stability and speed of the thing vs NFS vs Samba vs iSCSI (OpenIscsi initiator, "iSCSI Enterprise Target" for the target) vs ATA over Ethernet (both a kernel based virtual plane and a userspace one, don't remember much about it)
Keep in mind that I did this some months ago, also it was fairly informal and I just used the defaults given to me by the various debian packages. Software vblade for AoE was uninspiring and I quickly dropped that.
I tested for file transfer speed and stability. So I did my best with very large files, multiple gigs, so that there was no file system cache issues. Then I ran Bonnie++ on all of them to see how well they performed.
Samba was by far the slowest. Simply outclassed.
I think, if I remember correctly, that NFS did do random access much faster then anybody else. The downsides to sshfs is things like not handling ACLs or being able to handle special file types like named pipes, but that's not that important just for desktop file sharing.
Then if your dealing with mostly text files over a slower network (say wireless) then how attractive is the compression option for ssh? (very)
Nowadays Openssh is the only network service that runs on my machines at home. It's all I ever need.
The major gotcha with sshfs is that the stability of the FS is determined by the quality of the ssh server. Of course, recent versions of OpenSSH are superior to all else.
file managers Posted Feb 27, 2007 2:05 UTC (Tue) by drag (subscriber, #31333) [Link] http://fuse.sourceforge.net/wiki/index.php/SshfsFaq
ssh as network filesystem Posted Feb 27, 2007 2:07 UTC (Tue) by rfunk (subscriber, #4054) [Link] Yeah, having learned system/network administration on NFS-heavy networks, I've learnedto avoid it whenever possible, and ssh is a great protocol for that. Thus sftp://. :-) sftp:// and fish:// are different. fish:// uses shell commands, while sftp:// uses sshd's sftp subsystem extension (there's a switch for it in the OpenSSHd config file). sftp is noticably faster, but slightly less well-supported across different ssh servers. I definitely intend to do some more with sshfs soon.
Random access? Posted Feb 27, 2007 7:19 UTC (Tue) by eru (subscriber, #2753) [Link] I think, if I remember correctly, that NFS did do random access much faster then anybody else. The downsides to sshfs is things like not handling ACLs or being able to handle special file types like named pipes, but that's not that important just for desktop file sharing.How can sshfs (and other similar FS'es over a file transfer protocol) do random access at all? The FAQ you linked to in your followup did not answer this. Do they just copy a file back and forth? I guess this works for small files, but is infeasible for very large ones, and those are precisely the ones where random access is most useful. About pipes on desktop, some programs do create them in the user's home directory. Wine is one.
Random access? Posted Feb 27, 2007 10:15 UTC (Tue) by nix (subscriber, #2304) [Link] The SSH_FXP_READ and SSH_FXP_WRITE messages take an offset and length: see the secsh-filexfer* standards.
sftp rides atop ssh, but it is *not* equivalent to stuff you can do by pounding on the shell (unlike scp).
That's why it's a subsystem and not just another client command.
Random access? Posted Feb 27, 2007 20:26 UTC (Tue) by drag (subscriber, #31333) [Link] I wouldn't considure Sshfs as a replacement for NFS or SMB (it would probably fall appart for large numbers of users) and I wouldn't use it for a home directory, but I think it makes a very convienent and clever way file transfers for personal use.
New KDE 4 preview shows progress (Linux.com) Posted Feb 27, 2007 2:09 UTC (Tue) by proski (subscriber, #104) [Link] I think if you are already satisfied with some setup, you should just continue using it, and please stop worrying whether it's default or not. Dumbing down the defaults is aimed at attracting even bigger idiots than we are :)
New KDE 4 preview shows progress (Linux.com) Posted Feb 27, 2007 5:22 UTC (Tue) by aseigo (guest, #18394) [Link] > (and politics)
none. it was a purely technical decision that met with zero internal guff
|
|||||||||||||