From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 14F601396D0 for ; Mon, 4 Sep 2017 20:56:02 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 97CC1E0D6F; Mon, 4 Sep 2017 20:55:57 +0000 (UTC) Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 42CA7E0C75 for ; Mon, 4 Sep 2017 20:55:57 +0000 (UTC) Received: by mail-qt0-x229.google.com with SMTP id k2so5813853qte.2 for ; Mon, 04 Sep 2017 13:55:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=spYA+H+Pc1U6XJIwo2XBhowNhFe+KgcZNoh1ljm9ISk=; b=G1DS6FfkjHA8fPfxP5IsR5tA6G+hTc9zGh2vNAHeE6Y6e0fZTtsTLGmyP3vfNoEKM7 3kqbjfm+RqWwidSCVat/JtMaA9LVX/j5O5h4z/sehce4VPIcqHm1/bMjIHAYPJgkqzho GqhL0Q9jyaiR+XW1yMJO6eHgY8X40kyIysiiwyDidVIqj2WBXbnYIb+d3SeP6pBrTBRq 4w+9ncKPuaqM/AH6aVRc+9VnHqKAFL4TT7IxoXeQI2vfCIblfAcI+Lvlrps3kDAM6PTZ VJaiCy3XBLeIdjSvFGjBbzqZanrNzrSzFa3osQH5bd3c8SrtbvgjBt5ye1UvDJ2pqJ/2 v5wA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=spYA+H+Pc1U6XJIwo2XBhowNhFe+KgcZNoh1ljm9ISk=; b=MGMtUA3sTLmLT02VHhupBromCmdt53PnNhty6k0pigXH9n4O+KSEotXbg1LywgBI1Z mDbUBelGVsHGLgmSP4PLa6tgQwJmsh8EcRcnFz1DK4UmtnNhZB0dU2LVOQzaJGA7fsTy KYtsF4ZK1axSbZy+8TDeJEmG/BxVdnz2qsLUJ6E1WRx+UBVU6FcnqZ1zkYteGKiUUIpH XwEZHDJ/8VPRDtNDgqbWHlahVsJuDAC6qWswP4aPjZ4jVAWZVHliXFkujjDqg8WqmbS4 GDgQSvMsmklM54uqbKtG+hF+AsQKjJc6kllaA3xOJvhkkkff5bC1tCmtZ6I3alHbgY8x d7VQ== X-Gm-Message-State: AHPjjUgMNXPSKJ4Xc5rSwBxgYhSN3sjScTdVht/G+KV99EnGy/uNUGLE u17Vc2xFhx4Wzf/JFPftC9Wn/SdA/Q== X-Google-Smtp-Source: ADKCNb7INzNQ4HWjwVjzgvxGdhHwlQ4P/VGI1AbOW8KniBh7pkKtqWdrSYKTamtYQVAg5Jpo0pv5eZt80Vrabv3+yxo= X-Received: by 10.237.60.1 with SMTP id t1mr2311651qte.246.1504558556451; Mon, 04 Sep 2017 13:55:56 -0700 (PDT) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 Received: by 10.140.20.98 with HTTP; Mon, 4 Sep 2017 13:55:55 -0700 (PDT) In-Reply-To: <17e2d911-7f53-f7c9-4392-7b33d9b422ae@gmail.com> References: <17e2d911-7f53-f7c9-4392-7b33d9b422ae@gmail.com> From: Grant Date: Mon, 4 Sep 2017 13:55:55 -0700 Message-ID: Subject: Re: [gentoo-user] Re: Lowest common denominator compile To: Gentoo mailing list Content-Type: text/plain; charset="UTF-8" X-Archives-Salt: 474eb751-24cd-4f11-8647-965425658b65 X-Archives-Hash: 96bca027af019d45414f058bf2aab45e >>> I have a network of very nearly identical Dell XPS 13 laptops that I >>> manage with a script. The master pushes the contents of its >>> filesystem to the others so I only have to manage one system. It's >>> worked really well over several years. I just got a new Dell XPS 13 >>> to serve as the master and there have been some changes that were >>> difficult to integrate with the network (high-res screen, /dev/sda >>> replaced with /dev/nvme0n0) but those problems are fixed thanks to you >>> guys. >>> >>> Now I'm running into "trap invalid opcode" errors on the older >>> systems. Can I disable some of the newer CPU instruction sets on the >>> master laptop when compiling to hopefully generate binaries that will >>> work on the older systems? If so, could anyone point me in the right >>> direction? I don't want to use distcc please. >>> >>> CHOST="x86_64-pc-linux-gnu" >>> CFLAGS="-march=native -O2 -pipe -fomit-frame-pointer" >> >> >> Switching to -mtune=native seems to work. Time for an emerge -e world. > > Also time for ansible. Why you managing a fleet of machines with a > script that won't actually differentiate properly between machines? It > will sorts mostly do it right, except when you forget something. Well I designed it around the principle that I would have the luxury of using sufficiently identical hardware across each system so that it wouldn't need to differentiate. It's simple, it's one file. I just execute the file with certain parameters based on whether I'm cloning the running system to a USB stick, cloning the running USB stick to its host system, pushing the master system to another system, or updating the running system based on the last push to it. Worked great until the latest iteration of XPS 13. Even now the only hardware differentiation it needs to make is /dev/sda or /dev/nvme0n1. DisplaySize in xorg.conf and -mtune=native in make.conf are sufficient to handle different screen resolutions and CPUs. > This is exactly the use-case ansible was designed for: declarative, > idempotent, predictable management of a fleet of machines that may or > may not be around when you feel like updating something (so it catches > up later), and needs only sshd and python to do it's magic :-) ansible does sound pretty cool. I'll check it out if I outgrow my script but as long as I can keep using Dell XPS 13 laptops I don't think it will have any trouble scaling. - Grant