[sf-lug] SF-LUG meeting notes for Monday 18 March 2019

Tue Mar 19 17:58:19 PDT 2019

On 3/19/19 5:03 PM, Rick Moen wrote:

     A lot which I am too tired to deal with today,
     Rick you always assume the worst when I make mention of
any problems I have experienced.

     I don't bother reporting things i tried in order to surmount the
problems I mentioned.  They did not work.

     But here is something I did today I updated my LibreOffice
to 6.2.1 and was presented with a problem.
A file  libreoffice-openclipart  must be removed before it can
be replaced by the newer version and between removing
the file and replacing it with the new version if you want
clipart LibreOffice can be updated by LibreOffice Manager.
The file and the new version are listed here:

libreoffice-openclipart (6.1-1pclos2018 => 6.2-1pclos2019)

Have a good day Rick it is bedtime for me.

> Quoting Bobbie Sellers (bliss-sf4ever at dslextreme.com):
>
>>      EasyOS 1.0.13 is an update supposedly but I had a lot of
>> trouble getting online.  I.E I could not get online.  The WiFi
>> card could not be found.
> Does this merely mean that you hoped EasyOS would autofind and
> autoconfigure your wireless, it didn't work out that way, and you did no
> other attempt to diagnose and fix the problem?  I ask because your
> phrasiing 'the WiFi card could not be found', read at face value, seems
> to suggest a hypothesis about, say, the chipset not being reported by
> lspci/lsusb (whichever, as appropriate), or something like that.
>
> Bobbie, you've been working with Linux for, what, over a decade now,
> right?  Isn't it time you moved past 'Something wasn't right, so I fixed
> the problem by switching to a different Linux distribution'?
>
> You logically should have started with 'Oh, what's my wireless chipset,
> and what driver does it need'?  If you don't know, that's your _first_
> task, and you start by running lspci (if its internal) or lsusb (if it's
> on USB) to spot the wireless chipset.  Then, you use the Key Skill of
> the Early 21st Century (Web-searching) to find out what driver is
> required for that chipset.  Or, y'know, you could ask a Linux user
> group, such as you could do right here and now.
>
> Armed with knowledge of what the chipset is, you can look at system
> logfiles to see if the kernel tried to modprobe that driver, and what
> happened when it tried, e.g., if it failed to initialise the hardware
> because a proprietary firmware BLOB is required that the distro didn't
> furnish (often because it cannot lawfully do so).
>
> You could remove the driver:
>
> # modprobe -r [drivername]
>
> You could then reload the driver to see what happens (again, looking at
> the logs):
>
> # modprobe [drivername]
>
> You could run iwconfig to see whether the driver is configured.  And
> like that.
>
> Not bothering and instead giving up and switching to a different
> distribution means you have no chance to _really_ evaluate the
> distribution.  You're implicitly judging the distribution by its
> installer, which is like judging a car by its startup sound or a house
> by its front door.  You spend half an hour running through a distro
> installer, and potentially many years running it.  Shouldn't you give
> the distro a chance, by bothering to try to solve initial problems,
> rather than giving up the first time something doesn't work right for
> you?
>
>
>>      pclinuxos-kde-darkstar-2019.0315.iso was slow booting
>> It has the latest kernel but an obsolete version of Libre Office.
>> Falkon is the only browser supplied though it runs the latest
>> kernel 5.0.2.  Darkstar the compiler for this release wanted
>> a small fast downloading system so he used links to get
>> the full versions of the applications he lists.
> Falkon (formerly QupZilla) is a pretty nice lightweight Web browser.  Also,
> again, you spend only a tiny amount of time running the installer and
> then potentially many years running the distribution.  Aren't
> your choice of other Web browsers just one easy package operation away?
> So, why does it matter that you for some reason are dissatisfied with
> Falkon?
>
>> debian-live-9.8.0-amd64-kde was very disappointing
>> with few of the KDE tools I am used to using. Getting on
>> line was impossible for me as Debian is using tools similar
>> to what I saw 10 years ago. You have to know a lot &
>> enter it before you can get it started. I pointed this
>> out to Jim and he asked why they would set it up like
>> that.
> Since obviously you were seeking cutting-edge 'desktop Linux' software,
> why on God's green earth were you trying the Debian 9 'Stretch' Stable
> release?  It seems like you didn't get past Debian 101:
>
> Debian Stable is a release-oriented distro with overwhelming emphasis on
> shipping stable, ergo rather old, versions of the software included.
> The old versions adopted as standard for each release receive backported
> bugfix refreshes only during the distribution's lifetime.  They are
> not replaced by a different upstream version until the next Debian
> Stable release.  (Debian 9 Stretch was a 2017 release.)
>
> For the KDE image of Debian 9 Stretch, one can use the plasma-nm KDE
> widget (a graphical front-end to NetworkManager) to configure wireless.
> https://wiki.debian.org/WiFi/HowToUse#KDE_Plasma
>
> This is a few years old because Debian 9 Stretch is the Debian Stable
> release (that FYI is about to be replaced as Debian 10 Buster finishes
> the release process).  Is plasma-nm a bit antique by bleeding-edge
> desktop Linux standard?  Sure, but you went out of your way (with Debian
> Stable) to be out in the sticks, long miles from the bleeding edge.
>
> As I've said on this mailing list many, many times before, people
> wanting the bleeding edge on Debian can easily get it, by NOT going
> mindlessly for Debian Stable.  Debian has two closely related rolling
> distributions, Debian Testing and Debian Unstable.  Testing gets its
> package repos updated each night by a quarantining / quality control
> script run on maintainer uploads to Debian Unstable.  If you understand
> this, and understand that Testing packages that clear quarantine might
> have dependencies on packages (such as libraries) whose relevant
> versions haven't yet cleared quarantine, Testing can be a good choice.
> (There is an easy way to deal with that problem, but I won't get into it
> here).
>
> _Or_, one can use one of the many Debian derivatives that are based on
> Debian Testing / Debian Unstable, such as one of the Siduction
> live-distro flavours.
>
> Anyhow, good grief, Bobbie.   When you went for Debian 9, 'old versions'
> is pretty much what it said on the tin.  You asked for that, you got it.
>
>
>
>> Aside from that this is one of the most boring
>> looking desktops I have seen.
> Aren't there dozens and dozens of theme packages, each of them one
> package operation away?  I'm not a KDE guy, but that's my recollection.
>
> Again, good grief!  Evaluating distributions by their initial end-state
> at the end of the installer run-through and first boot is unbelievably
> short-sighted.  I like a restaurant that looks nice, too, but I'd be
> mostly interested in the food.
>
>
>
>
>
>> AntiX 17.4 in the 32 bit version would not boot on my
>> machine.
> With what diagnostics?  Did you even look?  Did you try any of the
> debugging options outlined in the antiX FAQ or elsewhere?  Did you
> make sure you used the antiX version appropriate to your machine's
> hardware limitations (e.g., not use the 'full' flavour solely because
> it's the one linked from the DistroWatch coverage, even though it
> won't boot if you have too little RAM)?
>
>
>>      4MLinux 28 in the 32 bit version also hung on my
>> computer.  There is no desktop 64 bi version
> Again, any effort at debugging at all?
>
>>      Jim S. Showed up about 7 PM, had something to eat
>> and read a bit in Linux Pro latest issue.  He is very
>> interest in SCAPY which has something to do with
>> Python but SCA is undefined in the magazine article
>> apparently.
>
>    Scapy is a powerful Python-based interactive packet manipulation
>    program and library.
>
>    It is able to forge or decode packets of a wide number of protocols,
>    send them on the wire, capture them, store or read them using pcap
>    files, match requests and replies, and much more. It is designed to
>    allow fast packet prototyping by using default values that work.
>
>    It can easily handle most classical tasks like scanning, tracerouting,
>    probing, unit tests, attacks or network discovery (it can replace hping,
>    85% of nmap, arpspoof, arp-sk, arping, tcpdump, wireshark, p0f, etc.).
>    It also performs very well at a lot of other specific tasks that most
>    other tools can't handle, like sending invalid frames, injecting your
>    own 802.11 frames, combining techniques (VLAN hopping+ARP cache
>    poisoning, VoIP decoding on WEP protected channel, ...), etc.
>
>    Scapy supports Python 2.7 and Python 3 (3.4 to 3.7). It's intended to be
>    cross platform, and runs on many different platforms (Linux, OSX, *BSD,
>    and Windows).
>
> https://github.com/secdev/scapy

     Bobbie Sellers -  When I reminisce many people say that I am living 
in the
past and I can only agree because the rent is so much cheaper there and my
money goes so much further.

>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linuxmafia.com/pipermail/sf-lug/attachments/20190319/b6bdf603/attachment-0001.html>