Re: IDENTIFY failed
On Nov 4, 2021, at 08:00, Rin Okuyama wrote: > > Hmm, if affected hardware is somehow limited, we can just introduce something > like AHCI_QUIRK_EXTRADELAY. Otherwise, we can reconsider, for example, before > NetBSD 10 is released. > > Jun, Patrick, can you please provide full dmesg for your machines? > Is it a function of the ACHI controller, or the drive attached to it, or a mismatch between how the two handle the ATA protocol? A quirk table would be a good solution. I can only hope that it’s as easy as tagging a controller. For the systems that demonstrate the failure, do other drives work fine? That may be the easiest way to check. The two drives in Ebihara-san’s dmesg output are low-cost mechanical drives, and I’m more suspicious of the drives than then controllers. jf -- John Franklin frank...@elfie.org
Re: github.com/NetBSD/src 5 days old?
On May 14, 2020, at 09:07, Hauke Fath wrote: > > [re-directing to tech-repository, which was created precisely to keep > debates like this one off the other lists...] My apologies. I’ll continue this thread on tech-repository. jf -- John Franklin frank...@elfie.org
Re: github.com/NetBSD/src 5 days old?
On May 14, 2020, at 09:26, Joerg Sonnenberger wrote: > > On Wed, May 13, 2020 at 10:11:14PM -0400, John Franklin wrote: >> There are scalability issues with Mercurial, too. I cloned NetBSD src >> on a 1GB RAM, 1GB swap, 4 CPU VM (Debian Buster) using git from the >> GitHub project and from anonhg.netbsd.org. > > You are comparing Apples and Oranges. The clonebundles on anonhg are > created with very large windows and zstd compression and the necessary > buffering of that is the primary memory use. I used to provide bzip2 > bundles as fallback, but disk space constrains made that temporarily > undesirable. I.e. this is not about scaling at all. I’m comparing cloning with cloning using the same VM. From the contributor’s POV, it's as apples-to-apples as it gets. Even the commands are the same: “$VCS clone $URL” As configured, Mercurial takes 3x the memory, 4x the time, and fails to clone at all without a minimum of 3GB of RAM+swap. The driving factor behind the resource requirement is the amount of history the project has. Which is to say, how well these two tools *scale* with the size of the repository. If server-side changes can reduce that, and all the server needs is a bigger disk, then get a bigger disk. jf -- John Franklin frank...@elfie.org
Re: ongoing git vs hg (was: github.com/NetBSD/src 5 days old?)
On May 13, 2020, at 17:56, Greg A. Woods wrote:
>
> At Wed, 13 May 2020 21:30:29 +0200, Joerg Sonnenberger wrote:
> Subject: Re: ongoing git vs hg (was: github.com/NetBSD/src 5 days old?)
>>
>> On Wed, May 13, 2020 at 12:21:50PM -0700, Greg A. Woods wrote:
>>> At Wed, 13 May 2020 14:14:16 +0200, Joerg Sonnenberger wrote:
>>>
>>>> I have no idea what the OP is talking about. Mercurial doesn't have pull
>>>> requests, neither does git BTW. So this is about some specific web UI or
>>>> review tool, but I don't even know which one.
>>>
>>> Consider "pull request" to stand in for _any_ kind of workflow and
>>> mechanism that third parties would use to submit changes along with the
>>> recorded existing metadata for those changes, to the upstream project's
>>> repository.
Put another way, it’s nothing more than “please consider the changes in branch
jqcoder/foo for inclusion in your project.” Any DVCS that can handle branches
reasonably well can do something like a “pull request.” If you like it,
`${DVCS} merge jqcoder/foo`. The way GitHub handles PRs, the branch lives in
their private clone of the repository, not the main project’s copy. It
prevents the master repository from getting polluted with dozens of pull
request branches.
> So thus the question remains: What will NetBSD's workflow be? Will it
> be compatible with merging a set of changes from a third party in much
> the manner of what's typically called a "pull request" in the Git
> (github, gitlab, etc., etc., etc.) world, and especially in a way that
> avoids squashing a branch into a single commit (thus losing commit
> metadata)?
It should be possible to go both ways. I’ve seen very clean pull requests of a
few commits that should be merged including the full history, and some that
were 300+ commits with one-third of the commit messages including the words
“revert” or “undo” in them. (In some cases, the commit message was simply
“revert”.) Following the chain was fruitless, only comparing the branch to the
mainline was of any value, and a squash commit is the only way to handle such
things.
jf
--
John Franklin
frank...@elfie.org
Re: github.com/NetBSD/src 5 days old?
On Apr 30, 2020, at 21:28, bch wrote: > > I thought the plan to move to HG hasn't been finalised yet, am I missing > something? Plus, why HG and not Fossil, if the end-result consumption is via > Git anyways? > > Last I heard fossil had scaling issues due to the large number of artifacts > that needed to be tracked. I may be able to trawl notes and find some > particulars, or Joerg may be able to comment from memory on the technical > aspects. > > > I was really hopeful for fossil as a solution as it seems really sane for > many reasons: > 1) good user interface(s) > 2) good, novel ticket handling > 3) sane architecture > 4) portable C implementation > 5) BSD license > > I think in the end though Joerg reckoned the scalability issue was too much. There are scalability issues with Mercurial, too. I cloned NetBSD src on a 1GB RAM, 1GB swap, 4 CPU VM (Debian Buster) using git from the GitHub project and from anonhg.netbsd.org. Git consumed 675MB of memory at its peak, and took 4m38s. Cloning with hg from anonhg.netbsd.org consumes all RAM and all swap before the OOM killer takes it out. Upping the memory to 2GB RAM (still 1GB swap) gets further along, to the point where hg forks into $(CPU_COUNT) processes for “updating to bookmark @ on branch trunk” before the OOM killer takes it out. Finally, 2GB RAM and 1GB swap, and enabling vm.overcommit_memory was enough to let hg finish in 17m52s. jf -- John Franklin frank...@elfie.org
Re: NetBSD on a wireless router?
On Aug 15, 2019, at 14:57, r...@reedmedia.net wrote: > > On Wed, 14 Aug 2019, John Franklin wrote: > >> Are you absolutely committed to NetBSD? pfSense is an excellent >> router/firewall distribution built on top of FreeBSD, with support for >> whatever WiFi and hardware FreeBSD supports. I love NetBSD, but when I >> need to set up a router, I just grab pfSense. > > :) > > https://duckduckgo.com/?q=pfsense+essentials+book+jeremy+c.+reed > > From its preface: > [snip] Oh, so you’ve heard of it! :) > I have probably used around eight different wireless cards on a few > different hardwares running a few different versions of pfSense. While > it works for me, I haven't had great reliability or performance with the > wireless devices I've used there. None of my pfSense routers have WiFi built-in, even though it’s an option. The WiFi module my preferred hardware vendor offers is only b/g/n — no 802.11ac at all. I don’t know if I would bother even if they did support AC, because I usually use the Ubiquiti APs for WiFi. For WiFi performance and management on a budget, they’re hard to beat. On occasion, I’ll use an old home router set to AP mode, until I get around to upgrading. jf -- John Franklin frank...@elfie.org
Re: NetBSD on a wireless router?
On Wed, Aug 14, 2019 at 10:51 AM, r...@reedmedia.net wrote: I want to replace a wifi router with a NetBSD solution. The posting at <https://mail-index.netbsd.org/netbsd-advocacy/2016/02/29/msg000703.html> links to a spreadsheet of hardward, but I don't know from that yet what has wireless and how well supported. Ideas include Microtik Routerboard, OpenBlocks, LinkIt Smart 7688, Orange Pi. Is anyone using NetBSD for wireless routers? Jeremy C. Reed Are you absolutely committed to /Net/BSD? pfSense is an excellent router/firewall distribution built on top of FreeBSD, with support for whatever WiFi and hardware FreeBSD supports. I love NetBSD, but when I need to set up a router, I just grab pfSense. jf -- John Franklin frank...@elfie.org
