legogris

  • Content Count

    33
  • Joined

  • Last visited

Reputation Activity

  1. Like
    legogris reacted to Igor in ZFS dkms package upgraded to v2.0.1   
    Media info:
    https://arstechnica.com/gadgets/2020/12/openzfs-2-0-release-unifies-linux-bsd-and-adds-tons-of-new-features/
     
    Remarks: 32bit support is broken in Debian Stretch, no upgrade there. Also this upgrade is needed to bump kernel to 5.10.y
  2. Like
    legogris reacted to NicoD in Video : Review of an AWS Graviton2 ARM server   
    Hi all.
    I've just finished a new video where I review an Amazon AWS Graviton2 arm64 server.
    This is a monster with 64 high-performance N1 cores.
    It isn't clocked that high at 2.5Ghz, but it performs amazing for that clockspeed.
    Here is my video.

    Here all the info I've gathered.
     
    AWS Server 32-cores 128GB ------------------------- NEOVERSE N1 64-core AWS Graviton2 ARMv8.2 aarch64 Arm’s Neoverse N1 cores -> based on A76 -> almost identical to Arm’s 64-core reference N1 platform -> CPU cores are clocked a bit lower 2.5GHz and only 32MB instead of 64MB of L3 cache Max speed 2500Mhz 8-channel DDR-3200 128GB ram 64 PCIe4 lanes TSMC’s 7nm process node ~1W per core at the 2.5GHz frequency between 80W as a low estimate to around 110W estimation. This info is not disclosed by AWS 7z single core Ampere 32-core : 2763 AWS 32-core : 3393 Threadripper 3990x : 4545 7z quad core : Raspberry Pi 4 @ 1.5Ghz : 6307 Odroid N2+ 4xA73@2.4Ghz : 9900 Ampere 32-core : 11145 AWS 32-core : 13733 Threadripper 3990x : 18060 7z all cores : Ampere 32-core : 85975 AWS 32-core : 110628 Threadripper 3990x : 391809 433702 OC Blender BMW CPU Odroid N2+ : 30m Ampere 32-core : 8m27s AWS Server 32-core : 2m08s ThreadRipper 3990x : 30s Blender Barber shop CPU AWS Server 32-core : 8m28s Threadripper 3990x : 2m18s79 CPU Miner Odroid N2+ : 14 Ampere 32-core : 87 AWS Server 32-core : 154.20 ThreadRipper 3990x : 1310 SBC bench : http://ix.io/2FrG Internet speed test between 1500 Mbit/s and 2000 Mbit/s both up- and download (up to 250MB/s) I had 32-cores of the 64-cores. It is expected to perform a bit worse per core with 64-cores vs 32-cores since less cache available per core. There's a newer Ampere 80-core N1 at 3Ghz SoC. https://www.anandtech.com/show/15578/cloud-clash-amazon-graviton2-arm-against-intel-and-amd/6 Thank you to @lanefu for giving me access to this.
  3. Like
    legogris got a reaction from TRS-80 in Need your help - what else beside Etcher   
    So, this is how it works (and advance apologies if I misread the conversation and you're talking about something else):
     
    First off, if you want to talk semantics, sha1 is technically a cryptographic hash function, not a checksum algorithm. One could even argue that it's overkill for this use-case and that an algortithm made for checksums, such as CRC, is more appropriate (less secure but by far enough to detect random write or read errors, but more performant).
     
    The data on the card is read, bit-by-bit (well, on a lover level the reads are buffered for performance reasons, but it makes no practical difference otherwise). The data is then put through the sha1 hash function, which produces a 160-bit hash. A single bit being changed produces a completely different hash.
     
    The odds of the hashes matching up in case every single bit doesn't is 1 in ~10^18. For practical purposes, low enough odds to be practically impossible. When we're at those odds, you might as well start thinking about the probability that the read during your verification steps gives you the expected output due to a read error exactly matching the inverse of the write error during the write, RAM errors and cosmic radiation. If you're concerned about well-funded adversaries with a huge dedicated compute cluster deliberately giving you a fake image with the same matching hash, then you might want to look at more cryptographically secure hash functions - in which case replace the `sha1sum` command above with the slower but more secure `sha512sum` (512 bits, or 1 in 10^154). The chances of a collision are small enough that on average, with all the worlds current computing power, we'd be talking millions of years. The number of atoms in the entire universe is believed to be around 10^80. Pick two random atoms in the known universe and the odds of those being the same atom is still vastly higher than SHA-2 producing the same hash after a write error.
     
    TLDR; For your purposes, if the checksum validates, so does the written data (given that the checksum verification here is made between data read back from the written card vs the source file and not just between the source file and a website). Etcher did CRC32 until 2018, and is now on SHA512. Looking at the source, usbimager actually reads back the source and the target into memory and does a memcmp (straight-up byte-by-byte comparison): https://gitlab.com/bztsrc/usbimager/-/blob/master/src/main_libui.c#L147
    These are all valid approaches, only caveat with the last one being that you need to be able to fit 2x the image size into RAM during the validation
  4. Like
    legogris reacted to mboehmer in Odroid C2 on seafloor (part II)   
    We are down... and modules seem to be in good shape. Let's hope the powerup will work as expected.

  5. Like
    legogris reacted to Werner in How i can config DHCP Server to Client from armbian?   
    Any tutorial for Debian/Ubuntu on the web should suffice since there is no difference between Armbian and those on OS level.
  6. Like
    legogris reacted to NicoD in Quick review of NanoPi Fire3   
    N2+ or Khadas VIM3. They're the only ones that have more performance than this SoC.

    I've got the NanoPC T3+ with this SoC. Single core performance isn't great. But multi-core it is amazing. Faster than the RK3399.
    Here some old benchmarks. For you the CPUMiner scores are important.
     
    64-bit SBC's Odroid N2+ Clock S/C | B/C | Blender | 7z S/C | 7Z B/C | CPUMiner Ubuntu Bionic 4.9 2.02Ghz 2.40Ghz 11m20s 1755 2504 14 Khadas VIM3 |SBC bench result |CPU Miner |7-zip s/c A53 |7-zip b/c A73 |7-zip multi avg. of 3 |Blender Ubuntu 18.04.02 http://ix.io/1MFD 13.10kH/s 1577 2311 10578 42m51s Armbian@1.9S.C./1.7B.C. http://ix.io/1NRJ Odroid N2 |SBC bench result |CPU Miner |7-zip s/c A53 |7-zip b/c A73 |7-zip multi avg. of 3 |Blender Ubuntu Bionic http://ix.io/1Brv 11.35kH/s 1564 1879 9988 50m28s NanoPC T3+ |SBC bench result |CPU Miner |7-zip s/c |7-zip b/c |7-zip multi avg. of 3 |Blender Armbian Bionic http://ix.io/1iRJ 10.99kH/s 1290 10254 1h10m25s Arbmian Stretch http://ix.io/1qiF 8.55kH/s 1275 10149 1h13m55s Rock Pi 4B |SBC bench result |CPU Miner |7-zip s/c |7-zip b/c |7-zip multi avg. of 3 |Blender Ubuntu http://ix.io/1uVr 9.50kH/s 1242 1818 7802 1h17m22s NanoPi M4 |SBC bench result |CPU Miner |7-zip s/c |7-zip b/c |7-zip multi avg. of 3 |Blender Armbian bionic hz1000 http://ix.io/1nLh 10.23kH/s 1335 2005 8352 1h13m50s CONFIG_HZ=250 http://ix.io/1BLW 10.45kH/s 1335 2007 8320 1h08m28s Armbionic@1.4/1.8 hz250 1253 1828 7821 1h12m52s Armbian bionic nightly http://ix.io/1pDo 10.24kH/s 1329 1990 8292 1h13m28s Armbian stretch desktop http://ix.io/1odF 8.66kH/s 1350 1977 8400 1h14m12s Armbian stretch dsk nightly //ix.io/1pM0 8.80kH/s 1359 1993 8500 1h15m04s Armbian stretch core no fan //ix.io/1pKU 8.80-8.65kH/s 1353 1989 8461 Armbian stretch core //ix.io/1pL9 8.76kH/s 1354 1988 8456 Armbian stretch core nightly //ix.io/1pLf 8.82kH/s 1357 1994 8494 Lubuntu Bionic arm64 http://ix.io/1oGJ 9.24kH/s CPU Miner 1056 1551 6943 1h28m13s Lubuntu Bionic armhf http://ix.io/1pJ1 1111 1769 7705 2h02m54s Lubuntu Xenial armhf http://ix.io/1oCb 989 1507 6339 2h20m51s Khadas Vim2 Max |SBC bench result |CPU Miner |7-zip s/c |7-zip b/c |7-zip multi avg. of 3 |Blender Ubuntu Xenial http://ix.io/1qkA 6.86kH/s 823 1134 6682 1h14m39s 7-zip only 600% of 800% used It would be hard to make enough money to repay the devices, and power.
    The Odroid N2+ is one of the most energy efficient SBCs around. When maxed out on CPUs it only consumes 6W. Most others need double of that for half the performance.

    These days mining isn't done on computer hardware but on specialized hardware. So with a few SBCs you can't compete with these ASICs.
    But if you use solar power then you've got the big advantage that you don't need to pay for energy costs. What's the biggest cost for ASICs. If you really want to do this, then do your research well. Else it's a probable moneypit. But at least you can enjoy the SBCs.
    Greetings.
     
  7. Like
    legogris got a reaction from manuti in Focal vs Buster?   
    It's not a case of arm64 not being as well-supported. In general most modern software has way better support on arm64 than armf. If you're on a 64-bit processor, you can choose. HC2 will simply not do arm64 since it's a 32-bit processor.
     
    You can use either distro. I'd personally vouch for buster, or even bullseye. debian's testing is generally relatively stable in this phase of the lifecycle, and buster has old versions with known issues of some packages by now.
  8. Like
    legogris reacted to NicoD in Odroid N2+ / N2 Plus   
    Armbianmonitor: http://ix.io/2sUH Hi all. 
    I've recently received the Odroid N2+. Since nobody else started a topic about it, I'll be the one. 
    All works fine with Armbian since not much hardware changes have been made vs the N2. Except for the CPU frequency.
     
    With the Odroid Ubuntu you can set it to 2.4Ghz for the big cores A73 as overclock (2208 stock)., and 2016Mhz for the A53 cores (1908  stock). 

    With Armbian the max clocks are 2Ghz for all cores. Using Armbian Focal 4.9 legacy.
    I tried setting the higher values in config.ini. Also tried with the "meson64_odroidn2_plus.dtb" file from the Odroid Ubuntu. Doesn't boot with that. (What do I know )

    Other changes are the RTC battery that's now on the board. 
    The heatsink has changed a little. But it's still more than sufficient to keep it cool even when overclocked. 

    USB3 still rather s*cks on it. Slow and a lot of issues with 2.4Ghz dongles(wifi/keyboard...).
    Too bad they didn't do anything about that. But that probably could have complicated compatibility with N2 images. 

    Also feels a bit more sluggish than RK3399 on NVMe vs 128GB eMMC on the N2+.  That's what fast I/O does. I'll try on USB3-NVMe later.

    Here some pictures. 1st pic the N2+ with its case open.
    2nd picture the N2 left and the N2+ on the right.

    Cheers all.
  9. Like
    legogris reacted to ning in [HOWTO] build Debian-flavor kernel packages for Armbian with module signed and with debian-featured kernel config   
    from 1st and 2nd posts, you already knows how to use debian linux build framework to build a module signed kernel for your armbian with your own kernel configure. but you may ask is my kernel missing some features required by debian? how can I know it? and how to fix it.
     
    the answer to these 3 questions are depends on your current kernel configurations, but it difficult to read and compare each kernel configuration with debian's kernel configuration.
     
    let me tell you how debian build its own kernel configurations, then you can answer these questions yourself.
     
    The formula: Debian kernel configuration = common configs + arch specific configs  + flavor configs + kernel autoselected configs.
    here common configs are core debian features, which is in file debian/config/config
    arch configs are needed for debian to run on an arch, which are in files: debian/<arch>/config
    flavor configs are tune debian kernel into some flavor, eg rt kernel. debian/config/config.rt
    the 3 kinds of configs are write in config files, only define 5% kernel configs, and the rest are kernel autoselected.
     
    at this point, you need only to change arch related configs to make the kernel runs on your device.
     
    here are steps to make the change.
    1, use debian defualt config to rebuild your kernel. stop after .config is created.
    2, use meld to compare your config file and .config. only take care the configs missing in .config, do not touch the configs added in .config.
    3, add missing config in arch config
     
    now you get the missing configs to run on your devices.
  10. Like
    legogris reacted to ning in [HOWTO] build Debian-flavor kernel packages for Armbian with module signed and with debian-featured kernel config   
    before you start:
        Armbian already provides kernel build script in armbian build framework, and you can download these packages via `apt`
        in common cases, you shouldn't build kernel yourself, even you want to build a customer kernel package, you should use armbian build framework.
        because you can get best supports.
     
       so below content is only for experts.
     
    prepare source code:
        1, stable linux kernel source code:
            https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
           https://kernel.googlesource.com/pub/scm/linux/kernel/git/torvalds/linux.git
       2, armbian build framework, for patches and kernel config
           https://github.com/armbian/build
       3, debian linux build rules:
          git clone https://salsa.debian.org/kernel-team/linux.git --depth=1
         optional: checkout to a branch to build a different kernel version, current version is 5.5.8
       4, add patches to debian linux build rules:
          copy all family patches to <debian-rules>/debian/patches/
          add all your patches to <debian-rules>/debian/patches/series
         make sure all your patch are appliable to mainline kernel.
         optional: remove all debian's kernel patch, only leave armbian kernel patch.
     5, apply the patches.
        apt install devscripts
        cd <debian-rules>
       debian/bin/genorig.py <path-to-stable-linux>
       debian/rules orig
    6, copy kernel config to <debian-rules>/config/[armhf, arm64]/config
     
    prepare native armhf/arm64 build env
    1, donwload armbian's prebuild rootfs, or use debootstrap.
    2, mount dev, sys, proc, tmp to armhf/arm64 rootfs. reference: https://github.com/armbian/build/blob/master/lib/image-helpers.sh#L27
    3, mount <debian-rules> to armhf/arm64 rootfs.
     
    start build, in chroot rootfs
    1, cd <debian-rule>
    2, apt install devscripts fakeroot
    3, debian/rules debian/control DEBIAN_KERNEL_DISABLE_INSTALLER=true
    4, debuild -i -us -uc -b # do it only once, to let build system promt missing build depends. you need to install all build depends at this step.
    5, fakeroot debian/rules binary or fakeroot debian/rules binary-arch
    6, long wait.
  11. Like
    legogris reacted to NicoD in Daily (tech related) news diet   
    Bit off topic, that's what the topic is for
    So I've been using the NanoPi M4/V2 for over a half year as main desktop and left my pc off most of the times. That today gave me a nice advantage in my electrical bill.
    While the price of electricity goes up, I consumed 8.8% less only by using SBC's instead of my pc. And that not for a full year even. I can still improve with LED lights. And keep using my SBCs.

    This does give an example why using ARM can be very benificial. I even made a quick video about it. Not really Armbian related. I don't think I need to convince any of you of the advantages of using arm.
    But it is a good thing to think about where we can save money/energy in replacing x86 machines with arm boards.

    Arm also has disadvantages off course. Less user friendly, do it yourself... I also talk about that. So you don't need to see the video any more actually, bit if you do, please enjoy.
    Greetings, NicoD
     
  12. Like
    legogris got a reaction from OrangePee in Need your help - what else beside Etcher   
    So, this is how it works (and advance apologies if I misread the conversation and you're talking about something else):
     
    First off, if you want to talk semantics, sha1 is technically a cryptographic hash function, not a checksum algorithm. One could even argue that it's overkill for this use-case and that an algortithm made for checksums, such as CRC, is more appropriate (less secure but by far enough to detect random write or read errors, but more performant).
     
    The data on the card is read, bit-by-bit (well, on a lover level the reads are buffered for performance reasons, but it makes no practical difference otherwise). The data is then put through the sha1 hash function, which produces a 160-bit hash. A single bit being changed produces a completely different hash.
     
    The odds of the hashes matching up in case every single bit doesn't is 1 in ~10^18. For practical purposes, low enough odds to be practically impossible. When we're at those odds, you might as well start thinking about the probability that the read during your verification steps gives you the expected output due to a read error exactly matching the inverse of the write error during the write, RAM errors and cosmic radiation. If you're concerned about well-funded adversaries with a huge dedicated compute cluster deliberately giving you a fake image with the same matching hash, then you might want to look at more cryptographically secure hash functions - in which case replace the `sha1sum` command above with the slower but more secure `sha512sum` (512 bits, or 1 in 10^154). The chances of a collision are small enough that on average, with all the worlds current computing power, we'd be talking millions of years. The number of atoms in the entire universe is believed to be around 10^80. Pick two random atoms in the known universe and the odds of those being the same atom is still vastly higher than SHA-2 producing the same hash after a write error.
     
    TLDR; For your purposes, if the checksum validates, so does the written data (given that the checksum verification here is made between data read back from the written card vs the source file and not just between the source file and a website). Etcher did CRC32 until 2018, and is now on SHA512. Looking at the source, usbimager actually reads back the source and the target into memory and does a memcmp (straight-up byte-by-byte comparison): https://gitlab.com/bztsrc/usbimager/-/blob/master/src/main_libui.c#L147
    These are all valid approaches, only caveat with the last one being that you need to be able to fit 2x the image size into RAM during the validation
  13. Like
    legogris reacted to bubbadestroy in RK3399 -Smart Technologies AM40 iQ "Module"   
    SMART AM40 iQ Appliance
    P/N: 1031572
    Model: UGK-AM40-EDU | EWY1-AM40-EDU | EWY2-AM40-EDU
     
    Processor            RK3399, Dual-core A72+Quad-core A53, 64 bits, 2GHz
    Memory              4 GB DDR3L SDRAM
    Storage 32 GB eMMC 5.1
    Wireless technology       Bluetooth 4.1
    802.11A/B/G/N/Ac
    Capture options               Establish a Bluetooth wireless connection with a supported mobile device
    Connectors         HDMI 1.4 (1920 × 1080) output for external monitor
    USB 3.0 Type-A (×2)
    RJ45 Gigabit Ethernet
     
     
     
    --Update--
    For device tear-down and technical sheets included in package - SEE SECOND POST
     
    Reference links posted at bottom are sourced as I dig up more details that may be useful . It looks like the power will have to be supplied via gpio as far as I can tell.. The official documentation and fccid technical orders refer to the Headless SBC / Module what have you; as an "IQ Appliance".  Tagged 'grep' for control/command function searching through fccid or other official documentation) Otherwise found simply as AM40 rk3399 or AM40 iq on google/other engines  
     
    --AM40 iQ - Anyone seen or attempted armbian on something similar?--
     
    Figured this forum may be one of the few places that might appreciate and see what I first saw.
    So if anyone might have an idea where to proceed with a possible hidden gem like this..
     
    I picked it up for reasonable price a quite a bit LESS than current nanopi m4 cost  the other night. Can't say quite yet if it will be a useless paperweight, or a diamond in the rockchip. heh.
    As soon as it arrives I intend on seeing what kind of hac.. err educational research can be done to place Armbian on it eventually over its intended OS. There seems to be a service switch that is used on other models to allow intel modules and windows OS. The form factor seems to be carrier board size, so here's hoping for that switch to be more open to source than intended for this particular model.
     
    It's just something about the specs on it raised an eyebrow, yea? And the case it comes with is pretty solid compared to the shit, err, other case and fan combos you normally see.. That alone..
     
    I didn't see any tear-down from the ffcid schematics available to the public, possibly because it sold as an education exclusive device to school system.
    If anyone here shows interest, I'd be glad to do a tear-down (bubba do like destroy) and share it with the RK3399 community.
     
    -Follow up-
    Regarding cost. I paid somewhere under $50. If anyone else considers it, I suggest you be firm with the seller, and make an offer that is well under what they're going to be asking.
    Reason to be a cheapskate on these things? Well..
     
    1. Likely these were paid for by government tax funds for schools. Or written off as a privately owned business cost anyhow, which means someone like us already helped pay for them.. In the form of tax or tax return budget allotted to business owners.
     
    2. Considering I'm not even sure if its possible to power on so simply without gpio testing or a breakout wizard beard
     
    3. Cause we can build this things ourselves already for under $100 easily. So yea don't pay something more than that, even brand new for sure!
     
    Open Power Specification and 2 pins in the back is all I see so far.
     
    Ebay:
     
    https://www.ebay.com/itm/SMART-Model-AM40-Part-Number-1029788-Rev-07-No-Antennae-Very-Good-Condition/174156468137?hash=item288c88cfa9:g:DvwAAOSwCRVdcQyW
     
    https://www.ebay.com/itm/NEW-SMART-iQ-Appliance-AM40-Education-Digital-Signage-Player-Rockchip-RK3399/173853101572?hash=item287a73ce04:g:AccAAOSwaAlccc2l
     
     
    Manufacturer Reference:
    https://support.smarttech.com/docs/software/iq/en/about/specifications/am40.cshtml

    https://support.smarttech.com/docs/software/iq/en/about/iq-appliance-connectors.cshtml
     
    FCCID Technical Orders: doesn't seem to have its own nomenclature listing however, it is referenced in great detail its carrier device (an over priced touch screen)
    sourced for IMPORTANT notes before any reversing or mod attempt at introducing hardware compatible touch screen, PSU, OPS (serial) etc

     
     
    user manual control/command function search 'grep AM40'
     
    FCC ID QCIIDS665P1
    QCI-IDS665P1, QCI IDS665P1, QCIIDS665P1, QCIIDS665PI, QCI1DS665P1, QCIID5665P1, QCIIDS66SP1, QC11DS665P1, OCIIDS665P1, 0CIIDS665P1
    SMART Technologies Inc. SMART Board 6000S and 6000S Pro Series Interactive Displays IDS665P1
    SMART LCD Monitor SBID-6065S, IDS665-1
    Smartboard Interactive Display 6000S / Pro SBID-6265S, SBID-6275S, SBID-6265S-PW, SBID-6275S-PW
     
    https://fccid.io/QCIIDS675P1
    https://fccid.io/QCIIDS675P1/Users-Manual/User-Manual-4554712
     
     
    FCC ID QCI7086
    QCI-7086, QCI 7086, QCI7086, QCI7O86, QC17086, OCI7086, 0CI7086
    SMART Technologies Inc. Interactive Display 7086
     
    https://fccid.io/QCI7086
    https://fccid.io/QCI7086/User-Manual/Users-Manual-3626573
     
    https://fccid.io/QCI7086/Internal-Photos/Internal-Photos-3626563
     
     
    user manual control/command function search 'grep iQ appliance'
     
    FCC ID QCI7000
    QCI-7000, QCI 7000, QCI7000, QCI7OOO, QC17000, OCI7000, 0CI7000
    SMART Technologies Inc. Interactive Display 7000
     
    https://fccid.io/QCI7000
    https://fccid.io/QCI7000/Users-Manual/user-manual-3417295
    https://fccid.io/QCI7086/Internal-Photos/Internal-Photos-3417295
     
     
    OPS: Open Plug-gable Specification  Serial (40 pin) Seria(40 pin) = OPS (80 pin
    *note, not sure exactly if this is the way to go, but closest I could find for now to adapt the OPS interface
     
    manufacturers "support" forum search regarding ops
    https://community.smarttech.com/s/global-search/OPS?language=en_US
     
     
    A Challenger Appears
    https://hackaday.io/project/20193-open-pluggable-specification-breakout-board
     
    https://www.digikey.com.au/products/en/connectors-interconnects/rectangular-board-to-board-connectors-arrays-edge-type-mezzanine/308?k=tx24&k=&pkeyword=tx24&s=54162&pv1989=0&FV=ffe00134&mnonly=0&newproducts=0&ColumnSort=0&page=1&quantity=0&ptm=0&fid=0&pageSize=25
     
     
     
     
     

     
     
     
     
    OPS: Open Plug-gable Specification
    potentially an inconvenient convenience.  (hdmi,usb,rj45 and etc..) to make the platform a module.
    imagine your favorite usb to serial, or whatever favorite debugging i/o.  Now, chop off the USB part, and replace it with this. heres hoping those 2 pins are simple logic level voltage and ground

     
    Service Switch:
    Possibly switches between EMMC and SD Boot? May be interesting

     
     
    TLDR;
    possibly epic fail or epic win
    used condition: metal case / fan / rk3399 / 4GBDDR3 / 32GB EMMC

     
    vs
     
    NanoPi M4 Metal Case w/ Cooling Fan 
    $30 to $45
     

     

     
    Metal Case with Cooling Fan and
    RK3399/4GBDDR3/32GB eMMC
    $35 to $100
     

     

     

  14. Like
    legogris reacted to Igor in Seed our torrents   
    https://dl.armbian.com/_download-stats/
  15. Like
    legogris reacted to Igor in Seed our torrents   
    Via torrent network we only serve latest images which redistribution among fastest servers only takes several minutes. At that point, they are already present at all fixed mirrors. No reason to worry
  16. Like
    legogris reacted to TRS-80 in Helios64 Annoucement   
    OK, now that I have read through this whole thread, as well as the Announcement over at Helios (and comments over there) I have some further thoughts...
     
     
     
    I guess you were so concerned about the price, you saw the need to point it out twice?
     
    Sure, x86/amd64 are fine, if you like firmware level backdoors into your system. Personally, I don't and therefore have stopped purchasing recent Intel/AMD hardware for a number of years now.
     
    And besides he said...
     
     
    Which I thought was quite reasonable (and rare nowadays with how greedy most business people have seen to become) and also allowing for several different options and use-cases. Quite nice in fact IMO.
     
    Hopefully we will end up with Nice Things (tm) instead of some proprietary firmware somewhere. From what I can tell there shouldn't be any (required?) video, bluetooth, Wi-Fi stuff here. Those are usually the problem areas, so I remain "cautiously optimistic."
     
    ECC
     
    For those others like me looking for ECC (for ZFS, or similar), some slight bad news:
    the ECC version will be only 2GB (not 4GB) and will not be available immediately at release Apparently up until now there were none at all ECC SDRAM modules available on the market. After reading their Announcement (including comments) I learned they seem to be in the pipeline and getting close (but will miss release). So, hopefully Soon (tm). Also, the only modules that are even available at all are 8Gb (small "b" = bits) x 2 of them on board (see pics) = 2GB (big "B" = Bytes) RAM total). So that is what we will be able to get, for now.
     
    They say they will think about upgrading later to larger capacity, as soon as bigger modules become available on the market.
     
    I am already thinking I am not sure how patient I can remain, after waiting for something like this for literally years. I may buy first available ECC model of this board, and then later on, well... Maybe I will finally get around to modding our toaster oven into a uController managed reflow oven...
     
    Still better than anything that has come thus far, and if you are not doing de-duplication, etc. or certain other features (talking ZFS here) you don't need a ton of RAM (and old guideline of 1GB/TB or whatever does not apply). I plan on doing straight mirrors anyway, with large disks, for lots of different reasons.
  17. Like
    legogris got a reaction from TRS-80 in Surveying the hardware landscape 2019 and beyond, with an eye toward freedom (headless server)   
    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.
     
     
  18. Like
    legogris got a reaction from lanefu in Process for adding CSC boards?   
    I'm having some success installing Debian on Raspberry Pi 3B+ and thought I'd proceed with making an Armbian build in order to have equivalent environments with other boards in my cluster.
    Is there any process/channel for this or should I just make a PR on the repo? What are some particular prerequisites I should be aware of that might block it from merging?
     
    I am very aware of armbian's stance on Raspberry Pi, and I understand you do not want to support it officially (if nothing else because you'd have difficulty handling the incoming clueless users), but I think there are a lot in the intended armbian audience who have Raspis lying around who would be happy about an armbian build. Also it could act as a gateway to bring people to educate themselves more on Linux in general.
     
  19. Like
    legogris reacted to TRS-80 in Surveying the hardware landscape 2019 and beyond, with an eye toward freedom (headless server)   
    Greetings everyone,
     
    A couple years ago, I did my research and followed the recommendation here and on linux-sunxi to purchase a Cubietruck and have had excellent results.
     
    I use my small low power GNU/Linux sever for all manner of things including self hosted "cloud" (contact, calendar, file synchronization), XMPP messaging server, media server, etc...  It has been such a success in fact that we are putting more and more of our valuable personal files on there like pictures, etc. and that has me thinking more and more about reliability, backup, etc...
     
    I became very interested in ZFS but my understanding is that it requires 64-bit, but the state of 64-bit ARM devices seems... well, not quite ready for prime time just yet?
     
    I have spoken to some friends and family about my self-hosted solution, and a few of them are interested now in doing something similar. So now I am thinking along the lines of purchasing a second (and/or third...) Cubietruck and putting together a sort of distributed cluster of little servers at different locations where we each back up one another's data.
     
    So I guess my question is, should I pull the trigger now and purchase additional Cubietruck(s), or just sit tight and wait a little longer until 64-bit ARM matures? Or perhaps there is some other option I am not aware of (hardware recommendation)?
     
    My primary concerns are privacy, including keeping my own data on devices I physically control or have access to. Also the whole state of affairs with blob bootloaders is very troubling to me, but it has been difficult for me to find specific info on this, at least with regard to specific ARM based hardware. Maybe I am not looking in the right place(s)? Any pointers about where to find such information would also be greatly appreciated.
     
    To give you an idea of where I am coming from, I spent years and hundreds of dollars acquiring a number of KGPE-D16 motherboards and related hardware (ECC RAM, etc.) to run Libreboot and ZFS, only to measure the power consumption and realize that at hundreds of watts it was totally unfit for the purpose of a 24/7/365 server. I just don't want to make any more really bad mistakes like that. I know there are some very knowledgeable people here, and I am hoping some of you can contribute to a discussion that would get me (and others who think similarly) looking in the right direction.
     
    TRS-80
     
    P.S. - I just want to thank everyone here who is doing such a fine job. The developers as well as those who help in answering questions in the forums, etc. I am very short on time these days and cannot help out in that way myself currently, however I did make a small monthly financial commitment in the form of a membership. It is not a lot but is the least I can do. I feel that those of you who spend your valuable time on development, support, etc. should not have to come out of pocket for server costs and other small expenditures. I know that I personally greatly appreciate your work, I'm sure others do as well, even if they don't say so as often as they should. Cheers!
  20. Like
    legogris reacted to TRS-80 in Process for adding CSC boards?   
    There is also the issue that RPi has a locked down bootloader / RTOS / GPU blob running underneath the OS, which is totally unacceptable from a Freedom standpoint.
     
    Debian (which Armbian is at least partially named after) to me (and I am sure many, many others) stands for some other things besides the technical bits of the package manager and software repository. Debian takes a strong political stance in favor of Free Software.
     
    Now this is not something that Armbian (as far as I know) officially adopts. And in fact I think there are some other blobs in certain places that are required to get certain boards to run, etc. I am actually still trying to figure all of this out but in the meantime, just something I wanted to bring to your attention for consideration.