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 2F6C7138350 for ; Sun, 26 Apr 2020 14:23:20 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 6AD39E0A88; Sun, 26 Apr 2020 14:23:14 +0000 (UTC) Received: from mail-40138.protonmail.ch (mail-40138.protonmail.ch [185.70.40.138]) (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 EC2A4E09F9 for ; Sun, 26 Apr 2020 14:23:13 +0000 (UTC) Date: Sun, 26 Apr 2020 14:23:01 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1587910991; bh=8rcJiBTr1yfPutUH6rY3n+/75RBN7gnO1PQsIK2ltYA=; h=Date:To:From:Reply-To:Subject:In-Reply-To:References:From; b=Fe4XkillAgjD/vENIHwvrtVY6RzehpEFJAU+nApUhzLOM0yOB1Xm1goWK4tul5Yg+ /IHBoaZPH5e3f+dclHb7yLPTl3YOajzIJ/WKH/uq8Swhfycs8lRGt9/8Cxdep5kTtP LKH0RVTaYuckWmGOnrHbWvpqkc8oPO7wTzm3Y0o4= To: "gentoo-user@lists.gentoo.org" From: Caveman Al Toraboran Subject: Re: [gentoo-user] Is Gentoo dead? Message-ID: In-Reply-To: References: <20200421165803.GB187193@redacted> <11506562.O9o76ZdvQC@peak> <20200421190145.GF187193@redacted> <0d270fdf-1de2-03b4-1f5a-702450975561@gmail.com> <2b6a7f82-b4c2-2115-e4e5-2ec27482a4c9@gentoo.org> 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 X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.2 required=7.0 tests=ALL_TRUSTED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM shortcircuit=no autolearn=disabled version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on mail.protonmail.ch X-Archives-Salt: 4409241c-3ef9-4b8f-b195-bb9b3b61458d X-Archives-Hash: a2269d5326c91d5f247fe68166d120da On Saturday, April 25, 2020 1:23 AM, Michael Orlitzky wrot= e: > It's not outwardly a traveling salesman problem, but it's on the same > level of difficulty. If you look at RDEPEND in an ebuild, you'll see a > bunch of entries like > > cat/pkg <=3D version > > As the package manager recursively processes all of the ebuilds in the > dependency graph, you wind up with a goal like > > maximize the versions of all installed packages > subject to > cat/pkg1 <=3D version1 > cat/pkg1 > version2 > > cat/pkg2 >=3D version3 > > ... > > > That looks a lot like a linear programming problem, but package versions > are discrete. So ignoring all of the details, it's believable that we > have an integer programming problem, which is NP-complete. i'm dumb, and don't fully understand this, but i think i found something interesting: [1] http://www.aimsciences.org/article/doi/10.3934/jimo.2014.10.557 i wonder, can gradient descent be used to find optimal portage solution? didn't read beyond the abstract in [1], but from the abstract it seems doable (i.e. integer programming solvable by gradient descent). anyone please correct me if i'm wrong. if doing it with gradient descent is doable, then i wonder, can emerge one day be GPU accelerated? how coold would it be? :D ``world's 1st GPU accelerated package manager''! of course it is not a pressing issue, but i think it is a very fun puzzle to think about in my free time (which is most of my life these days), and i think some here may like contemplating such shameless thoughts. rgrds, cm.