From owner-freebsd-current@FreeBSD.ORG Mon Oct 28 16:49:24 2013 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id EA749741; Mon, 28 Oct 2013 16:49:24 +0000 (UTC) (envelope-from drosih@rpi.edu) Received: from smtp10.server.rpi.edu (smtp10.server.rpi.edu [128.113.2.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8A0EA2C79; Mon, 28 Oct 2013 16:49:24 +0000 (UTC) Received: from smtp-auth1.server.rpi.edu (smtp-auth1.server.rpi.edu [128.113.2.231]) by smtp10.server.rpi.edu (8.14.3/8.14.3/Debian-9.4) with ESMTP id r9SGmlQQ008874; Mon, 28 Oct 2013 12:48:48 -0400 Message-Id: <201310281648.r9SGmlQQ008874@smtp10.server.rpi.edu> Received: from smtp-auth1.server.rpi.edu (localhost [127.0.0.1]) by smtp-auth1.server.rpi.edu (Postfix) with ESMTP id D2A2158087; Mon, 28 Oct 2013 12:48:47 -0400 (EDT) Received: from localhost.localdomain (webmail1.server.rpi.edu [128.113.2.169]) by smtp-auth1.server.rpi.edu (Postfix) with ESMTP id ADCB858005; Mon, 28 Oct 2013 12:48:47 -0400 (EDT) Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: binary X-Originating-Ip: 128.113.124.121 X-Http_host: webmail.rpi.edu Date: Mon, 28 Oct 2013 12:49:14 -0400 MIME-Version: 1.0 Subject: Re: [heads up] axing AppleTalk and IPX/SPX X-Mailer: EMUmail 6.0.1.32 From: drosih@rpi.edu X-Browser: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_8) AppleWebKit/534. 59.8 (KHTML, like Gecko) Version/5.1.9 Safari/534.59.8 X-Webmail-User: drosih@mail.rpi.edu To: julian@freebsd.org, glebius@FreeBSD.org X-Virus-Scanned: ClamAV using ClamSMTP X-Bayes-Prob: 0.0001 (Score 0, tokens from: outgoing, @@RPTN) X-Spam-Score: 0.00 () [Hold at 15.00] MSGID_FROM_MTA_HEADER:0.001, T_RP_MATCHES_RCVD:-0.01, SPF(none:0) X-CanIt-Incident-Id: 03KGEMMSS X-CanIt-Geo: ip=128.113.2.169; country=US; region=NY; city=Troy; postalcode=12180; latitude=42.7495; longitude=-73.5951; metrocode=532; areacode=518; http://maps.google.com/maps?q=42.7495,-73.5951&z=6 X-CanItPRO-Stream: outgoing X-Canit-Stats-ID: Bayes signature not available X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.113.2.230 Cc: stable@FreeBSD.org, current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: drosih@rpi.edu List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2013 16:49:25 -0000 On Mon, 28 Oct 2013 11:28:07 EDT Julian Elischer wrote: > > On 10/28/13 8:42 PM, Gleb Smirnoff wrote: > > > > The plan is two axe two old networking protocols from FreeBSD head/, > > meaning that FreeBSD 11.0-RELEASE (available in couple of years) would > > be shipped without them. > > > > 1) AppleTalk > > > > Last time claimed to be supported by vendor in 2007[1]. In > > practice had very little use since 90th. > > Discontinued by major routing equipment vendors since 2009[2]. > > I did a lot of work on this to get it going in the 90s but > really it's only current value is as an example of a non-IP protocol. > > (and the same for IPX, which was what Novell used to use I believe.) > I'd be pretty amazed to discover anyone still used either. FWIW, we still use Appletalk for a lot of printing at RPI, although we're not using the system-level Appletalk in FreeBSD. I've got my own heavily customized version of the old CAP (Columbia Appletalk Package). We use it only for printing, not for file-sharing. I can certainly confirm that very few printers support Appletalk, so obviously we (at RPI) are in for a world of hurt at some point in the future. But we've also cut back so much on systems-programmers and sysadmin's that we haven't had the manpower to work on alternatives. I suspect this will end badly. I notice that CAP was removed from the ports collection some time ago, and that there didn't seem to be any objections to that. So that's some more indication that appletalk isn't seeing much use. As far as the kernel-level support, I assume you're just removing all the code tied to the kernel options NETATALK and NETATALKDEBUG? Or does it entail some other changes, which might wreck my custom compile of CAP? -- Garance Alistair Drosehn = drosehn@rpi.edu Senior Systems Programmer or gad@FreeBSD.org Rensselaer Polytechnic Institute; Troy, NY; USA