• 9 Posts
  • 39 Comments
Joined 11 months ago
cake
Cake day: August 8th, 2023

help-circle
rss





  • As with all definitions, there is a gray area where people will have different boundaries on exact meanings. To you - a supplier relationship needs an explicit payment, which is a fair definition.

    However, the more widely used definition that most people, including me, refer to, is not necessarily focused on the supplier, but on the supply - what we use in our toolchains is a supply - regardless of how it was obtained.

    When there is an issue in a trusted supply, even if it was not a commercial relationship (a prerequisite by your definition), it is a supply-chain attack by the more widely used definition.


  • The article states reasons which aren’t limited to what happened. I understand and agree with your sentiment about the supply chain issue being something that could happen anywhere - those were my initial thoughts too.

    The reasons for shifting are related to speed, other mainstream software already having made that switch years ago (pre incident), and unfortunately… More robustness in terms of maintainers.

    Open source funding and resilience should be mainstream discussions. Open source verification and security reliability should be mainstream discussions: here’s a recent mastodon thread I found interesting:

    https://ruby.social/@getajobmike/112202543680959859

    However, people switching from x to z (I did see what you did there) is something that is going to happen considering the other factors listed in the article that I summarized above.


  • Linux mint Debian edition or Opensuse tumbleweed.

    Slow Internet/less updates, older, more tested software, slightly wider package availability: LMDE.

    Faster Internet, more updates, very new (but well tested) software, needs slightly more technical knowledge sometimes: Opensuse tumbleweed.

    I personally use Opensuse Slowroll, which is a slower rolling release experimental version of Opensuse tumbleweed.












  • It is certainly useful for some use cases such as network print servers (I have a dedicated lxc container on the network to do this) and custom conversions of pages (during my digging, I learned about companies using a CUPS network printer to watermark every document being printed).

    I'm not an expert by any means: it is definitely a useful tool in certain cases, but oh man… the documentation was a bit hard to figure out for me!


  • Mission Accomplished! My printer driver now has a MirrorPrint Option, and selecting it enables Mirror Printing. For convenience (since I don't see a client side option to flip mirror printing), I have a doppleganger of my regular printer, and I named it MirrorTest - screenshot below. When I need a mirror print, I just send it to the mirror printer.

    Actual Changes

    Here's the relevant excerpt (added) in /etc/cups/ppd/MirrorTest.ppd (I added this UI option right below the Toner option). Excerpt adds a MirrorPrint Toggle (boolean) to the printer defaults setup. When enabled - the printer will print in mirror mode.

    *%=== Mirror Printing ================================
    *OpenGroup: General
    *OpenUI *MirrorPrint/Mirror Print: Boolean
    *OrderDependency: 110 AnySetup *MirrorPrint
    *DefaultMirrorPrint: True
    *MirrorPrint True/MirrorPrint: "<>setpagedevice"
    *MirrorPrint False/Normal: ""
    *CloseUI: *MirrorPrint
    

    For further convenience (making sure that a new printer installation didn't mess up my custom changes, I also updated the relevant ppd file in /usr/share/cups/model/. Whenever you add a new printer - CUPS will use the corresponding model ppd as a base, and it will apply any settings changes from configuring default to the copied ppd file in /etc/cups/ppd/your_printer.ppd.

    Hope this helps if someone else is also looking to do something similar!