Fresh Installation Of FreeBSD 11.2--Mate Not Working Properly

Quarter Wave Vertical

Member

Thanks: 9
Messages: 77

#1
Yesterday, I wanted to upgrade one of my machines to 12.0-RC3 and ended up trashing my system.

I tried several times to re-install 11.0 (upgrading to 11.2 afterward) with Mate and Slim and I couldn't get the desktop to work properly. The best I could do is to log on through Slim, even after I made a fresh installation of 11.2 directly. I get the Mate desktop but none of the utilities (such as Mate Terminal) in the menu bar work.

I don't know what to do next. I'm wondering if something's not set up properly, but I don't think I missed any of the steps.

One possibility is to swap the HD as it's over 10 years old.

Does anyone have any suggestions? Thank you.
 

Vull

Member

Thanks: 19
Messages: 65

#2
How much memory do you have? Starting with a fresh install made from FreeBSD-11.2-RELEASE-i386-memstick.img, I've installed mate on an approximately 10 year old Intel Pentium 4 i386 machine with 3 GB of RAM. It's very sluggish and slow, but everything works okay, I guess. Still, I find that it's just barely passable, performance-wise. This Dell Dimension 4700 machine does have the improvement of a newer 1TB SATA hard drive replacement, and all IDE devices have been removed physically and in the BIOS.
It works okay, but just barely, with only pkg install xorg mate sddm added, but it's too slow, which seems odd since the same machine runs pretty briskly with kde5, xfce, lxde, or enlightenment installed on it (FreeBSD), and it can also run the Debian and Ubuntu versions of mate at reasonable speeds, and without the same sluggishness. In /etc/rc.conf I only had to add dbus_enable="YES" and sddm_enable="YES". Many people also add hald_enable="YES" but I'm trying to avoid using HAL since it's been deprecated for several years, and using HAL doesn't affect the speed at all as far as I can tell.

Because of the slowdown in performance, I've opted not to use mate on this machine, but instead prefer kde5 for desktop/entertainment usage, or one of lxde, xfce, or enlightenment for a lighter-weight server-style front-end.
 
OP
OP
Q

Quarter Wave Vertical

Member

Thanks: 9
Messages: 77

#3
How much memory do you have? Starting with a fresh install made from FreeBSD-11.2-RELEASE-i386-memstick.img, I've installed mate on an approximately 10 year old Intel Pentium 4 i386 machine with 3 GB of RAM. It's very sluggish and slow, but everything works okay, I guess. Still, I find that it's just barely passable, performance-wise. This Dell Dimension 4700 machine does have the improvement of a newer 1TB SATA hard drive replacement, and all IDE devices have been removed physically and in the BIOS.
It works okay, but just barely, with only pkg install xorg mate sddm added, but it's too slow, which seems odd since the same machine runs pretty briskly with kde5, xfce, lxde, or enlightenment installed on it (FreeBSD), and it can also run the Debian and Ubuntu versions of mate at reasonable speeds, and without the same sluggishness. In /etc/rc.conf I only had to add dbus_enable="YES" and sddm_enable="YES". Many people also add hald_enable="YES" but I'm trying to avoid using HAL since it's been deprecated for several years, and using HAL doesn't affect the speed at all as far as I can tell.

Because of the slowdown in performance, I've opted not to use mate on this machine, but instead prefer kde5 for desktop/entertainment usage, or one of lxde, xfce, or enlightenment for a lighter-weight server-style front-end.
Thanks for your reply.

One thing that baffles me is that I've got almost the identical system installed on another drive on the same machine and it runs fine. (I figured I might need it as a backup.)

My machine is an older Compaq Presario running a Pentium D. I've got 4 GB installed, so memory's not a problem.

I don't know if this has anything to do with it, but I believe I installed the original system when it was FreeBSD 10.x and upgraded it whenever a new release was available.

That being said, I edited /etc/rc.conf like you did but, instead of sddm_enable="YES" I used hald_enable="YES" and slim_enable="YES".

I prefer Mate as I became accustomed to Gnome. I've been running xcfe on a laptop but I'm not all that fond of it. KDE never particularly impressed me, either.

I might try what you've done with /etc/rc.conf and see what happens. The problem I'm dealing with right now is that running xorg by itself gives me a dark screen.

Fortunately, I've got another machine with the same setup, so I'm not out of action.
 

Vull

Member

Thanks: 19
Messages: 65

#4
I'm guessing HAL isn't the issue, but maybe your hard drive is, especially since you say the same config is working okay on a different drive. Maybe the mate port for FreeBSD 10.x was different than the one for 11.2, but that's just another guess. IIRC I had previously installed mate on a 64 bit Acer Aspire laptop with 6 GB RAM, and didn't see the same performance lags that I have on the i386. There might be a difference in the i386 vs. the amd64 ports (just another guess, obviously). My only problems with the Acer laptop had to do with driver support for the Radeon graphics card and the wifi, which never worked for me, but fortunately it had a wired internet connection.

Good luck with it. I like mate a lot too, but fortunately I like kde5 just as much if not more. If your previous kde experience was with kde4, you might consider giving kde5 a shot, since it actually is quite a bit different, quite a bit more modern, and offers some noteworthy improvements.
 
OP
OP
Q

Quarter Wave Vertical

Member

Thanks: 9
Messages: 77

#5
I'm guessing HAL isn't the issue, but maybe your hard drive is, especially since you say the same config is working okay on a different drive. Maybe the mate port for FreeBSD 10.x was different than the one for 11.2, but that's just another guess.
That's what I suspect. The machine uses an Intel processor and I installed the FreeBSD version specifically for that. Later on, the versions were for the AMD only but I was able to successfully upgrade the OS.

IIRC I had previously installed mate on a 64 bit Acer Aspire laptop with 6 GB RAM, and didn't see the same performance lags that I have on the i386. There might be a difference in the i386 vs. the amd64 ports (just another guess, obviously). My only problems with the Acer laptop had to do with driver support for the Radeon graphics card and the wifi, which never worked for me, but fortunately it had a wired internet connection.

Good luck with it. I like mate a lot too, but fortunately I like kde5 just as much if not more. If your previous kde experience was with kde4, you might consider giving kde5 a shot, since it actually is quite a bit different, quite a bit more modern, and offers some noteworthy improvements.
 
OP
OP
Q

Quarter Wave Vertical

Member

Thanks: 9
Messages: 77

#6
I tried several different variations in installing Mate in order to get it to work on my machine, but I consistently got the same results. I'm wondering if it's reached its limit with that desktop. It's not the first time it's happened to one of my computers.

Since I'm already familiar with it, I installed Xfce and it's working so I can still use the machine, but not quite the way I had hoped.
 

Vull

Member

Thanks: 19
Messages: 65

#7
Your thread got me thinking that I could try to compile everything from ports using a fresh 11.2-RELEASE install on this old machine, just to see if that gave me any improvement in Mate's performance. It's taking many hours; I started it yesterday evening and right now it's on [3821/4594] of the xorg port compilation. I'll let you know how it works out whenever it gets through; it might be a few days though hah since I know that the mate port is also pretty big. I've never attempted such a big compile before so thanks for stimulating my thinking and inspiring me to do this.
 
OP
OP
Q

Quarter Wave Vertical

Member

Thanks: 9
Messages: 77

#8
Your thread got me thinking that I could try to compile everything from ports using a fresh 11.2-RELEASE install on this old machine, just to see if that gave me any improvement in Mate's performance. It's taking many hours; I started it yesterday evening and right now it's on [3821/4594] of the xorg port compilation. I'll let you know how it works out whenever it gets through; it might be a few days though hah since I know that the mate port is also pretty big. I've never attempted such a big compile before so thanks for stimulating my thinking and inspiring me to do this.
You're welcome.

I'm still tinkering with it and, so far, I haven't figured out what I might have missed.
 

kpedersen

Daemon

Thanks: 396
Messages: 1,244

#9
I have done this just recently in a jail to test and needed to remember the following:

1) dbus_enable="YES" in rc.local
2) hald_enable="YES" in rc.local
3) procfs mounted on /proc
4) pkg install mate
5) start with mate-session

It generally works. Marco (metacity) the window manager coredumps due to some libgtop error or some other untested crap. I just ran openbox instead for this test and the rest of the DE was relatively fine.
 
OP
OP
Q

Quarter Wave Vertical

Member

Thanks: 9
Messages: 77

#10
Thanks for your response.

I have done this just recently in a jail to test and needed to remember the following:

1) dbus_enable="YES" in rc.local
2) hald_enable="YES" in rc.local
I added those to /etc/rc.conf

3) procfs mounted on /proc
I added that to /etc/fstab, but I'm not sure if it made any difference. I recall, though, having to add something like that in early versions of FreeBSD/Gnome, but I never needed it for the other FreeBSD/Mate installations I have.

4) pkg install mate
5) start with mate-session

It generally works. Marco (metacity) the window manager coredumps due to some libgtop error or some other untested crap. I just ran openbox instead for this test and the rest of the DE was relatively fine.
The pull-down menus appear to work and I can change settings through Control Center.

The display defaults to 1280 x 1024 instead of 1024 x 768, which is what it's supposed to be.

I still can't mount external drives, such as a USB stick, which, in Mate happens automatically.

I was able to run a number of applications, such as Firefox and VLC, but those were set up on that HD under Xfce.

I can drag windows, files, and directories, but the response is slow, which isn't supposed to be.

When I log on and run startx, xterm starts up. After running exec mate-session, I get an error message about setting QT_SCALE_FACTOR=1 and having to recompile libgtop if there are problems.

I seem to be making progress, but, as they say, close but no cigar. I'm not sure what to do next.
 

Vull

Member

Thanks: 19
Messages: 65

#11
Using startx from my non-root user account, I get fewer errors when I put

exec ck-launch-session dbus-launch --exit-with-session mate-session

in my $HOME/.xinitrc file, instead of just the plain exec mate-session command. It has something to do with helping dbus to communicate. Do you have Power Management and Screensaver in your Control Center? It almost sounds like you have the "mate-base" package instead of the "mate" meta-port, but that can't be the case, since you do have the Mate Terminal program icon. Mate Terminal doesn't come with the "mate-base" package, nor do Power Management and Screensaver. If you do have those icons, do they work? Does your machine have ACPI? Mine doesn't but I can still set the timeouts and suspend sessions using APM, which it does have.
 

kpedersen

Daemon

Thanks: 396
Messages: 1,244

#12
Attached is a screenshot of my experiences.
I am running mine inside a Jail but perhaps I seem to be getting similar to you?
You can see that my xterm has no window border or title bar.

mate_gtop.png

I think the libgtop (i386) package is broken causing Marco (the Mate Window Manager) to crash.
Perhaps recompile just that package from ports?

These kind of errors really do show just how little these large desktop environments are used and maintained on FreeBSD. I am in the market for a simple to use desktop environments for my students and so far I am having much more success with Xfce4 currently. Though I am sure in a week or two that will be broken somehow ;)
 

Vull

Member

Thanks: 19
Messages: 65

#13
I'm now on my 3rd attempt at compiling Mate from ports, after 2 unsuccessful tries. By comparison, I had no problems compiling xorg from ports, although it took many hours. This ties up my development machine so that I can't use it for much of anything else, but in between compiles yesterday, I took the opportunity to install mate-base on a separate partition using pkg install mate-base, and it's working okay, same as my previous Mate installs using pkg have worked. If it ultimately turns out that I can get the x11/mate-base compile to work, I'll post the results and the procedure here. One thing I noticed during this endeavor is that the packages for mate and mate-base are for Mate version 1.20.0, whereas the port was updated to Mate version 1.20.3 on Nov. 5 (Guy Fawkes Day, ha). I'm guessing that this latest update has something to do with the ongoing efforts to make these Gnome-based desktops integrate better with Wayland, and it all begs the question of why they haven't upgraded the mate package to 1.20.3 as well, since a whole month has now passed since the port was upgraded. Also for comparision, my Debian 9.6 laptop's version of Mate, which I'm posting this from, seems to be Mate version 1.16.0 - if I had the port or package for Mate 1.16.0 on FreeBSD I'd try installing it instead, but, ah whell...

Last night I compiled graphics/cairo overnight, and it took about 12-1/2 hours to compile, so it's no small part of this Mate port. Cairo is a Wayland dependency and it seems to be one of the ports that keeps bombing my efforts to compile x11/mate-1.20.3, so I compiled it first, this time around, and it did manage to get through the compile without blowing up, this time. I'm probably doing it all wrong; I'm not using portmaster, but I'm open to suggestions if anybody has a better idea. Thanks.
 
OP
OP
Q

Quarter Wave Vertical

Member

Thanks: 9
Messages: 77

#14
Using startx from my non-root user account, I get fewer errors when I put

exec ck-launch-session dbus-launch --exit-with-session mate-session

in my $HOME/.xinitrc file, instead of just the plain exec mate-session command. It has something to do with helping dbus to communicate. Do you have Power Management and Screensaver in your Control Center?
Yes, and they appear to be working.

It almost sounds like you have the "mate-base" package instead of the "mate" meta-port, but that can't be the case, since you do have the Mate Terminal program icon. Mate Terminal doesn't come with the "mate-base" package, nor do Power Management and Screensaver. If you do have those icons, do they work? Does your machine have ACPI?
Yes.

Mine doesn't but I can still set the timeouts and suspend sessions using APM, which it does have.
 
OP
OP
Q

Quarter Wave Vertical

Member

Thanks: 9
Messages: 77

#15
Attached is a screenshot of my experiences.
I am running mine inside a Jail but perhaps I seem to be getting similar to you?
You can see that my xterm has no window border or title bar.

View attachment 5639

I think the libgtop (i386) package is broken causing Marco (the Mate Window Manager) to crash.
Perhaps recompile just that package from ports?
I keep getting a message about that on xterm. I was thinking about recompiling it from ports. The worst that can happen is that I have to start a brand-new installation.

These kind of errors really do show just how little these large desktop environments are used and maintained on FreeBSD. I am in the market for a simple to use desktop environments for my students and so far I am having much more success with Xfce4 currently. Though I am sure in a week or two that will be broken somehow ;)
I have a laptop that runs Xfce as, apparently, it couldn't handle a Mate installation. It's worked for me for nearly 2 years so far.
 
OP
OP
Q

Quarter Wave Vertical

Member

Thanks: 9
Messages: 77

#16
I thought that perhaps the hard drive (which is about as old as the computer) might be going wobbly, so I made a fresh installation on an external unit to see if that made a difference.

I got the identical performance. For example, I can't drag and place windows as quickly and easily as I can on my other installations. I get the same errors with xterm as well.

Something somewhere must have been fiddled since I originally installed this system on my other drives. The question is what.

Maybe it's time to consider a different desktop. KDE, maybe?
 

kpedersen

Daemon

Thanks: 396
Messages: 1,244

#17
Are you in the position to try to test it on an amd64 install of FreeBSD?
I still think it is due to a breakage in the i386 build of libgtop.

Perhaps the Mate maintainer only runs 64-bit as their test machine.
 

Vull

Member

Thanks: 19
Messages: 65

#18
I was finally able to get mate-base 1.20.3 to compile from ports. It was problematic, and this is a bit off topic, but, briefly, and in case anyone's interested, to make it compile successfully, I had to compile the dependency ports graphics/cairo and net/samba47 first and second, using make install clean. This was apparently because those two ports need to use python27 before it gets upgraded to python36 by the other ports. Then, thirdly, I compiled mate-base using make DISABLE_VULNERABILITIES=yes install clean, because of vulnerabilities in graphics/openjpeg which would cause the compile to abort otherwise. Finally, I compiled x11/xorg with make install clean. And it works. I'm sure there are other ways of doing it, but this worked for me. For comparisons, I also installed approximately the same things using packages on another partition of the same machine, except that version has mate-base version 1.20.0 instead of 1.20.3 because of the differences between available packages and ports.

Oddly, the compiled-from-ports 1.20.3 version shows the same problem with gtop you reported, whereas the control version of mate-base 1.20.0 I installed from packages does not. I don't know exactly why this is so, and otherwise they appear to be identical. I would have guessed it would have been the other way around.

To summarize from the postings above, my main reason for compiling mate-base from ports was to try to eliminate the lag-time in dragging windows, which I've long experienced, and which Quarter Wave Vertical also reported. This unfortunately did not work, and I still have the same lag time latency problem that I had experienced on the installed-from-packages version. Fooey. Ah whell.

About your problem with discovering and mounting USB drives, I had sort of forgotten some of this, but going through the compiler options reminded me, and, as I understand it, because the HAL Hardware Abstraction Layer (i.e., hald_enable="YES") is deprecated in FreeBSD, these versions of Mate have a default option selection to use devd instead of hald for device discovery. Some people use autofs as a workaround for this, but I've opted to use sysutils/automount instead. Briefly, all you should need to do to get device discovery to work properly is pkg install automount. Then, from the root account, copy /usr/local/etc/automount.conf.sample to /usr/local/etc/automount.conf and use your favorite text editor to change the setting for USER in automount.conf to whatever the name of your non-root account happens to be. After a reboot, the system should then be able to automatically mount any USB stick you insert and automatically open the file manager for you. You can then use the caja file manager or the command prompt to copy files with read/write privileges to and from the USB stick, and also you'll be able to unmount the drive from caja or from the non-root user's command prompt using the umount command. I tried this using the hald daemon alone, and it did not work for me. I have thus disabled hald in this and in all of my other desktop configurations in FreeBSD, and only use devd and sysutils/automount for device discovery and automount needs.

I like kde5 and wouldn't discourage anyone from trying it. It's a bit more flexible, IIRC, with regards to being able to use either hald or devd plus automount for device discovery and automounting. I still used automount instead of hald on kde5, but you might prefer to just use hald instead, and, if I'm not mistaken, it will remain your choice on kde5, but only for as long as hald is still being supported therein. HAL has been deprecated for several years, and is reportedly no longer being upgraded, but is still being used and maintained, so who knows when, if ever, it will actually ever go away completely.

Thanks & best regards.

Edited to add: In automount.conf I also changed:
Code:
ENCODING=pl_PL.ISO8859-2
CODEPAGE=cp852
to
Code:
ENCODING=en_US.UTF-8
 
OP
OP
Q

Quarter Wave Vertical

Member

Thanks: 9
Messages: 77

#19
Are you in the position to try to test it on an amd64 install of FreeBSD?
I still think it is due to a breakage in the i386 build of libgtop.

Perhaps the Mate maintainer only runs 64-bit as their test machine.
I've run into that before. I tried installing a certain third-party program several years ago and I couldn't get it to work until after I switched over to the AMD64 version of FreeBSD (the i386 version was still being supported at the time).

I've been using the AMD64 version ever since and it's only now that I've been having problems doing a fresh installation on my Intel machine. That's why I made the earlier comment about wondering if my computer is reaching its limits as far as FreeBSD is concerned.

That, however, doesn't explain the fact that I can run FreeBSD in command-line mode without any problems (yet) as well as being able to use Xfce as a desktop.

I do, however, have another machine that is 64 bits and haven't had any problems with the installations I've got on it, though I have to admit that I haven't attempted a fresh installation on that one.

Now that I think I've ruled out the HD as the problem, I plan on installing KDE5 on the external test drive and see how that works.
 
OP
OP
Q

Quarter Wave Vertical

Member

Thanks: 9
Messages: 77

#20
I was finally able to get mate-base 1.20.3 to compile from ports. It was problematic, and this is a bit off topic, but, briefly, and in case anyone's interested, to make it compile successfully, I had to compile the dependency ports graphics/cairo and net/samba47 first and second, using make install clean. This was apparently because those two ports need to use python27 before it gets upgraded to python36 by the other ports. Then, thirdly, I compiled mate-base using make DISABLE_VULNERABILITIES=yes install clean, because of vulnerabilities in graphics/openjpeg which would cause the compile to abort otherwise. Finally, I compiled x11/xorg with make install clean. And it works. I'm sure there are other ways of doing it, but this worked for me. For comparisons, I also installed approximately the same things using packages on another partition of the same machine, except that version has mate-base version 1.20.0 instead of 1.20.3 because of the differences between available packages and ports.

Oddly, the compiled-from-ports 1.20.3 version shows the same problem with gtop you reported, whereas the control version of mate-base 1.20.0 I installed from packages does not. I don't know exactly why this is so, and otherwise they appear to be identical. I would have guessed it would have been the other way around.

To summarize from the postings above, my main reason for compiling mate-base from ports was to try to eliminate the lag-time in dragging windows, which I've long experienced, and which Quarter Wave Vertical also reported. This unfortunately did not work, and I still have the same lag time latency problem that I had experienced on the installed-from-packages version. Fooey. Ah whell.

About your problem with discovering and mounting USB drives, I had sort of forgotten some of this, but going through the compiler options reminded me, and, as I understand it, because the HAL Hardware Abstraction Layer (i.e., hald_enable="YES") is deprecated in FreeBSD, these versions of Mate have a default option selection to use devd instead of hald for device discovery. Some people use autofs as a workaround for this, but I've opted to use sysutils/automount instead. Briefly, all you should need to do to get device discovery to work properly is pkg install automount. Then, from the root account, copy /usr/local/etc/automount.conf.sample to /usr/local/etc/automount.conf and use your favorite text editor to change the setting for USER in automount.conf to whatever the name of your non-root account happens to be. After a reboot, the system should then be able to automatically mount any USB stick you insert and automatically open the file manager for you. You can then use the caja file manager or the command prompt to copy files with read/write privileges to and from the USB stick, and also you'll be able to unmount the drive from caja or from the non-root user's command prompt using the umount command. I tried this using the hald daemon alone, and it did not work for me. I have thus disabled hald in this and in all of my other desktop configurations in FreeBSD, and only use devd and sysutils/automount for device discovery and automount needs.

I like kde5 and wouldn't discourage anyone from trying it. It's a bit more flexible, IIRC, with regards to being able to use either hald or devd plus automount for device discovery and automounting. I still used automount instead of hald on kde5, but you might prefer to just use hald instead, and, if I'm not mistaken, it will remain your choice on kde5, but only for as long as hald is still being supported therein. HAL has been deprecated for several years, and is reportedly no longer being upgraded, but is still being used and maintained, so who knows when, if ever, it will actually ever go away completely.

Thanks & best regards.

Edited to add: In automount.conf I also changed:
Code:
ENCODING=pl_PL.ISO8859-2
CODEPAGE=cp852
to
Code:
ENCODING=en_US.UTF-8
Thanks for your comments. The slow response in dragging windows appears to be a bug in the current setup.

How long did it take for the installation from ports? It seems each time I do that, I could go do something else as some of them could require several hours. That's assuming that there's no error in compiling, along with a listing of several cryptic messages. (That sort of thing reminds me of when I learned FORTRAN programming as an undergraduate using WATFOR/WATFIV.)
 

Vull

Member

Thanks: 19
Messages: 65

#21
The fix suggested by this compiler output made the libgtop errors go away for me:
Code:
===>  Installing for libgtop-2.38.0_1
===>  Checking if libgtop already installed
===>   Registering installation for libgtop-2.38.0_1 as automatic
Installing libgtop-2.38.0_1...
===============================================================================

In order to use the File System read/write monitor, you must chmod
/dev/devstat so that all users can open it read-only.  For example:

# chmod 0444 /dev/devstat

In order for this to persist across reboots, add the following to
/etc/devfs.conf:

perm    devstat 0444

===============================================================================

===> SECURITY REPORT:
      This port has installed the following files which may act as network
      servers and may therefore pose a remote security risk to the system.
/usr/local/bin/libgtop_daemon2

      If there are vulnerabilities in these programs there may be a security
      risk to the system. FreeBSD makes no guarantee about the security of
      ports included in the Ports Collection. Please type 'make deinstall'
      to deinstall the port if this is a concern.
===>   marco-1.20.2 depends on shared library: libgtop-2.0.so - found (/usr/loca
l/lib/libgtop-2.0.so)
===>   Returning to build of marco-1.20.2

Thanks for your comments. The slow response in dragging windows appears to be a bug in the current setup.

How long did it take for the installation from ports? It seems each time I do that, I could go do something else as some of them could require several hours. That's assuming that there's no error in compiling, along with a listing of several cryptic messages. (That sort of thing reminds me of when I learned FORTRAN programming as an undergraduate using WATFOR/WATFIV.)
Not counting the time spent on redoing things after cryptic error messages, I got a clean start-over as described above, and everything went smoothly afterwards. So then, from that point onwards, the first compile (cairo) ran for about 12.5 hours, and took care of a lot of the dependencies for the other compiles. The samba47 compile then ran for a little over 1.5 hours, the mate-base compile then took just under 4.0 hours, and the xorg compile took about 1.5 hours. Note that this is for mate-base and not the complete mate "meta" package. I still need to add mate-terminal to get what I want, and maybe a few other things, and I'm still not sure if I'm even going to use it. As I mentioned before, I like kde5 and the only reason I'm not using it instead of Mate is because it's too memory hungry for a server front-end. For a server-less desktop-only system I would definitely use kde5 instead. There is no window-dragging latency problem with kde5 on my machine, and in fact of all the DEs I've tried, including xfce, lxde, and Enlightenment, only Mate has exhibited this latency problem. As for kde5 it's accurately described as a bit of a cpu and memory hog but it still runs remarkably well on this ancient i386 machine with only 2 cpus, 3 GB RAM, a 2.8 GHz processor speed and 800 Mhz bus speed. Great DE, and I really like the look and feel using the Oxygen theme.

Edit to add: one more thing, when I did the compiles I used make config-recursive before running make install clean in order to set all the options in advance. It would take much longer if I omitted that step. Out of time for now, good luck & ttyl
 
OP
OP
Q

Quarter Wave Vertical

Member

Thanks: 9
Messages: 77

#22
The fix suggested by this compiler output made the libgtop errors go away for me:
Code:
===>  Installing for libgtop-2.38.0_1
===>  Checking if libgtop already installed
===>   Registering installation for libgtop-2.38.0_1 as automatic
Installing libgtop-2.38.0_1...
===============================================================================

In order to use the File System read/write monitor, you must chmod
/dev/devstat so that all users can open it read-only.  For example:

# chmod 0444 /dev/devstat

In order for this to persist across reboots, add the following to
/etc/devfs.conf:

perm    devstat 0444

===============================================================================

===> SECURITY REPORT:
      This port has installed the following files which may act as network
      servers and may therefore pose a remote security risk to the system.
/usr/local/bin/libgtop_daemon2

      If there are vulnerabilities in these programs there may be a security
      risk to the system. FreeBSD makes no guarantee about the security of
      ports included in the Ports Collection. Please type 'make deinstall'
      to deinstall the port if this is a concern.
===>   marco-1.20.2 depends on shared library: libgtop-2.0.so - found (/usr/loca
l/lib/libgtop-2.0.so)
===>   Returning to build of marco-1.20.2



Not counting the time spent on redoing things after cryptic error messages, I got a clean start-over as described above, and everything went smoothly afterwards. So then, from that point onwards, the first compile (cairo) ran for about 12.5 hours, and took care of a lot of the dependencies for the other compiles. The samba47 compile then ran for a little over 1.5 hours, the mate-base compile then took just under 4.0 hours, and the xorg compile took about 1.5 hours. Note that this is for mate-base and not the complete mate "meta" package. I still need to add mate-terminal to get what I want, and maybe a few other things, and I'm still not sure if I'm even going to use it. As I mentioned before, I like kde5 and the only reason I'm not using it instead of Mate is because it's too memory hungry for a server front-end. For a server-less desktop-only system I would definitely use kde5 instead. There is no window-dragging latency problem with kde5 on my machine, and in fact of all the DEs I've tried, including xfce, lxde, and Enlightenment, only Mate has exhibited this latency problem. As for kde5 it's accurately described as a bit of a cpu and memory hog but it still runs remarkably well on this ancient i386 machine with only 2 cpus, 3 GB RAM, a 2.8 GHz processor speed and 800 Mhz bus speed. Great DE, and I really like the look and feel using the Oxygen theme.

Edit to add: one more thing, when I did the compiles I used make config-recursive before running make install clean in order to set all the options in advance. It would take much longer if I omitted that step. Out of time for now, good luck & ttyl
So, by the time you were finished, it took some 20 hours. It makes one wonder whether it's worth installing Mate that way. Of course, one could run the machine with a different desktop and build Mate in the background in a terminal window after signing on as a superuser.

I'll take a look at KDE5. It's been a number of years since I last tried KDE so I'm not familiar with what it's like now.

It's too bad that installing Mate using pkg has gone wobbly. I really liked it after using Gnome2 for quite a while when my computer was running Linux.
 

Vull

Member

Thanks: 19
Messages: 65

#23
Since my main hope was to work around the delayed window dragging problem and it didn't work, I suppose it wasn't worth it in that sense, but it didn't really cost me anything but a little time, and I gained a little experience at compiling things from ports, and learned a few things about the inner workings of Mate. The security hole created by graphics/openjpeg for instance. I have another machine I can use when this one's busy, so I just compiled everything straight from the console. All in all I thought the whole experiment was pretty interesting and worth a try anyway.
 
Top