legogris

Members
  • Content Count

    20
  • Joined

  • Last visited

About legogris

  • Rank
    Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Cool. Already placed an order last week but FriendlyELEC seems hit by coronavirus or something. 7 days now and zero communication despite reachouts over e-mail, forum PMs and phone calls. If it weren't for their track record and the lockdown in Guangzhou I'd just assumed I've been scammed. Thinking if I should do a chargeback or keep waiting :/ EDIT: What do you know, I just logged in on their webshop and the order was marked as shipped today, so I guess things are moving and they're just overwhelmed and low on english-speaking staff.
  2. Nice perk of seeding: Since there is such a large number of torrents targeting individual boards and chipsets, sorting torrents by ratio give nice statistics on board popularity and trends. Can be helpful to see which boards to check out closer
  3. Ok, cool. Was just thinking we may be a bunch of people with Gbit/s downlinks who will occupy bandwidth that'd be better serving those actually downloading releases for themselves and that it might be hard to get people to change it once they've deployed so better nip it in the bud so to speak. But I guess that's just premature optimization, so nvm
  4. I don't really see what the users bandwidth has to do with this..? Initial seeders get hit equally hard by 100MBit/s downloads regardless of if that user is on a 100Mbit or 1Gbit/s connection?
  5. I was mostly thinking to ease for the initial seeders rather than for the people using the script. 10Mbit/s sould be a sane default?
  6. First batch of torrents on my new seed box Maybe it would be a good idea to modify the script to limit download speed a bit by default (so we don't get overloaded by all of us downloading at top speed at release, there's a bit of balance here, just a thought)
  7. Did anyone run Ethernet/Wi-Fi benchmarks/speed test on any of these boards?
  8. @gdm85 I'm considering this board as a wifi hotspot and I'm curtious what kind of speeds you see over Ethernet / Wi-Fi?
  9. Thanks for the input, guys! I'll order another board and run some benchmarks (and sorry for getting x86 in here xD) @Daniel Denson What case do you use for this with disk(s)?
  10. I'm currently on the hunt for the cheapest decently reliable board to use for building a glusterfs cluster. Requirements are simple: GbE, SATA port, arm64, preferably low power. While helios64 is obviously the way to go for a NAS when it lands, it's totally overkill for a setup like this and I just realized that ODROID HC2 won't fly due to being 32-bit only. Most other 64-bit boards require expansion boards for SATA, which drags up the total cost. Finally I realized that the PC Engines APU boards fit all criteria, and come with what I understand to be performant GX-412TC CPUs. This one, for example, for 86EUR (maybe a bit on the pricey side, but I haven't found better actually): https://www.pcengines.ch/apu2d0.htm These boards are generally only used as router boards, and I am actually already using one as a router (which prevents me from doing tests myself right now unfortunately :P) Does anyone have any idea of if this is a Bad Idea or worth a shot? Looking at the specs I don't see an obvious reason why this wouldn't work. EDIT: While I guess an interesting topic to use these boards for other purposes, I realized now that the Espressobin looks more suitable at smaller size and lower cost at ~60EUR + shipping, so I think that's the best bet for now. EDIT2: Seems like GlusterFS has higher requirements than I thought and performs poorly with Gluster; this user got a measly 35Mbps (albeit with 5 disks): https://www.reddit.com/r/DataHoarder/comments/92zwct/espressobin_5drive_glusterfs_build_follow_up/. Redhat recommends 16GB minimum but surely it could be reasonable for home use with less... https://access.redhat.com/articles/66206 The APU has 2 instead of 4 cores and comes with in a 4GB version over the Espressobin's 2GB, so maybe it's the better alternative after all.
  11. So my takeaway after reading up a bit more. For CPU/IO loads, Khadas VIM3 is a beast and looks unparalleled today, but is quite expensive and includes an NPU which you may or may not need. VIM3L is a bit lower specced but can easily be extended to get PoE, which is nice. ODROID N2 comes close, but is physically large. NanoPi M4V2 looks to be the most reasonable option on the market today - if only it came in a 4GB RAM version... I feel that each of these boards is so close but each is missing one single thing that ends up making it a significant compromise. XU4 is quite low-specced compared to each of these, and similarly priced to the NanoPi M4. FWIW, linuxgizmos just compiled a decently comprehensive spreadsheet that is pretty up to date: http://linuxgizmos.com/ringing-in-the-new-year-with-136-open-spec-linux-sbcs-under-200/ Also, @NicoD has a lot of good stuff on his youtube channel: https://www.youtube.com/watch?v=2Yu8Rj7o9lk For now I think I will hold off any new purchases and fall back to NanoPi M4V2 in absence of new models or price drops in the coming couple of months.
  12. I am building from source using the vagrant process, as outlined here: https://docs.armbian.com/Developer-Guide_Using-Vagrant/ When running ./compile.sh, I get the option to customize the kernel via dialog and I did select some customizations. When saving the config, I choose the default `.config` as output. However, when running `./compile.sh` a second time, all the settings are back at default and I can not find any `.config` file anywhere in the tree. No files in `userpatches` are changed since before running the compile. Reading https://docs.armbian.com/Developer-Guide_Build-Preparation/#providing-build-configuration suggests new config files should be generated but I can't locate any. The files in userpatches are untocuhed. I do see `./output/config/linux-rockchip64-current.config` - this seems to contain kernel config (I did a build for rockchip64 here). Is this what I'm looking for? If so, how do I reuse this in a sustainable way? Lastly, do I get it right if by default I should put generic customizations in `./userpatches/config-default.conf` and board-specific ones in e.g. `./userpatches/rock64.conf`? (Asking since docs seem to be very out of date wrt directory structure)
  13. This has now been fixed: https://github.com/armbian/build/pull/1772
  14. Dang, I must have just missed it, they're up at $48 each now. 9$ each was a crazy deal.