Decent Starting Point For Rolling A Desktop Environment?

Decent Starting Point For Rolling A Desktop Environment?

[Antonio Malcolm]

[-- Attachment #1.1: Type: text/plain, Size: 743 bytes --]

Currently, I'm attempting to roll a gdm + cinnamon DE, and have the 
packages installed, but configuration is going less than stellar.
Adding the entries to /etc/rc.conf doesn't seem to do much good, as I can't 
launch gdm.
Xorg is installed, and I can start that just fine.

Adding dbus and gdm to DAEMONS=() in /etc/rc.conf results in booting to a 
command line prompt, only to see an "Error in module" message after 
authenticating.
Adding them to /etc/rc.conf via enable_dbus="YES" and enable_gdm="YES"  
does nothing.

Most of the current documentation from a Google search results in countless 
references to installing with systemd, but I'm trying to avoid systemd.
(That said, it's tempting, because it looks easier.)


[-- Attachment #1.2: Type: text/html, Size: 777 bytes --]

Re: Decent Starting Point For Rolling A Desktop Environment?

[Christian Neukirchen]

Antonio Malcolm <antonio...@gmail.com> writes:

> Adding dbus and gdm to DAEMONS=() in /etc/rc.conf results in booting to a 
> command line prompt, only to see an "Error in module" message after 
> authenticating.
> Adding them to /etc/rc.conf via enable_dbus="YES" and enable_gdm="YES"  
> does nothing.

Please read https://github.com/voidlinux/documentation/wiki/runit on
how to start daemons in void.

-- 
Christian Neukirchen  <chneuk...@gmail.com>  http://chneukirchen.org

Re: Decent Starting Point For Rolling A Desktop Environment?

[Enno Boland]

[-- Attachment #1.1: Type: text/plain, Size: 909 bytes --]

https://github.com/voidlinux/documentation/wiki/runit

Am Donnerstag, 22. Januar 2015 15:58:54 UTC+1 schrieb Antonio Malcolm:
>
> Currently, I'm attempting to roll a gdm + cinnamon DE, and have the 
> packages installed, but configuration is going less than stellar.
> Adding the entries to /etc/rc.conf doesn't seem to do much good, as I 
> can't launch gdm.
> Xorg is installed, and I can start that just fine.
>
> Adding dbus and gdm to DAEMONS=() in /etc/rc.conf results in booting to a 
> command line prompt, only to see an "Error in module" message after 
> authenticating.
> Adding them to /etc/rc.conf via enable_dbus="YES" and enable_gdm="YES"  
> does nothing.
>
> Most of the current documentation from a Google search results in 
> countless references to installing with systemd, but I'm trying to avoid 
> systemd.
> (That said, it's tempting, because it looks easier.)
>
>

[-- Attachment #1.2: Type: text/html, Size: 1058 bytes --]

Re: Decent Starting Point For Rolling A Desktop Environment?

[Antonio Malcolm]

[-- Attachment #1.1: Type: text/plain, Size: 453 bytes --]

Ok, will give symlinking for runit a go...

Though, it doesn't quite explain why adding mdadm as a daemon to rc.conf is 
working for me, currently, per the wiki I just added: 
https://github.com/voidlinux/documentation/wiki/Installing-On-UEFI-with-BIOS-RAID-%28FakeRAID%29
However, if symlinking is the proper method, I'll give that a go later 
today, and update the wiki page, accordingly.

Thanks, much! Liking Void, very much, so far!

>
>

[-- Attachment #1.2: Type: text/html, Size: 628 bytes --]

Re: Decent Starting Point For Rolling A Desktop Environment?

[Logen Kain]

[-- Attachment #1.1: Type: text/plain, Size: 107 bytes --]

Oh yea, the symlinking method is one of the things that made me fall for 
void/runit.  Easy and elegant.

[-- Attachment #1.2: Type: text/html, Size: 133 bytes --]

Re: Decent Starting Point For Rolling A Desktop Environment?

[Antonio Malcolm]

[-- Attachment #1.1: Type: text/plain, Size: 192 bytes --]

WELL, that certainly worked.
It was fun, listening to the speakers pop a bit when adding the symlink for 
ALSA, and the wireless LED indicator light up, for NetworkManager.

Thanks, all!

[-- Attachment #1.2: Type: text/html, Size: 219 bytes --]

Re: Decent Starting Point For Rolling A Desktop Environment?

[Logen Kain]

[-- Attachment #1.1: Type: text/plain, Size: 271 bytes --]

This might be a local problem for me due to hardware... I use a R61 and my 
router is comcast.  The dhcp feels so slow to connect on it.  If you are on 
a laptop and you feel it's too slow to connect for you, static IP's are 
much faster when comming out of standby.

[-- Attachment #1.2: Type: text/html, Size: 298 bytes --]

Re: Decent Starting Point For Rolling A Desktop Environment?

[Antonio Malcolm]

[-- Attachment #1.1: Type: text/plain, Size: 200 bytes --]

Ok, got lightdm and cinnamon up and running (gdm was a pain in the arse- 
lightdm was much more compliant).
As this requires some additional packages and finagling, I'll likely add 
another wiki.

[-- Attachment #1.2: Type: text/html, Size: 221 bytes --]

Re: Decent Starting Point For Rolling A Desktop Environment?

[Antonio Malcolm]

[-- Attachment #1.1: Type: text/plain, Size: 334 bytes --]

OK< I've hit another issue, and can't seem to find a decent answer when 
searching:

In Cinnamon, applets won't launch from the menu, and when I run:

$ cinnamon-settings

I'm greeted with:

$ python: undefined symbol: pam_start

I can confirm both Python and PAM are installed on this machine, as well as 
python-pam.


[-- Attachment #1.2: Type: text/html, Size: 395 bytes --]

Re: Decent Starting Point For Rolling A Desktop Environment?

[Logen Kain]

[-- Attachment #1.1: Type: text/plain, Size: 844 bytes --]



On Saturday, January 24, 2015 at 2:27:59 AM UTC-6, Antonio Malcolm wrote:
>
> OK< I've hit another issue, and can't seem to find a decent answer when 
> searching:
>
> In Cinnamon, applets won't launch from the menu, and when I run:
>
> $ cinnamon-settings
>
> I'm greeted with:
>
> $ python: undefined symbol: pam_start
>
> I can confirm both Python and PAM are installed on this machine, as well 
> as python-pam.
>

So I was just sitting in MATE when I read this and installed cinnamon "sudo 
xbps-install -S cinnamon"
Log out into lxdm
Logged into it via lxdm.
click menu > gedit
It worked.
lxdm seems to just work with whatever I install and no setup, perhaps 
that'll help.  And for reference my /var/services
agetty-tty[1-6], alsa, dbus, dhcpcd, lxdm, ntpd.

I'll try with light-dm and will report back. 

[-- Attachment #1.2: Type: text/html, Size: 1042 bytes --]

Re: Decent Starting Point For Rolling A Desktop Environment?

[Logen Kain]

[-- Attachment #1.1: Type: text/plain, Size: 792 bytes --]

I installed lightdm along with the gtk3 greeter.

Upon trying to start cinnamon it failed, however it did work in *Software 
Rendering* mode.

Gedit still opened from the menu.

Running cinnamon-settings seems to have worked.

python-pam is installed for me as well, the 2.x version NOT the 3.4 version.
pam, pam-base, pam-libs as well.

Perhaps try to reinstall the pam packages?  I'm sorry, but I really have no 
idea what else it could be and I can't seem to replicate your issue on my 
machine.  My machine is also far from fresh.

If you can replicate the issue on a fresh install, I'd be happy to try it 
myself.  I should be getting a Lenovo T420 in a couple days, I'll probably 
want to install void anyway.  If I remember I'll try to test it out then as 
well.


[-- Attachment #1.2: Type: text/html, Size: 856 bytes --]

Re: Decent Starting Point For Rolling A Desktop Environment?

[Logen Kain]

[-- Attachment #1.1: Type: text/plain, Size: 106 bytes --]

So I just realized the pam issue was moved to another thread.  Well hope 
it's all working for you now.

[-- Attachment #1.2: Type: text/html, Size: 153 bytes --]

Re: Decent Starting Point For Rolling A Desktop Environment?

[Juan RP]

[-- Attachment #1.1: Type: text/plain, Size: 199 bytes --]

The pam issue was due to python requiring an up to date ld.so(8) cache and 
was fixed some days ago by me.

A live image with cinnamon and autologin created with void-mklive confirmed 
the fix.

[-- Attachment #1.2: Type: text/html, Size: 235 bytes --]

Re: Decent Starting Point For Rolling A Desktop Environment?

[Antonio Malcolm]

[-- Attachment #1.1: Type: text/plain, Size: 301 bytes --]

Sorry to get back to this so late, but, yes, it's been fixed- everything 
but cinnamon-settings worked, for me, out-of-the-box, and, after the 
python-pam fix, cinnamon-settings worked fine, too.
Getting lightdm, with the gtk greeter, and cinnamon up and going was easy 
enough.

Thanks!

>
>

[-- Attachment #1.2: Type: text/html, Size: 472 bytes --]

Re: Decent Starting Point For Rolling A Desktop Environment?

[Antonio Malcolm]

[-- Attachment #1.1: Type: text/plain, Size: 1348 bytes --]

Well, ok, an update: Cinnamon breaks BADLY with the most recent Nvidia 
drivers. Add to that, it does irritating things, with either overriding 
some Xorg settings, and (at least the HOW of) its use of Xorg settings in 
its own settings (I had lots of fun getting my trackpad to work 
predictably). Solutions, from around the web, for solving the Cinnamon + 
Nvidia debacle, range from such magic, as install bumblebee, and *MAGIC*, 
cinnamon will suddenly work, to reinstalling Nvidia drivers, from the 
Nvidia website and *MAGIC*,  Cinnamon will suddenly work, to reinstalling 
your entire Linux setup and *MAGIC*, everything will just work. Yeah, no 
thanks.

Anyhow, I've ended up happily chugging along with a 
lightdm+openbox+compton+thunar stack. Quite happily.
Add tint2 and kupfer to the equation, and it's a golden setup, which 
behaves just as expected- as configured. 
When you're going to set things via config files, anyhow, you may as well 
go all the way, and go with the solution which operates almost solely 
according to those configs, without adding so much cruft atop them.
Lessons learned!
The only two bits of cruft, in my current setup are obconf and 
lxappearance, as they do make setting the general "look and feel" stuffs 
easier. And lightdm appears to work easily with whatever you put behind it.

[-- Attachment #1.2: Type: text/html, Size: 1358 bytes --]

Re: Decent Starting Point For Rolling A Desktop Environment?

[Logen Kain]

[-- Attachment #1.1: Type: text/plain, Size: 365 bytes --]

I had an issue with the current nvidia drivers as well.  It seemed to be 
missing libs.  Couldn't open settings.  A switch to stable solved all those 
issues.  

I might be alone here, but I've always had issues Nvidia in Linux.  Once 
upon a time they were the only ones that worked, but they still sucked.  
Mehbe I should just switch back to a 3dFX card.

[-- Attachment #1.2: Type: text/html, Size: 414 bytes --]

Re: Decent Starting Point For Rolling A Desktop Environment?

[Stefan Mühlinghaus]

[-- Attachment #1.1: Type: text/plain, Size: 475 bytes --]

I have had Nvidia issues as well, though with the current kernel/driver 
combination it is working again. I think it was some DRM problem.

If you don't like the proprietary driver or have problems with it you could 
always use the nouveau-driver. It's more compatible but does not have the 
same kind of performance in 3D-heavy applications like games. However, it 
should work just fine. If you are not picky with your 3D performance you 
may want to git it a try.

[-- Attachment #1.2: Type: text/html, Size: 506 bytes --]

Re: Decent Starting Point For Rolling A Desktop Environment?

[Antonio Malcolm]

[-- Attachment #1.1: Type: text/plain, Size: 3074 bytes --]

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.


[-- Attachment #1.2: Type: text/html, Size: 3049 bytes --]

Re: Decent Starting Point For Rolling A Desktop Environment?

[Stefan Mühlinghaus]

[-- Attachment #1.1: Type: text/plain, Size: 556 bytes --]

I absolutely agree. I used OS X for a while and was quite happy with it. 
But then it seemd to just get worse (and slower!) with every new iteration 
and all the programs started to depend on the new OS versions. Thats where 
I jumped off and used linux fulltime.

Now I'm running a very barebones setup. Login via the console, Xorg via 
startx and in it a tiny, tiling windowmananger called Xoat. I do most stuff 
like configuration or editing on the shell and it works great for me. But I 
know that kind of setup is not everyones cup of tea :)

[-- Attachment #1.2: Type: text/html, Size: 585 bytes --]

Re: Decent Starting Point For Rolling A Desktop Environment?

[Antonio Malcolm]

[-- Attachment #1.1: Type: text/plain, Size: 168 bytes --]

Indeed. I find that most of the stuff I'm configuring from the console 
(usually via vi or nano), I don't touch that often. It's, mostly, a 
set-and-forget affair. 

[-- Attachment #1.2: Type: text/html, Size: 187 bytes --]

Re: Decent Starting Point For Rolling A Desktop Environment?

[Logen Kain]

[-- Attachment #1.1: Type: text/plain, Size: 4167 bytes --]

AMD seems to be doing something to make their support better for newer 
cards. Something about an opensource thing they'll add to the kernel, and 
their drivers will talk to that.  Hopefully fixing most of the issues 
they've had over the years.

Their cards do typically take more effort to get to work, but when they 
work, everything works.  My nvidia card?  Everytime I boot, after I finally 
got brightness control to work at all, it is set at full blast.  There are 
various settings in the settings menu that doesn't seem to be set unless 
you open the settings menu.  By the way, I'm running an AMD card in my 
desktop... VoidLinux does an awesome job. First distro it "just worked" and 
has kept working, without me fighting with it.

But yes, back in the day, they both sucked but Nvidia typiclaly worked.  
Now both of them work, but you have to try if you want everything working 
well.  


On Tuesday, February 3, 2015 at 6:38:08 PM UTC-6, Antonio Malcolm wrote:
>
> 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.
>
>

[-- Attachment #1.2: Type: text/html, Size: 4219 bytes --]

Re: Decent Starting Point For Rolling A Desktop Environment?

[Antonio Malcolm]

[-- Attachment #1.1: Type: text/plain, Size: 1242 bytes --]

Yeah, my biggest gripe, setting up Nvidia, now, is that Nvidia's OpenGL 
drivers overwrite Intel's OpenGL drivers, meaning if you have dual GPU's, 
you get no OpenGL acceleration on the integrated (Intel) GPU.
Currently, I'm tinkering with using Nvidia's installer to install their 
drivers to another directory, and point to them in an xorg conf file 
specific to Optimus settings. Using their kernel module seems to break 
xorg's server in Void, though (which makes it unusable- the screen flashes, 
and there's no way to get to the CLI), so my next attempt is to use their 
drivers with Void's nvidia-dkms package. Other wise, between xorg conf 
files specific to each GPU, and lightdm's conf, I'm able to switch between 
an Optimus setup and an Intel standalone setup. I should be able to get 
this working, it's just going to take some trial and error. This is on an 
Aorus X3+.

And getting either AMD or Nvidia, with dual graphics, on the MacBook Pro, 
is ALWAYS a pain in the arse, but that has nothing to do with either AMD or 
Nvidia, and everything to do with Apple. In any case, GPU setup in Linux is 
typically work, and more work than getting other things configured (save 
for, maybe, trackpads, sometimes).

[-- Attachment #1.2: Type: text/html, Size: 1241 bytes --]

Re: Decent Starting Point For Rolling A Desktop Environment?

[Logen Kain]

[-- Attachment #1.1: Type: text/plain, Size: 396 bytes --]

In my case I have a thinkpad t420 (not sure if I've mentioned this already) 
with the optional Nvidia card.  The hd3000 runs cooler and seems to do 
everything I want it to almost as well as the Nvidia.  So I just use the 
Intel.  

Overwriting the OpenGL drivers is a new thing?  That seems like odd 
timing... now that Intell gpu's are finally capable of something other than 
MSpaint.

[-- Attachment #1.2: Type: text/html, Size: 433 bytes --]

Re: Decent Starting Point For Rolling A Desktop Environment?

[Antonio Malcolm]

[-- Attachment #1.1: Type: text/plain, Size: 873 bytes --]

Ah, no, it's not new. The proprietary Nvidia installer (and, by extension, 
the distro-specific installers), overwrite the Intel/Xorg *glx and *GL 
drivers, in additiona to some others (I think, also the Mesa Intel DRI 
stuffs- but don't quite me, on that).
So far, my attempts to abstract Nvidia's drivers has only borked things, as 
the Nvidia install does more than simply install the drivers; there's a 
lot, there, in general, so it becomes a time-sink, tracking it all and 
performing what is, essentially, dependency-surgery. So, I'm going to 
attempt the opposite, and copy the Intel-specific stuffs, which are more 
manageable, and easier to fix, if something breaks, to an /intel directory 
inside of /usr/lib/xorg, add the module paths to an Intel-specific Xorg 
config, and install the Nvidia packages in the usual way. We'll see how 
that goes...

[-- Attachment #1.2: Type: text/html, Size: 876 bytes --]