2021-05-19 17:13 from Nurb432
Except HP :) They dropped support for OSX on this printer, and
stopped updating the Linux driver install er so me moving beyond
Debian v9 blew that too. My first go around was just to install
their drivers like i did before. but nope. So i went went 'generic'
CUPS and saw that. But as long as CUPS keeps working i'm ok. just
that message i saw lead me to believe i was screwed here in the near
future.
I dont print often, mostly mailing labels and perhaps a sewing
template or a recipe, but its nice to be able to do it when i want
and not have to buy a new printer when mine works just fine.
its all about having to download firmware to the printer every time
you print. Stupid design. Stupid idea. Should have been illegal.
I used to be a fan of HP printers, but not anymore. This is one of the reasons.
HP is in a blacklist in office for new purchases at the time of this writting. When an HP printer falls appart we buy something else.
2021-05-19 19:42 from Nurb432
Right. just mine ( and a few other old 'windows centeric' ones too im
sure )Wed May 19 2021 07:20:11 PM EDT from ParanoidDelusions
Oh. For your printer.
Thenn there is the fact you used to be able to print using hplip and only FOSS components and nowadays they want you tom use their plugin engine (which is proprietary), yet they cannot get their certificates right so the plugins are delivered to you unauthenticated.
Ya, my next wont be an HP. After several over the decades.
Used to be one of the best, now they are evil crap.
Oh, and i dont blame them for dropping support on a 20 year old printer, i dont expect support forever.. But if they didnt do all that firmware crap, they wouldn't have to. just support PCL, or Postscript ( showing my age there ) or some other more modern standard and be done.
Ah, I see, the 1018 isn't a "real" HP printer, as in it doesn't use any normal HP technology and does not speak PCL. It is a "Zenographics" printer with its own language.
This particular bastardization of printing appears to be supported by the "foo2zjs" project [ https://github.com/koenkooi/foo2zjs ]. Since foo2zjs gets included along with CUPS in your typical Linux distribution, this probably means that Linux will support that printer for much longer than Windows or Mac.
Pretty sure that is the driver set i used. ( i forget now, i just installed 'stuff' and it worked. didnt pay much attention since its all pretty routine, once i found the HP driver would not compile anymore due to my OS version change )
Fri May 21 2021 11:34:37 AM EDT from IGnatius T FoobarAh, I see, the 1018 isn't a "real" HP printer, as in it doesn't use any normal HP technology and does not speak PCL. It is a "Zenographics" printer with its own language.
This particular bastardization of printing appears to be supported by the "foo2zjs" project [ https://github.com/koenkooi/foo2zjs ]. Since foo2zjs gets included along with CUPS in your typical Linux distribution, this probably means that Linux will support that printer for much longer than Windows or Mac.
Wow. That is amazing. I'm going to ask about ALL of my old, obscure, unsupported hardware here on Uncensored before I throw it away.
Not being sarcastic - this was excellent info.
Fri May 21 2021 11:34:37 EDT from IGnatius T FoobarAh, I see, the 1018 isn't a "real" HP printer, as in it doesn't use any normal HP technology and does not speak PCL. It is a "Zenographics" printer with its own language.
This particular bastardization of printing appears to be supported by the "foo2zjs" project [ https://github.com/koenkooi/foo2zjs ]. Since foo2zjs gets included along with CUPS in your typical Linux distribution, this probably means that Linux will support that printer for much longer than Windows or Mac.
Office network wend down last night after losing a couple of sites due to weather, this was the reason:
To a vendor, you only allow specific IPs and specific ports. Running it wide open like that is a HUGE risk. You start with zero trust and work from there.
Mon Jul 19 2021 11:49:11 AM EDT from LoanShark
Then what's the point of creating a VPN link to your cloud host if you can't route traffic over it?
2021-07-19 12:01 from Nurb432
To a vendor, you only allow specific IPs and specific ports.
Running it wide open like that is a HUGE risk. You start with zero
trust and work from there.
Yeah, OK, I can see that. Just accepting whatever your vendor, under *their* control, advertises, like 10.0.0.0/8, could be bad.
But there is a middle ground: specific CIDRs that you define. Amazon VPC gateways fit this model; you define a CIDR for each of your subnets. There should be nothing in there that's defined by the vendor.
Among other things, address allocations for individual machines are so dynamic these days that publishing routes at such a fine-grained level can be prohibitive in certain environments.
If you have dynamic addresses on servers, you are doing it wrong ( at least in my book ).
Mon Jul 19 2021 03:06:16 PM EDT from LoanShark
Among other things, address allocations for individual machines are so dynamic these days that publishing routes at such a fine-grained level can be prohibitive in certain environments.
2021-07-19 15:13 from Nurb432
If you have dynamic addresses on servers, you are doing it wrong ( at
least in my book ).
That's just the way it is, in the cloud, it's unavoidable.
My vendor, which uses AWS can pin their IP. Load balancers for web servers, the web servers themselves, and SQL.
So i disagree its unavoidable. Just demand it, and you get it.
Mon Jul 19 2021 06:19:22 PM EDT from LoanShark2021-07-19 15:13 from Nurb432
If you have dynamic addresses on servers, you are doing it wrong ( at
least in my book ).
That's just the way it is, in the cloud, it's unavoidable.
2021-07-19 18:57 from Nurb432
My vendor, which uses AWS can pin their IP. Load balancers for web
servers, the web servers themselves, and SQL.
So i disagree its unavoidable. Just demand it, and you get it.
It can be done in principle. You can configure an explicit IP before instance launch, for example.
But this isn't everything. Insisting on static IPs for everything would rule out whole parts of the AWS technology stack, for example you would never be able to use the `awsvpc` network mode on ECS.
And there's a lot of dynamic/automated stuff that's considered best-practice these days which would not be able to do.
In our cases its specific 'apps' these people provide, so locking them down is the best way to go.
If they need to be wide open, then it happens via internet, not via VPN. For us VPN is meant to be for restrictive, secure stuff. So we lock it to IPs and ports. ( sometimes IP ranges.. but that would have prevented this mess the weekend too ).
We dont use the vendors DNS ( another security risk ) so going by name isn't an option really. Sure we can setup records in ours, but if it was going to change often, not going to add that overhead to us. And i am not even sure if our firewalls can do DNS in this case, and needs IP ( donno, i could be wrong, its not my gig. its cisco gear ).
Mon Jul 19 2021 09:01:52 PM EDT from LoanShark2021-07-19 18:57 from Nurb432
My vendor, which uses AWS can pin their IP. Load balancers for web
servers, the web servers themselves, and SQL.
So i disagree its unavoidable. Just demand it, and you get it.
It can be done in principle. You can configure an explicit IP before instance launch, for example.
But this isn't everything. Insisting on static IPs for everything would rule out whole parts of the AWS technology stack, for example you would never be able to use the `awsvpc` network mode on ECS.
And there's a lot of dynamic/automated stuff that's considered best-practice these days which would not be able to do.