From mboxrd@z Thu Jan 1 00:00:00 1970 From: Georg Potthast 2 Subject: Re: Condensing and re-coding programs to save space Date: Tue, 28 Feb 2017 12:54:32 +0100 (CET) Message-ID: <994626183.125220.1488282872735@com4.strato.de> References: <406f2bdb-b019-71d9-f1dc-87ac86b8ef18@jodybruchon.com> Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Return-path: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1488282874; l=2026; s=domk; d=georgpotthast.de; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Subject: References:In-Reply-To:To:From:Date; bh=bRvpE2APhubA1z9yAz7BRTNleutn/jx3uWCn82ndqYY=; b=oSQJK4sgD4xhfU3RcO+wZ+sgp3KAiJm236l2agECL1YeuF6qygfOaknxzTyTkGSXxn mz3naVNQpYJnwXIJetwgdaiSfV4tBwMBKtCrV1xlBu1BEGjsZBCxVFsfAr8IFNjDgf7O EYaSSQ4QCUCsL63yDMAmHiIHfgz4JzNw0ZG+k= In-Reply-To: Sender: linux-8086-owner@vger.kernel.org List-ID: Content-Type: text/plain; charset="macroman" To: ELKS I have not tested it, but my understanding is that the Makefile puts differ= ent files on the floppy images depending on the type selected. So a 360 Kb = image has fewer files than a 1.44 image. As long as the list of files for e= ach format in the Makefile is maintained I think this would be sufficient f= or now. With the new ethernet support one could set up a repository ;) Georg > Marc-Fran=C3=A7ois LUCCA-DANIAU hat am 28. Februar 20= 17 um 10:31 geschrieben: >=20 >=20 > > Well, see...that's a problem. The ELKS kernel uses a really old copy of > > Kconfig from Linux and when I looked at extracting the one used in a mo= re > > modern Linux source code base the task was far from trivial. A lot of E= LKS > > was cobbled together well over a decade ago. I'm open to moving to a mo= re > > all-encompassing build system if someone wants to do it, but it certain= ly > > will not be a simple task. >=20 > Mmm... let us be pragmatic and stop dreaming with stuff like "changing > the compiler", "moving to another build system", etc. ELKS is > definitively a "hobby" / "educational" project, with a few active > contributors, and is intended to have fun, not for business (except > data erasing / recovery on antic machines ?). So our development > strategy should be consistent with that matter of fact : little steps > forward, and keep consistency and stability. Obsolescence is > absolutely NOT a concern here, as long we find compatible emulators > and embedded systems to play with. >=20 > Back to the current Kconfig: it works quite well, fulfills the need, > so why breaking it with an hazardous upgrade ? I only propose to use > it not only for the kernel, but also for the applets and image format > selection. Not to upgrade it. >=20 > MFLD > -- > To unsubscribe from this list: send the line "unsubscribe linux-8086" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html