CUPS 1.6 shaking up Linux printing

Posted Mar 10, 2012 8:57 UTC (Sat) by marcH (subscriber, #57642)
In reply to: CUPS 1.6 shaking up Linux printing by klevin
Parent article: CUPS 1.6 shaking up Linux printing

I'm sorry avahi does not work for you. For me, it allows zeroconf peer to peer networking using hostnames instead of IP addresses, something proprietary network protocols were achieving more 20 years ago. TCP/IP is really a poor joke in terms of user-friendliness.

And by the way, the concept of "personal firewall" borrowed from Windows does not make any sense. Why are blocked ports opened in the first place?
Let's assume for instance avahi is a security risk that Fedora blocks: then why is it listening to the network it in the first place? This is bordering on stupidity.

Security's worst enemy is useless complexity and "personal firewalls" are exactly that: a failure to keep it simple.

Firewalls are of course useful in some complex network configurations where... "default rules" are very unlikely to make any sense either and where a real network administrator is required.

Coming soon: Linux antiruses.

to post comments

CUPS 1.6 shaking up Linux printing

Posted Mar 10, 2012 13:15 UTC (Sat) by dlang (guest, #313) [Link] (7 responses)

TCP/IP is so horrible that all the 20 year old proprietary networking systems have all been replaced by TCP/IP

auto-discovery has the problem that if any node is mis-configured (either accidentally or deliberately), it can break the entire network.

auto-discovery is great for small environments, but horrible for large ones.

TCP/IP and the rest

Posted Mar 10, 2012 17:44 UTC (Sat) by marcH (subscriber, #57642) [Link]

> TCP/IP is so horrible that all the 20 year old proprietary networking systems have all been replaced by TCP/IP

What a technical and convincing argument. Of course TCP/IP is not horrible; it's horribly not user-friendly.

TCP/IP won because it was NOT proprietary. In networking more than anywhere else interoperability is key (see Metcalfe's law) so, proprietary protocols did not stand a single chance against consensus and text-based RFCs available for free. User-friendless played practically no role in the fight.

> auto-discovery has the problem that if any node is mis-configured (either accidentally or deliberately), it can break the entire network.

There are so many other things just as likely to "break the entire network". Like manual configuration from casual users for instance.

Most alternatives to TCP/IP featured BOTH auto-discovery and centralized configurations. In fact every good and new thing in IPv6 was more or less stolen from something older - and rightly so.

I strongly recommend "Interconnections" by Radia Perlman. It's a fantastic book for anyone interested in Ethernet/IP design choices and comparing them with alternatives. This book gives perspective very difficult to get otherwise since alternatives are dead.

CUPS 1.6 shaking up Linux printing

Posted Mar 10, 2012 19:13 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link] (3 responses)

>auto-discovery has the problem that if any node is mis-configured (either accidentally or deliberately), it can break the entire network.

How? Autodiscovery mechanism generally work by flooding the network with broadcast/multicast updates. A misconfigured node should just be silently ignored.

I assume you're not talking about DHCP/RA.

CUPS 1.6 shaking up Linux printing

Posted Mar 11, 2012 5:01 UTC (Sun) by khim (subscriber, #9252) [Link] (2 responses)

>auto-discovery has the problem that if any node is mis-configured (either accidentally or deliberately), it can break the entire network.

How? Autodiscovery mechanism generally work by flooding the network with broadcast/multicast updates.

Exactly.

A misconfigured node should just be silently ignored.

Only if you disable autodiscovery (how else can you prevent flood organized by misconfigured node from affection configuration of the rest of the network) - but then what's the point of the whole exercise?

I assume you're not talking about DHCP/RA.

Actually DHCP is not any different: if a single node hogs all available IPs from a DHCP pool then other nodes will be unusable.

All autodiscovery mechanisms have this problems - and DHCP is not an exception. It also shows that on practice problems are rare: sure, DHCP autodiscovery may fail too and it even happens from time to time but if you'll consider how ubiquitous it is and how rare are such failures… I think we should not fear autodiscovery mechanisms all that much. 99% of users use [limited] version of autodiscovery with TCP/IP and sky have not fallen so why can't we use somewhat more advanced version and get the convenience offered by proprietary networks 20 years ago?

CUPS 1.6 shaking up Linux printing

Posted Mar 11, 2012 6:24 UTC (Sun) by dlang (guest, #313) [Link] (1 responses)

I don't consider DHCP an autodiscovery mechanism.

That's a server that responds to queries (although very bad things can happen if you end up with unexpected DHCP servers on a network)

Autodiscovery in this context is when everything tries to advertise what services it offers to everything else on the network. In a small network this can work, but in a large network you end up with chaos due to too many things advertising services that you don't care about, and either meaningless auto-generated names, or conflicts between human generated names

CUPS 1.6 shaking up Linux printing

Posted Mar 11, 2012 7:31 UTC (Sun) by khim (subscriber, #9252) [Link]

I don't consider DHCP an autodiscovery mechanism.

Just like I don't consider reference-counting schemes “real GC”, heh. Well, true it's “autodiscovery lite” mechanism: it's more limited and thus more tolerant to problems with clients… but it introduced “single point of failure” so it's also not ideal.

Autodiscovery in this context is when everything tries to advertise what services it offers to everything else on the network.

This is not a requirement. Devices on network can play different games. For example they can choose single master which then arbitrates everything. Of course this implies some level of trust which may or may not be appropriate for real world.

In a small network this can work, but in a large network you end up with chaos due to too many things advertising services that you don't care about, and either meaningless auto-generated names, or conflicts between human generated names

Right, but in large network you probably have a dedicated sysadmin which can setup everything as is needed. But for something like home network autodiscovery may be invaluable.

P.S. Interesting twist in the GC debate: iOS5 added ARC and a lot of guys viewed it as an “incremental step on the road to real GC”, but looks like Apple shares my POV: beginning in OS X v10.8, garbage collection is deprecated (if favor of ARC if I understand correctly).

CUPS 1.6 shaking up Linux printing

Posted Mar 19, 2012 14:33 UTC (Mon) by abacus (guest, #49001) [Link] (1 responses)

auto-discovery has the problem that if any node is mis-configured (either accidentally or deliberately), it can break the entire network.

A buggy client can cause a lot of trouble too. See e.g. Workarounds for "iOS 4.1 - 5.0.1 Allows DHCP Lease to Expire, Keeps Using IP Address" Bug .

CUPS 1.6 shaking up Linux printing

Posted Mar 19, 2012 16:49 UTC (Mon) by dlang (guest, #313) [Link]

in a full autodiscovery environment, every system is both a client and a potential server, that's why I said if any _node_ is misconfigured rather than any _server_