Thread: Soc Gdt
View Single Post
Old 10-30-2011, 10:07 PM
HelpDeskHustler's Avatar
HelpDeskHustler HelpDeskHustler is offline
Join Date: Mar 2007
Posts: 2,699
Default Re: Soc Gdt

Haha, you just mistook me for Marv.

From a security standpoint, Chrome/ium is better. I has less memory leaks, it uses less memory and has less vulnerabilities. I can't use it everyday though because all it has is Incognito/Save until deleted for history,cookies,cache. For me, I can't take the All-or-nothing route unless it's a public PC. I enjoy cookies and cache (aside from in a KDE environment, where your passwords are all saved easily) but I can't stand history. There's no reason to keep history beyond a session, and Chrome won't let me JUST turn that off without Incognito. In addition to this, firebug is orders of magnitude better than chrome's web developer kit. My beef with firefox in Mint is that the Repo copy has binary modifications that disallow settings and IMO cripple google to be this 2005-looking google with some stupid mint theme.

I'm looking forward to gaming on Linux for the very reason of working utilities. I can't wait until the drivers start working the way they should (nVidia open source ones are rapidly on their way -- I'd give it no more than 2 years at this rate). I don't have much of a beef with steam as it's the best DRM/download manager in existence right now -- and does well as a centralized platform. But if games make it to linux, expect a big boom to be integrating them with Linux package management systems and implementing the DRM via key signing on the repo. Steam exists because Windows doesn't have good support for 3rd party, trusted repositories. I could see common-channel XMPP/IRC mixed with this completely obsoleting steam aside from the unified store.

As far as Gentoo goes, I'm interested in their package management (emerge/portage) and it's ebuild system. They use Python and are by far one of the most intuitive source-building methods in existence. I'd like to remix this with YUM, rysnc, and Mercurial and borrow some ideas from Pacman (Arch Linux) to make a good binary/source package manager for RPM. I probably won't even take anything from Apt -- it has terrible console output and really isn't much different from YUM. Apt isn't "UNIX-y" enough IMO. One thing fedora does need is a GUI program that caches the freaking repositories. It feels like every time I open the GUI package manager it takes ages, when that's the GUI's fault, not YUM or RPM's.

As far as file grouping goes -- think of it like G+ (which ironically is based on UNIX user groups). A file can be part of many groups too, but you don't get a lot of functionality out of that. The functionality comes from sort groups, similar to how friends and circles work in G+. The best example I can think of is taking a table -- perhaps something like an iTunes library of songs and applying a graph transform to those files. You enter a directory and you might find groups like "by genre" or "by artist". No iTunes display is necessary because you can just look in a folder for the music. iTunes does this behind the scenes with a relational database, but filesystems can often be much faster for real files -- removing this feature from the program and implementing it seperately allows for cross-program support and better performance patching. Essentially the grouping program will take a directory A, apply group transforms to its contents into a new directory B, then manage the filesystem links to those files based on the groups that the files are in.
Reply With Quote