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.
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
legogris reacted to bubbadestroy in RK3399 -Smart Technologies AM40 iQ "Module"
SMART AM40 iQ Appliance
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
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
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.
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.
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
FCC ID QCI7086
QCI-7086, QCI 7086, QCI7086, QCI7O86, QC17086, OCI7086, 0CI7086
SMART Technologies Inc. Interactive Display 7086
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
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
A Challenger Appears
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
Possibly switches between EMMC and SD Boot? May be interesting
possibly epic fail or epic win
used condition: metal case / fan / rk3399 / 4GBDDR3 / 32GB EMMC
NanoPi M4 Metal Case w/ Cooling Fan
$30 to $45
Metal Case with Cooling Fan and
$35 to $100
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."
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.
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.
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.
legogris reacted to TRS-80 in Surveying the hardware landscape 2019 and beyond, with an eye toward freedom (headless server)
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.
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!
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.