mintCast 231 – CUPS and Linux Printing

Download

News:

Main Topic: CUPS and Linux Printing

Website:

Tip:

  • When you have a terminal open, and you can’t actually read the text because it’s too small and you’re old and have bad eyes, you can quickly make the terminal window (and the text) bigger by pressing <ctrl>+. Of course, <ctrl>- makes it smaller as well, and <ctrl>0 resets it to “normal” size. Of course, these keystrokes work for quite a few windows!
  • Some really interesting and useful bash aliases and functions are here:

Pre-Show Music:

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.

Advertisements

5 thoughts on “mintCast 231 – CUPS and Linux Printing

  1. I was listening to this episode on my drive in to work this morning (I work with Rick Schulte who turned me on to your podcast) and realized I hadn’t added noatime to the fstab entries for my SSD. As a result I searched for other tips and tricks and ran across some advice relating to fstrim that made sense. For systems, such as servers, that are on all the time using cron.weekly isn’t a bad idea. For other systems, such as desktops and laptops, that are rebooted on a fairly regular basis you can add the fstrim to rc.local and have it trim on reboot. While I haven’t tested this yet it seems to be a reasonable option. I have been trying to my system to boot as fast as possible so until I hit the fastest possible boot time I’m not adding anything to it. I’d be interested in hearing your opinions on tuning boot times, I currently have mine around 21.76 seconds including typing a fairly long password for the LUKS encryption. I don’t know what my target is but it’s a fun quest. Thanks for the podcast and maybe one day I can buy you a beer since you’re also in the greater Houston area!

    • It was probably okay that you didn’t have noatime in your mount options. From what I’ve read, for some time now, the kernel has defaulted to “relatime” when mounting file systems. relatime is a good compromise between atime and noatime options. It keeps some programs happy that rely on atime behavior while minimizing writes to almost noatime levels. relatime only updates the atime of a file if its modification time is newer than the last atime when a file is accessed. This keeps programs like the mutt email reader happy (mutt uses atime to tell if you’ve got new messages that you haven’t read yet), although I doubt most Mint users use mutt with a local mail spool file!

      So in reality, specifying noatime actually isn’t saving very many write cycles vs using relatime.

      • That is good to know! It’s always interesting to see the different takes on how to optimize one’s system overall especially with SSDs right now. I recently saw an article arguing against the use of SSDs that was fairly interesting. While I am a sysadmin for a living things like tuning for SSDs and such not things I get to do on a regular basis.

  2. I didn’t understand what Scott wanted Canonical to do regarding declaring itself a business versus working for the community. I don’t think that Canonical has hid the fact that it is business searching for a way to make money by promoting forms of Linux. I think they have made it fairly clear that their focus is on mobile, IoT and the cloud because there is the potential to make money off phones and IoT and they do make money off cloud. I don’t think they make much off the desktop and I don’t see much potential for them to make much more money there. I think they mainly see the desktop as marketing (especially to developers) for the other use cases. Users are fortunate that development for cloud, IoT and mobile can translate into useful tools for the desktop as well (if things like Unity, Mir, Snappy ever turn out to be good) (really this has true about Linux as a whole as well; it’s installed much more in embedded devices, servers, and phones than it is in desktops, though Chromebooks are changing that). Asking Canonical to devote more resources to the desktop is, I think, like asking them to make Joe’s prediction come true.

Comments are closed.