From owner-freebsd-questions@freebsd.org Fri May 1 13:06:56 2020 Return-Path: Delivered-To: freebsd-questions@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 5934B2D5540 for ; Fri, 1 May 2020 13:06:56 +0000 (UTC) (envelope-from galtsev@kicp.uchicago.edu) Received: from kicp.uchicago.edu (kicp.uchicago.edu [128.135.20.70]) by mx1.freebsd.org (Postfix) with ESMTP id 49DCFW3kmnz4VvX for ; Fri, 1 May 2020 13:06:55 +0000 (UTC) (envelope-from galtsev@kicp.uchicago.edu) Received: from [192.168.43.113] (unknown [172.58.139.192]) (Authenticated sender: galtsev) by kicp.uchicago.edu (Postfix) with ESMTPSA id 711014E620; Fri, 1 May 2020 08:06:54 -0500 (CDT) Subject: Re: FreeBSD-speedometer? To: Polytropon , Matthias Gamsjager Cc: freebsd-questions@freebsd.org References: <20200501125126.4cb4076b.freebsd@edvax.de> From: Valeri Galtsev Message-ID: Date: Fri, 1 May 2020 08:06:53 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <20200501125126.4cb4076b.freebsd@edvax.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 49DCFW3kmnz4VvX X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=uchicago.edu (policy=none); spf=none (mx1.freebsd.org: domain of galtsev@kicp.uchicago.edu has no SPF policy when checking 128.135.20.70) smtp.mailfrom=galtsev@kicp.uchicago.edu X-Spamd-Result: default: False [0.30 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; DMARC_POLICY_SOFTFAIL(0.10)[uchicago.edu : No valid SPF, No valid DKIM,none]; RECEIVED_SPAMHAUS_PBL(0.00)[192.139.58.172.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.10]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-0.92)[-0.920,0]; FROM_HAS_DN(0.00)[]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.03)[0.029,0]; R_SPF_NA(0.00)[]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:160, ipnet:128.135.0.0/16, country:US]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(0.09)[ip: (0.27), ipnet: 128.135.0.0/16(0.13), asn: 160(0.11), country: US(-0.05)]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2020 13:06:56 -0000 On 5/1/20 5:51 AM, Polytropon wrote: > On Fri, 1 May 2020 11:21:56 +0200, Matthias Gamsjager wrote: >> We have binary package so you don't have to compile your self. >> Of course it is a choice to compile everything but why would you want to do >> that on a small machine? > > Why? Especially because! :-) > > In ye olden times, you often used source-based installation > methods to tweak the amount of what gets installed (memory > footprint), and you dealt with cimpile-time options to get > faster software - faster than what the default configuration > allowed. For example, system tools could be omitted, or the > kernel could be configured in a way to only contain the > stuff needed for a particular system. It was also useful > for ports where you needed to deviate from the default > options, or where you were forced (!) to use source-based > installs due to licensing restrictions. > > For those who wish to track -STABE or -HEAD, source-based > installations are mandatory. Maybe someone wants to check > if a specific patch works as intended - the whole system > or just one of its components can be built and installed. > This currently is impossible with binary packages. > > While I personally enjoy using binary packages, they are > not an answer to every scenario, because there simply is > no "one size fits all egg-laying wool-milk-sow". > > Machines equipped with slower disks and less memory will > of course need more time to build something. This is why > several users keep their machine running at night where > it can compile happily. On a 150 MHz Pentium with 64 MB > RAM, building a kernel required a few hours, and the whole > system needed 24 hours to build. With today's hardware, > compile times are faster. And especially for building ports, > some people use their own build servers (real or VM) for > this task. > > > >> If you really want to see how fast it could go. Spin up a machine on AWS >> with the memory and CPUs you would compare it to. > > Comparing bare metal to virtual metal is like cheating > in statistics - choose your test subjects in a specific > way to get any result you want. :-) > Agree with the sentimet. That aside, Unixbench, maybe? Valeri > > -- ++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++