From mboxrd@z Thu Jan 1 00:00:00 1970 X-Received: by 10.182.191.65 with SMTP id gw1mr25087902obc.40.1423010289718; Tue, 03 Feb 2015 16:38:09 -0800 (PST) X-BeenThere: voidlinux@googlegroups.com Received: by 10.50.66.227 with SMTP id i3ls1699913igt.38.canary; Tue, 03 Feb 2015 16:38:09 -0800 (PST) X-Received: by 10.51.15.133 with SMTP id fo5mr307185igd.3.1423010289485; Tue, 03 Feb 2015 16:38:09 -0800 (PST) Date: Tue, 3 Feb 2015 16:38:08 -0800 (PST) From: Antonio Malcolm To: voidlinux@googlegroups.com Message-Id: In-Reply-To: <9386866b-d729-4587-bd55-ab639a2da6ed@googlegroups.com> References: <9386866b-d729-4587-bd55-ab639a2da6ed@googlegroups.com> Subject: Re: Decent Starting Point For Rolling A Desktop Environment? MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_4012_932072130.1423010288043" ------=_Part_4012_932072130.1423010288043 Content-Type: multipart/alternative; boundary="----=_Part_4013_1590567692.1423010288043" ------=_Part_4013_1590567692.1423010288043 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit That's odd- I've always experienced the opposite, ie: the proprietary Nvidia driver has typically worked for me, and the open source Nouveau driver has typically given me issues. Also, I've always needed to do some finagling to get ATI drivers to work, but that's likely because I've typically installed my Linux rollouts on Apple laptops, and dealing with their combination of GMUX hardware/GPU hardware configuration and non-standard UEFI implemenation is a pain in the arse, and has required rolling a kernel (of course, it didn't help that I was running Debian, which uses an older kernel), and telling it where to find the Radeon BIOS. Add to that, on my 2011 MBP, vgaswitcheroo works, but something in the way MBP-specific GPU switching in the kernel extensions is written (and the code, written by some guys at Red Hat, looks like it was written a decade ago) causes the Radeon to crap out during subsequent power-cycling (works the first time, not on additional tries), so I ended up writing my own user-space utility for handling that. >From what I understand, the proprietary Nvidia drivers are better, especially performance-wise, than the proprietary ATI drivers, and, from dealing with both, I feel like Nvidia provide much more love to the Linux community than ATI. This may be partly because a lot of high-end animation and rendering workstations use Nvidia workstation-class GPUs for their crunching, and much of that software is either Linux-native, or comes with a Linux version (Maya immediately comes to mind), and Linux is used fairly often in those scenarios. Admittedly, that's a bit of speculation, on my part, but it's based on honest observation (I know folks in those industries, so I have that as a starting point, at least). Anyhow, GPU support is one of the biggest pains in the arse I deal with during a Linux install. However, there are definitely the other reasons I gave up on Cinnamon and went with Openbox and Compton. That Cinnamon overrides certain Xorg configs, and absorbs others in odd ways is the biggest. Conflicting with the GPU driver was sort of the last straw. I was using Linux as a server/hosting OS, mostly, and OS X as my *Nix-based desktop. I got tired of the bloat and half-baked features, which, over the last few revisions have stepped on my feet more and more and more. I want lean, I want out-of-my-way. I find KDE to be incredibly bloated, and both KDE and XFCE have wayyy too many settings panes/apps for my taste. Most of that is stuff I'd typically set in a config file somewhere, and touch maybe once in a blue moon- i.e., I don't really need a GUI for most of it. I don't particularly care for the look and feel of either LXDE or MATE, and I'll stay away from GNOME for the same reasons I dropped Cinnamon. My current Openbox stack is doing a great job. It's easy enough to theme it the way I want, with lxappearance-obconf and the standard config files. It simply obeys those, it's lean, it's reliable, and it performs well. ------=_Part_4013_1590567692.1423010288043 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
That's odd- I've always experienced the opposite, ie: the = proprietary Nvidia driver has typically worked for me, and the open source = Nouveau driver has typically given me issues.
Also, I've always needed t= o do some finagling to get ATI drivers to work, but that's likely because I= 've typically installed my Linux rollouts on Apple laptops, and dealing wit= h their combination of GMUX hardware/GPU hardware configuration and non-sta= ndard UEFI implemenation is a pain in the arse, and has required rolling a = kernel (of course, it didn't help that I was running Debian, which uses an = older kernel), and telling it where to find the Radeon BIOS. Add to that, o= n my 2011 MBP, vgaswitcheroo works, but something in the way MBP-specific G= PU switching in the kernel extensions is written (and the code, written by = some guys at Red Hat, looks like it was written a decade ago) causes the Ra= deon to crap out during subsequent power-cycling (works the first time, not= on additional tries), so I ended up writing my own user-space utility for = handling that.

From what I understand, the proprietary Nvidia driver= s are better, especially performance-wise, than the proprietary ATI drivers= , and, from dealing with both, I feel like Nvidia provide much more love to= the Linux community than ATI. This may be partly because a lot of high-end= animation and rendering workstations use Nvidia workstation-class GPUs for= their crunching, and much of that software is either Linux-native, or come= s with a Linux version (Maya immediately comes to mind), and Linux is used = fairly often in those scenarios. Admittedly, that's a bit of speculation, o= n my part, but it's based on honest observation (I know folks in those indu= stries, so I have that as a starting point, at least).

Anyhow, GPU s= upport is one of the biggest pains in the arse I deal with during a Linux i= nstall.
However, there are definitely the other reasons I gave up on Cin= namon and went with Openbox and Compton. That Cinnamon overrides certain Xo= rg configs, and absorbs others in odd ways is the biggest. Conflicting with= the GPU driver was sort of the last straw.

I was using Linux as a s= erver/hosting OS, mostly, and OS X as my *Nix-based desktop. I got tired of= the bloat and half-baked features, which, over the last few revisions have= stepped on my feet more and more and more.
I want lean, I want out-of-m= y-way. I find KDE to be incredibly bloated, and both KDE and XFCE have wayy= y too many settings panes/apps for my taste. Most of that is stuff I'd typi= cally set in a config file somewhere, and touch maybe once in a blue moon- = i.e., I don't really need a GUI for most of it. I don't particularly care f= or the look and feel of either LXDE or MATE, and I'll stay away from GNOME = for the same reasons I dropped Cinnamon.
My current Openbox stack is doi= ng a great job. It's easy enough to theme it the way I want, with lxappeara= nce-obconf and the standard config files. It simply obeys those, it's lean,= it's reliable, and it performs well.

------=_Part_4013_1590567692.1423010288043-- ------=_Part_4012_932072130.1423010288043--