Re: Linux on HP consumer laptop

[Tom H]

On Mon, Apr 4, 2016 at 5:25 PM, Yasha Karant  wrote:
> On 04/04/2016 07:02 AM, Tom H wrote:
>> On Mon, Apr 4, 2016 at 6:44 AM, Yasha Karant  wrote:
>>>
>>> In this regard, is anyone using Ubuntu LTS in a production
>>> environment? Is it fact both stable and (reasonably) hardened (e.g.,
>>> not a consume/enthusiast product such as MS Win or RH Fedora)?
>>
>> On the desktop, there are far more Windows systems deployed than Linux
>> ones...
>
> First, in many parts of the world other than the USA, MS Windows is
> not that well deployed even on the desktop except that many machines
> come with MS Windows pre-installed.

In the corporate world, Windows dominates the desktop (it also
dominates the desktop in the consumer/home world). So Windows is a
"production" OS.

Re: Virtual Box MS Win 7 guest no NAT issue now understood

[Tom H]

On Wed, Apr 6, 2016 at 7:19 AM, Yasha Karant  wrote:
>
> I have now resolved the cause of the lack of NAT Internet connection
> on a Virtual Box MS Win 7 guest.  After I installed SL 7.2 on my
> wife's new laptop, I restored (via a cp from an external USB hard
> drive that held all of the files that were not SL installed, including
> all of the Virtual Box guest files) the Virtual Box guest files from
> her previous laptop to the new machine.  I installed the Virtual Box
> EL7 RPM, configured VirtualBox to recognize the restored guest files,
> and the NAT network functioned over the 802.11 WNIC controlled by SL 7
> Network Manager -- everything worked (indeed, any statements that NAT
> would not work with 802.11 in "new" kernels were indeed red herrings).

Not at all. I even posted the kernel code where bridging's disabled for wifi.

VirtualBox doesn't use the Linux kernel's bridging.

This is from the VirtualBox documentation:

Bridging to a wireless interface is done differently from bridging to
a wired interface, because most wireless adapters do not support
promiscuous mode. All traffic has to use the MAC address of the host's
wireless adapter, and therefore VirtualBox needs to replace the source
MAC address in the Ethernet header of an outgoing packet to make sure
the reply will be sent to the host interface. When VirtualBox sees an
incoming packet with a destination IP address that belongs to one of
the virtual machine adapters it replaces the destination MAC address
in the Ethernet header with the VM adapter's MAC address and passes it
on. VirtualBox examines ARP and DHCP packets in order to learn the IP
addresses of virtual machines.

And this is from a laptop with a running VirtualBox VM. There's no
Linux bridge on the host (or a tun/tap interface either):

th@localhost:~$ VBoxManage list runningvms
"lubuntu" {65a3e709-e368-4717-8cd2-41e8751449ce}

th@localhost:~$ VBoxManage showvminfo lubuntu | grep "NIC 1"
NIC 1:   MAC: 080027A018CE, Attachment: Bridged Interface
'wlp18s0', Cable connected: on, Trace: off (file: none), Type:
82540EM, Reported speed: 0 Mbps, Boot priority: 0, Promisc Policy:
deny, Bandwidth group: none

th@localhost:~$ VBoxManage list bridgedifs
Name:wlp18s0
GUID:31706c77-7338-4030-8000-c0cb380f865a
DHCP:Disabled
IPAddress:   192.168.1.223
NetworkMask: 255.255.255.0
IPV6Address: 2a02:1205:c6a3:b7d0:c2cb:38ff:fe0f:865a
IPV6NetworkMaskPrefixLength: 64
HardwareAddress: c0:cb:38:0f:86:5a
MediumType:  Ethernet
Status:  Up
VBoxNetworkName: HostInterfaceNetworking-wlp18s0

th@localhost:~$ sudo ip l
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN
mode DEFAULT group default qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
3: wlp18s0:  mtu 1500 qdisc
pfifo_fast state UP mode DORMANT group default qlen 1000
link/ether c0:cb:38:0f:86:5a brd ff:ff:ff:ff:ff:ff

th@localhost:~$ sudo bridge l

th@localhost:~$ sudo ip -4 a
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN
group default qlen 1
inet 127.0.0.1/8 scope host lo
   valid_lft forever preferred_lft forever
3: wlp18s0:  mtu 1500 qdisc
pfifo_fast state UP group default qlen 1000
inet 192.168.1.223/24 brd 192.168.1.255 scope global wlp18s0
   valid_lft forever preferred_lft forever

th@localhost:~$ ssh 192.168.1.224

th@yasha:~$ sudo ip l
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN
mode DEFAULT group default qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: enp0s3:  mtu 1500 qdisc pfifo_fast
state UP mode DEFAULT group default qlen 1000
link/ether 08:00:27:a0:18:ce brd ff:ff:ff:ff:ff:ff

So "lubuntu" is running with an interface bridged using VirtualBox's
internal bridging and accessible from the host.

You were pointed at various ways to do this with Linux and KVM but
you'd have had to install and configure extra software to do so and it
never seemed to interest you.

Re: gimp toolbox?

[ToddAndMargo]

On 04/06/2016 12:59 AM, David Sommerseth wrote:


On 06/04/16 04:52, ToddAndMargo wrote:

Hi All,

I accidentally closed my gimp tool box.  How do I get the
default box back?


A quick search on the interwebs gave me this one as a high ranking
result:


(Search keywords: gimp toolbox missing)




Hi David,

Edit --> Preferences --> Window Management --> Reset Saved Window 
Positions to Default Values


Did the trick.

Thank you!

--
~~
Computers are like air conditioners.
They malfunction when you open windows
~~

Re: Issue with EPEL repo

[Lamar Owen]

On 04/05/2016 06:34 PM, Yasha Karant wrote:
Note that, unlike ELRepo folks with whom one can communicate via the 
SL list (persons who even are willing to identify themselves, and not 
"hide" behind some Bugzilla-like interface), EPEL seems much more 
unwilling to discuss matters. Has an EPEL "maintainer" ever (recently) 
posted/replied to the SL liist? I fully understand that the ELRepo 
folks are (presumably) volunteers, and thus may have little real free 
time to address such issues; hence, one should not pester them, 
particularly from typical enthusiast "users". I suspect that EPEL 
persons in part may, as with CentOS, now be paid by Red Hat, but I do 
not know this for a fact. ...


EPEL is essentially Fedora on a project level; it's basically 'the 
Fedora packages that can be packaged for various RHEL-derived 
distributions packaged for those distributions.'  It's also typically 
(but not always) the Fedora package maintainer maintaining the EPEL 
package, and it is most useful to contact that person directly.  
Bugzilla is the preferred means of contact, since it tracks the issues 
in a far more accessible (to the packager) way; no one is 'hiding' 
behind BZ, it's just the preferred way to get issues reported, tracked, 
and addressed.  Discussion of the base packages would likely be on the 
fedora-devel list, since EPEL is something of a Fedora thing.  Smooge, 
please feel free to correct my inaccuracies there, since you are 
connected directly to that and I am not.



On this point, a question.  I have been told (but not verified as a fact) that 
the Ubuntu equivalent to the main SL repository contains (all?) packages that 
one must, for any EL family distro, find on the master (SL, CentOS, etc.) 
repository and then hunt ELRepo, EPEL, and for some items, NUX and others (in 
which case I only enable software sources such as NUX during the actual 
installation of an RPM
package that only is available in source or on  such a repository).



This is partially true.  The Ubuntu repos, thanks to the Debian 
parentage and repos, are vast and include a lot of packages. However, 
even in Ubuntu-land one must eventually use a personal repo, known as a 
'PPA.'  PPAs are where things get hairy really quickly with Ubuntu since 
the quality of dependencies and the resolution of same varies wildly 
between different PPAs.  This is one of the basic differences between 
the Ubuntu and the RHEL-derived (and related, such as Fedora) 
ecosystems.  There are many more.


Off-topic note on something else you said:  US Southeast dialect does 
indeed differentiate between second person singular personal pronouns 
and second person plural personal pronouns.  Since 'thou' (while very 
correct and still used in certain theological and formal circles) is 
fallen from common use, the US Southeast dialect generally always 
addresses a singular second person as 'you' and plural second persons as 
y'all or you'n's (that last one is most commonly pronounced as the 
single syllable 'yunz' and is common in the Appalachian highlands; it is 
a contraction of 'you ones,' thus the 'nz' ending.  Y'all is of course 
the contraction of 'you all' and is more of a Piedmont and coastal 
thing).  The dual number use of 'you' is more confusing than helpful, 
when differentiating between singular and plural in the second person 
really is required, and the US Southeast dialect resolves the ambiguity 
in a creative, distinctive, and perhaps even a 'charming' way.

Re: Issue with EPEL repo

[Stephen John Smoogen]

On 6 April 2016 at 10:09, Lamar Owen  wrote:
> On 04/05/2016 06:34 PM, Yasha Karant wrote:
>>
>> Note that, unlike ELRepo folks with whom one can communicate via the SL
>> list (persons who even are willing to identify themselves, and not "hide"
>> behind some Bugzilla-like interface), EPEL seems much more unwilling to
>> discuss matters. Has an EPEL "maintainer" ever (recently) posted/replied to
>> the SL liist? I fully understand that the ELRepo folks are (presumably)
>> volunteers, and thus may have little real free time to address such issues;
>> hence, one should not pester them, particularly from typical enthusiast
>> "users". I suspect that EPEL persons in part may, as with CentOS, now be
>> paid by Red Hat, but I do not know this for a fact. ...
>
>
> EPEL is essentially Fedora on a project level; it's basically 'the Fedora
> packages that can be packaged for various RHEL-derived distributions
> packaged for those distributions.'  It's also typically (but not always) the
> Fedora package maintainer maintaining the EPEL package, and it is most
> useful to contact that person directly.  Bugzilla is the preferred means of
> contact, since it tracks the issues in a far more accessible (to the
> packager) way; no one is 'hiding' behind BZ, it's just the preferred way to
> get issues reported, tracked, and addressed.  Discussion of the base
> packages would likely be on the fedora-devel list, since EPEL is something
> of a Fedora thing.  Smooge, please feel free to correct my inaccuracies
> there, since you are connected directly to that and I am not.
>

What you state is mostly correct and probably how most people outside
of Fedora see how things working happen. The only difference would be
that discussion of the EPEL packages and group lists should be at
least cc'd on the epel-devel list as the people who can fix things are
on that list.



>> On this point, a question.  I have been told (but not verified as a fact)
>> that the Ubuntu equivalent to the main SL repository contains (all?)
>> packages that one must, for any EL family distro, find on the master (SL,
>> CentOS, etc.) repository and then hunt ELRepo, EPEL, and for some items, NUX
>> and others (in which case I only enable software sources such as NUX during
>> the actual installation of an RPM
>> package that only is available in source or on  such a repository).
>>
>
> This is partially true.  The Ubuntu repos, thanks to the Debian parentage
> and repos, are vast and include a lot of packages. However, even in
> Ubuntu-land one must eventually use a personal repo, known as a 'PPA.'  PPAs
> are where things get hairy really quickly with Ubuntu since the quality of
> dependencies and the resolution of same varies wildly between different
> PPAs.  This is one of the basic differences between the Ubuntu and the
> RHEL-derived (and related, such as Fedora) ecosystems.  There are many more.
>

Correct. The Fedora/EPEL version of this are called COPR's which can
be added to make your system better enabled.




-- 
Stephen J Smoogen.

MATE on SL 7

[Yasha Karant]

It appears that the software package GUI installer, gpk-application, 
does not have what is needed for an install of MATE
under SL.  (One evidently does not need MATE for SL 6 as Gnome 2 is part 
of the stock SL 6 distribution).  During the base install of SL 7,
I always install both whatever Gnome and KDE GUIs are supplied; thus the 
comment below about X windows is not relevant for my use.
I do this on servers as well as workstations so that graphical machine 
"workload" display and analysis tools are available in addition to the
scrolling text tools.  (Sometimes a visualisation provides insight that 
a table or text does not.)


From:

http://wiki.mate-desktop.org/download

Red Hat Enterprise Linux 7

MATE is available through the Extra Packages for Enterprise Linux (EPEL) 
repository, maintained by the Fedora Project. This should work on CentOS 
7 as well, and any other compatible derivatives.


After you install the epel-release-7*.rpm package to add the EPEL 
repository to Yum, you can install MATE with the following command:


yum groupinstall mate-desktop
If you install this on a minimal system without an existing GUI 
configured (such as a GNOME or KDE desktop), you might want to install 
the X Window System group as well for local graphical logins:


yum groupinstall "X Window System"
you may also want to change the default systemd target to graphical:

systemctl set-default graphical.target

End quote.  Note that unlike other entries in this URL document, the 
actual release (version) of MATE is not given (presumably because the 
document maintainers do not have the time or perhaps do
not get information from the EPEL "team",  Also, unlike the entry for 
Debian that states:

Debian

MATE 1.8.1 is currently packaged for Debian 8 (jessie). MATE 1.12 is 
also available on Debian testing (“Stretch”) and unstable (“Sid”).


(If sudo is unavailable on your system, simply omit it and use a root 
shell)

First make sure your package list is up-to-date by running:

sudo apt-get update
To install MATE, choose one of the apt-get options below.

This will install the base packages required for a minimal MATE desktop
sudo apt-get install mate-desktop-environment-core
This will install the complete MATE desktop
sudo apt-get install mate-desktop-environment
This will install the complete MATE desktop including a few extras
sudo apt-get install mate-desktop-environment-extras

End quote

There is no explanation of just which components are automagically 
loaded through the use of the RHEL 7 instructions; that is,
there is no explicit equivalent of:   This will install the complete 
MATE desktop including a few extras

sudo apt-get install mate-desktop-environment-extras

i am not certain what are in the "extras"; I do know that after I got 
MATE up and running on my wife's SL7.2 laptop, I had to hunt for the 
other RPMs I needed
to get MATE GUI displays of what she expected (and I also use on  my 
MATE desktop).  I am referring to items for the MATE menu and items for 
a MATE panel (e.g.,

applets).

Yasha Karant
;

Re: MATE on SL 7

[Tom H]

On Wed, Apr 6, 2016 at 11:30 PM, Yasha Karant  wrote:


> From:
>
> http://wiki.mate-desktop.org/download
>
> Red Hat Enterprise Linux 7
>
> MATE is available through the Extra Packages for Enterprise Linux
> (EPEL) repository, maintained by the Fedora Project. This should work
> on CentOS 7 as well, and any other compatible derivatives.
>
> After you install the epel-release-7*.rpm package to add the EPEL
> repository to Yum, you can install MATE with the following command:
>
> yum groupinstall mate-desktop
>
> If you install this on a minimal system without an existing GUI
> configured (such as a GNOME or KDE desktop), you might want to install
> the X Window System group as well for local graphical logins:
>
> yum groupinstall "X Window System"
>
> You may also want to change the default systemd target to graphical:
>
> systemctl set-default graphical.target
>
> End quote.
>
> Note that unlike other entries in this URL document, the actual
> release (version) of MATE is not given (presumably because the
> document maintainers do not have the time or perhaps do not get
> information from the EPEL "team".

Probably because EPEL doesn't stick to one version per release.

Last April, mate-desktop 1.8.2 was added. Last August, 1.10. Last
December, 1.12.


> Also, unlike the entry for Debian that states:
>
> Debian
>
> MATE 1.8.1 is currently packaged for Debian 8 (jessie). MATE 1.12 is
> also available on Debian testing (“Stretch”) and unstable (“Sid”).
>
> (If sudo is unavailable on your system, simply omit it and use a root
> shell)
>
> First make sure your package list is up-to-date by running:
>
> sudo apt-get update
>
> To install MATE, choose one of the apt-get options below.
>
> This will install the base packages required for a minimal MATE desktop
>
> sudo apt-get install mate-desktop-environment-core
>
> This will install the complete MATE desktop
>
> sudo apt-get install mate-desktop-environment
>
> This will install the complete MATE desktop including a few extras
>
> sudo apt-get install mate-desktop-environment-extras
>
> End quote
>
> There is no explanation of just which components are automagically
> loaded through the use of the RHEL 7 instructions; that is, there is
> no explicit equivalent of:
>
> This will install the complete MATE desktop including a few extras
>
> sudo apt-get install mate-desktop-environment-extras
>
> i am not certain what are in the "extras"; I do know that after I got
> MATE up and running on my wife's SL7.2 laptop, I had to hunt for the
> other RPMs I needed to get MATE GUI displays of what she expected (and
> I also use on my MATE desktop). I am referring to items for the MATE
> menu and items for a MATE panel (e.g., applets).

Debian has a tradition of chopping packages up.

For Gnome, there's gnome-core and gnome. The former provides a minimal
Gnome environment and the latter provides the full complement of apps.

I assume that the Debian Mate maintainers followed the same pattern
but I have no idea what mate-desktop-environment-extras might be. I
assume that EPEL's mate-desktop corresponds to Debian's
mate-desktop-environment.

Re: Issue with EPEL repo

[Nico Kadel-Garcia]

On Wed, Apr 6, 2016 at 12:09 PM, Lamar Owen  wrote:
> On 04/05/2016 06:34 PM, Yasha Karant wrote:
>>
>> Note that, unlike ELRepo folks with whom one can communicate via the SL
>> list (persons who even are willing to identify themselves, and not "hide"
>> behind some Bugzilla-like interface), EPEL seems much more unwilling to
>> discuss matters. Has an EPEL "maintainer" ever (recently) posted/replied to
>> the SL liist? I fully understand that the ELRepo folks are (presumably)
>> volunteers, and thus may have little real free time to address such issues;
>> hence, one should not pester them, particularly from typical enthusiast
>> "users". I suspect that EPEL persons in part may, as with CentOS, now be
>> paid by Red Hat, but I do not know this for a fact. ...
>
>
> EPEL is essentially Fedora on a project level; it's basically 'the Fedora
> packages that can be packaged for various RHEL-derived distributions
> packaged for those distributions.'  It's also typically (but not always) the
> Fedora package maintainer maintaining the EPEL package, and it is most
> useful to contact that person directly.  Bugzilla is the preferred means of
> contact, since it tracks the issues in a far more accessible (to the
> packager) way; no one is 'hiding' behind BZ, it's just the preferred way to
> get issues reported, tracked, and addressed.  Discussion of the base
> packages would likely be on the fedora-devel list, since EPEL is something
> of a Fedora thing.  Smooge, please feel free to correct my inaccuracies
> there, since you are connected directly to that and I am not.

There are some critical differences. EPEL never, never, never provides
a direct replacement or update to a base RHEL, and thus to a base
Scientific Linux package. I publish a *lot* of backported versions of
SRPM's to enable components for producton RHEL, CentOS, and Scientific
Linux environments. They do publish some parallel versions of packages
with alternative but compatible package names, and these can be
useful. But burden of backporting components that would require
updating system libraries winds up in the hand of individual
contributors, especially since RPMforge has effectively become
moribund. Many of them have been invaluable: "git" for RHEL or
Scientific Linux 5, for example, has been my friend.