Re: Printer driver for Samsung CLP-415-NW on SL7

[Matt Lewandowsky]

As the Samsung CLP series are not PCL or Postscript, you need more than just a 
PPD. 

There are really three choices:

1: Samsung model specific driver.

2: Samsung Universal Print Driver (UPD). 

3: Open source foo2qpdl driver. 

The first option is generally best, especially if your printer has a unique 
feature of some sort that you use often as the UPD will quite usually hide the 
unique options in a layer of UI. This is not an option for many models, 
especially running Linux. 

The UPD is especially great if you are printing to multiple Samsung printers. 
‎It almost always is updated more often than a model-specific driver, and that 
is the case on all supported platforms (not just Linux). It is also a better 
choice if you will be installing on a shared system where the users are 
familiar with the UPD on Windows as most of their knowledge maps cross-platform 
with this driver. 

As for the open source option… I understand foo2qpdl gives awesome output, 
especially for open source. Unfortunately, the author is actively hostile to 
packaging his drivers. As I am not a fan of leaving unpackaged files outside 
/home (ok, and maybe /etc and /opt and /var… you got me…), that makes this an 
option that is personally unpalatable. This is unfortunate, as he is 
effectively turning away patches and other development assistance. But everyone 
has their own needs and desires and approaches in open source. The foo2qpdl 
home page is at ‎http://foo2qpdl.rkkda.com/ for those who have fewer qualms 
than I do about unpackaged files and/or have a stronger need or desire to use 
an open source answer. 

I realize that this is far more than you likely hoped (or cared to receive) as 
an answer. But I am hopeful that future archive searchers will find this reply 
and that it will still be relevant. :)

Matt

-- 
Matt Lewandowsky
Big Geek
Greenviolet
m...@greenviolet.net http://www.greenviolet.net
+1 415 578 5782 (US) +44 844 484 8254 (UK)
Sent from my BlackBerry 10 smartphone.
From: Karel Lang AFD
Sent: Friday, 14 November 2014 01:49
To: Bill Maidment; SCIENTIFIC-LINUX-USERS@FNAL.GOV
Subject: Re: Printer driver for Samsung CLP-415-NW on SL7

Hi Bill,
did you just try to copy the ppd file you're using on the 6 to 7 and 
test result?

cheers,
-- 
*Karel Lang*
*Unix/Linux Administration*
l...@afd.cz | +420 731 13 40 40
AUFEER DESIGN, s.r.o. | www.aufeerdesign.cz

On 11/14/2014 05:10 AM, Bill Maidment wrote:
 Hi
 I have been using a Samsung colour printer CLP-415-NW on SL6 using the 
 recommended CLP-310 series driver with good results.
 On SL7, the driver recommended (the only one shown) is CLP-410 series, but 
 this only prints in black and white.
 Has anyone found a colour version that will work on SL7?

 Regards
 Bill Maidment
 Landline: +61 2 4472 9374
 Mobile: +61 418 682 993
 Web: www.maidment.me




smime.p7s
Description: S/MIME cryptographic signature

RE: RHEL 7 just hit the market place, I'm looking forward to when we can start testing SL 7

[Matt Lewandowsky]

Tom H, Sent: Wednesday, 11 June, 2014 01:33:
 AFAIC this pure FUD.

 In what way is the CentOS git less secure than other upstream git repos?

 Do you have an example of files being dumped into the CentOS git by
 non-CentOS uploaders? I've look at a few packages and I see
 kbsi...@karan.org (he's one of the main CentOS guys) and
 b...@centos.org.

The problem, as I see it, is that the b...@centos.org commits come from a 
magic place that no one is sure of where it is. The commits are not GPG 
signed, nor are they at all verifiable as originating with Red Hat.

We're getting a bit off-topic for this list, but I see the following as a 
solution to clarifying the current situation as I understand the reality to 
be:

1) Have the commits come from a Red Hat email address (since they're 
supposedly being pushed to the repo from Red Hat) as the committer.

2) Have the commits be GPG signed, with a way to verifiably trust the 
signature.

3) Ensure git.centos.org is able to show signing information.

This will result in a verifiable chain of the sources originating at Red Hat, 
and being reasonably sure of lack of tampering. However, it does add some risk 
to Red Hat as there is a degree of them certifying correctness. The don't 
trust view is that *someone* needs to be able to put their name behind it as 
opposed to a faceless committer claiming to be the bug tracker.

Personally, I don't care if kbsi...@karan.org commits are signed if he doesn't 
want them to be and I suspect almost every party interested in this 
conversation would agree. It's his personal name on the line. The problem is 
the generic bug tracker address committing huge swaths of code of unknown 
provenance.

Again, this is just my view of the situation. I'm not trying to say whether 
trust or don't trust is the correct answer. But I see both sides and I 
want to help everyone also see both sides so they can be informed in their 
replies instead of this rapidly degenerating into a mess of useless 
speculation which can't be reconciled due to lack of facts.

Matt

-- 
Matt Lewandowsky
Big Geek
Greenviolet
m...@greenviolet.net http://www.greenviolet.net
+1 415 578 5782 (US) +44 844 484 8254 (UK)


smime.p7s
Description: S/MIME cryptographic signature