mintCast 232 – Minty Bits

232]

Download

News:

Main Topic: Minty Bits … What Makes Mint Minty?

Website:

  • Mint Developer Centerhttp://developer.linuxmint.com
    • This page is for developers interested in Mint-related projects including Cinnamon and other Mint tools.

Tip:

  •  Configuring the MDM login screen for multiple monitors (segfault.linuxmint.com)
    • A lot of people using multiple monitors ask why their login screen appears on the wrong monitor, why can’t it use all of them, how to change its resolution and why the login screen simply doesn’t follow the configuration they set in Cinnamon, MATE, Xfce or KDE.

Pre-Show Music:

  • Playlist – “Traffic Jam” by Jamhippo  (jamendo.com)

Podcast Announcements:

More Information:

Hosts: Rob, Scott, and Joe
Live Stream every other Sunday 2:00 p.m.(Central): mintcast.org/livestream

Contact Us:

More Linux Mint info: website, blog, forums, community

Credits:

Podcast Entry and exit music provided by Mark Blasco (podcastthemes.com). Podcast bumpers provided by Oscar.


11 Replies to “mintCast 232 – Minty Bits”

  1. A Linux article author

    You may have been to one of my how-to and documenting-the-undocumented pages on one of my websites. Do you know how I can afford to spend all day writing high quality articles for the Linux community? ADS! If you block them, many of the how-tos and help you find when you use Google for a problem disappears when you block ads. The magical microtransaction system Rob mentions doesn’t exist as of yet, so he can’t use that as an excuse to block ads. You would not be willing to shell out money through a mimcrotransaction for one article that solved a very specific problem for you if you found it on some individual’s blog that you’d never heard of again nor might ever visit again. You may unblock a large tech website you’re visiting everyday, but a smaller site that did solve your one hard-to-solve problem wouldn’t be unblocked and wouldn’t make up it’s lost revenue on return visits. It’s hurting the Linux community’s access to information.

    Yes I agree tracking is a big problem. Click on the little info triangle that overlays the ad and write a complaint to the advertisement provider. I many countries around the wolrd, these companies are required to answer costumer inquiries. If tracking suddenly start costing them in terms of support staff cost, then hey: maybe they can do without them.

    Blocking all except one of the ads found on a site is a better approach than just blocking everything all the time. No ad blocker offers this as a setting, however.

    Right now, 62% of my visitors — mostly tech people — block my ads. I’m still paying for food and my bills, but I’d be mad to ever try and create a website for tech (that means Linux!) users ever again.

    • A Linux article author

      You may see it as “battling the advertisers”, but the content creators are the ones who will suffer. Content you stumble upon and appreciate every day is the content that will disappear first.

    • Terry

      I have Verizon wireless and pay for 4G but barely get 3G with a Wilson amplifier. I recently wrote Verizon to complain about download speeds of 339 bits/sec to 8800 bits/sec. At that speed, I’d just as soon avoid anything unnecessary. If I only had cable again! Who’d worry about ads? BTW, I download the podcast at the library.

  2. Tony

    Totally with you Rob on the WAR against advertising. They have gone nuts and it has hurt the internet badly. I have long SHARED on the ‘net de nada, and remain interested feeling of COMMUNITY like that in ham radio, Makers and BBS’s.

    If ads were restricted to dot-COM ONLY, that be fantastic. I’d be willing to view an ad or two … without being tracked … on favorite sites, but in general the Roman approach of PLOWING THEM UNDER seem apropos. Also agree that voluntary micropayments in user-customizable amounts would be a great boon (EG musicians might benefit greatly).

  3. Will

    Maybe I got lucky, but I found setting up my Epson printer/scanner for scanning to be pretty easy. All I had to do was install the “sane” and “simple-scan” packages and then the simple-scan program (maintained by GNOME) just worked. I did this on Arch, but I would think the process would be similar on Mint (maybe this is a good starting point: http://community.linuxmint.com/software/view/simple-scan).

    After I did this, I then tried installing the “iscan” and “iscan-data” packages (still on Arch) and these also just worked. iscan is the program written by Epson and has a few more features than simple-scan. I have found that I still usually use simple-scan because it works more smoothly when I don’t need the extra features.

    My Epson printer/scanner is wireless. I added a line to “/etc/sane.d/net.conf” with the ip address of my scanner and then simple-scan was able to connect to the scanner wirelessly. Adding a line with the ip address to “/etc/sane.d/epwoka.conf” allowed iscan to connect wirelessly as well.

    Hopefully this information can translate in some way to Linux Mint.

  4. Will

    I didn’t realize that LED’s could be used as receivers so efficiently. I still would guess that the LED’s in your monitor could not be used as a camera…. I think the main innovation in the Disney research is in the software related to using this transmission method in toys and other consumer products. Li-Fi technology has been under active research for several years: https://en.wikipedia.org/wiki/Li-Fi

    Regarding the xmodulo link, Rob, I don’t know if you have heard before that “everything is a file” but that is part of what is going on there: https://en.wikipedia.org/wiki/Everything_is_a_file

    I haven’t read much about the details of Snappy, but on a recent Linux Unplugged episode, Popey made it sound like we won’t be using a Snappy desktop any time soon. Snappy images are going to be produced in a way that is kind of like taking a snapshot of a deb-based system, so there will continue to be a deb-based version of Ubuntu. For systems where it makes sense (things with a well defined and limited usage pattern like small appliances and probably phones), Snappy will be used, but for day to day work on a personal desktop a deb-based system will probably continue to make more system for the time being.

  5. Will

    I think Isaac has already made similar suggestions, but I would recommend only posting the live stream information in one place and have the other places link to that place. What is the point of mentioning every show that you might or might not be able to get accurate information at a certain web site? Similarly, why mention the Freenode IRC channel every time just to point out how no one is there?

  6. swift110

    Again good show guys. I know it’s been a while since I have posted on here but I do listen to every single podcast ironically on my iPad. I wanted to hear what you guys thought of this post I wrote a while back about mate’. https://anthonyvenable110.wordpress.com/2015/06/20/the-desktop-formerly-known-as-gnome2-2/ For someywat reason a song came to mind so I just went with it. In case you were curious about it its “children’s story” by Slick Rick 1988. One thing I have noticed while listening to the show is that there is that I don’t normally see people in the freenode irc channel even while the live show is on.

  7. Michael

    As it happens, I did catch the latest podcast, Rob! Though I really don’t know nearly as much as you give me credit for; I just remember what I read. Joe’s skepticism inspired me to do a small experiment, the results of which I will share here. I downloaded the Mint 17.2 KDE 32-bit iso (it was KDE he was complaining about wasn’t it?) and used it in a virtual machine where I could control the RAM. I installed it to a virtual disk and then did a number of unscientific tests using your favorite free command. For each configuration, I just did a cold boot and logged in, with no other apps running, as it seems to me Joe complained about KDE sitting at 1 GB used just when the desktop itself running. So here’s the results for different RAM configurations from the free command (didn’t show the cached or buffer numbers):

    2048 MB: 1418820 KB used, 649232 Free 0 swap used
    1024 MB: 798272 KB used, 229396 Free 0 swap used
    512 MB: 414268 KB used, 93652 Free, 28640 swap used.

    At 512 MB of ram, the KDE desktop itself basically runs just fine. In fact I’d say it’s rather lightweight, although 512 MB looks to be the minimal number (more on this below). Applications like Firefox or LibreOffice are a very different story. I haven’t tested Mate or XFCE yet, but I imagine they are pretty comparable in what free will report. And as we can see, the results of “free” are pretty meaningless when trying to measure how heavy or light a desktop environment is.

    When there’s plenty of RAM the OS is going to be less aggressive in swapping, and it’s going to load more memory-mapped files into memory, rather than page fault. Since there’re a lot of libraries involved in KDE, if you have 8 GB of RAM it’s likely going to load them all into RAM so programs can run without page faults which will slow things down and add I/O wait time. When less RAM is available the kernel is going to push more pages out of RAM. In some cases, we’re talking about pushing things to swap. But also the kernel is likely to push out memory-mapped files, such as shared libraries.

    In fact, I’d say a good chunk of the memory KDE uses is in the form of shared libraries, and those can be pushed out of RAM when not needed, at some penalty of overall performance when they are needed. It’s this factor that makes using the free command unreliable as an indicator of the level of bloat.

    When RAM is tight, the kernel tries really hard to identify the “working set” of memory pages (read-only or read-write) for your running processes, and keeps those in RAM, while pushing other pages out. In fact I could see this in action when I just let my virtual machine sit idle for a few hours. Over time the kernel pushed a lot of pages out of memory, some of that into the swap file. Eventually I got to about 300 MB used, and about 200 MB in swap being used. If I interact with the system a bit, it swaps things back in, and the used memory goes back to around 400 MB as page faults bring these pages back into physical RAM.

    So really the only way to judge how light or heavy a system is is to monitor performance as you decrease the RAM. When you get to the point where disk I/O is starting to impact performance from all the swapping and reloading of shared libraries, then you know you’re at your limit. And 512 MB seems to be the lower limit for KDE 4 as shipped with Linux Mint 17.2.

    TLDR version: KDE 4 runs alright at 512 MB of RAM, but you can’t really use heavy applications, though Firefox actually does run more or less. At 1 GB it looks like KDE runs great even with applications running, and would be about as fast as any desktop out there, including XFCE on the same hardware.

    • Michael

      Looks like I didn’t get the explanation right. So Joe is more right than I gave him credit for. Shared libraries are not counted in the “used” column of free, but rather the “cache” column, which makes sense. They are shared after all. See:
      http://duartes.org/gustavo/blog/post/page-cache-the-affair-between-memory-and-files/

      It’s clear, though, that the amount of RAM KDE uses certainly depends on how much is available.

      In any event, if you are working in a memory-constrained environment such as a Raspberry Pi or even a Chromebook, if you stick with applications that share a common set of libraries, say Qt apps on KDE, or GTK apps on xfce, then things can perform better. If you mix and match applications the kernel has to load them into memory (the page cache) for applications to use, and if memory is tight, the kernel will have to throw out pages from the cache, and then reload them later when needed, and that can lead to I/O wait bogging things down (load average will go up).

Leave a Reply to A Linux article author Cancel reply

Your email address will not be published. Required fields are marked *

Linux Mint

The distribution that spawned a podcast. Support us by supporting them. Donate here.

Archive.org

We currently host our podcast at archive.org. Support us by supporting them. Donate here.

Audacity

They’ve made post-production of our podcast possible. Support us by supporting them. Contribute here.

mintCast on the Web

Episode Archives

This work is licensed under CC BY-SA 4.0

This Website Is Hosted On:

Thank You for Visiting