tkaiser

Well, I never buy 'brands' but chipsets instead. If it's about USB-to-SATA I only buy (and search for) these and maybe ASM1351 soon. With USB3 hubs I only buy VIA812 (rev B or newer) and with Gigabit Ethernet only RTL8153 (I own one such combined thing also from ORICO but again I searched for the ICs used to ensure I get exactly the good ones). Please be aware that some USB3 capable SATA bridges start to fail miserably with more recent kernels and you need to adjust some values to stop storage problems (and further decrease performance at the same time)

BCM2837 combined with LAN9514 allows for netbooting, no SD cards needed since early 2016. And since the above Raspberry cluster is there to dig into simulating large scale clustering most probably the use of devices with crappy USB Ethernet is a better choice than using good boards with GbE (since better simulating the scaling)

Sorry, I'm missing words. But this also explains so much and why it's useless to waste even one more second on everything UI related with Armbian.

Tried a new image on a Pinebook and am slightly shocked. A huge penguin is starting at me. When/where was the wallpaper switch from armbian06-1430-very-dark to armbian03-Dre0x-Minum discussed? I want to understand the reasons...

This is a useless product targeting RAID/NAS novices that don't know what they do RAID-1 was somewhat useful last century when we couldn't do better. On servers. That need 100% availability. It's useless at home, just an insane waste of disk capacity. Protection level is bizarrely low, it allows neither for data protection nor data integrity, you should really instantly try to test whether you can access your RAID-1 without this board (since it's a single point of failure and the board or the RAID controller on it can fail as well) and check data integrity (since those ICs are prone to overheating under load). Everything I wrote here about mdraid RAID-1 applies to those external USB-RAID controllers too: https://forum.openmediavault.org/index.php/Thread/18637-Home-NAS-build-FS-info/?postID=146935#post146935 As written above: Don't trust this thing. Check for data integrity (use btrfs and scrub your data after you let a large resync run), check how the board signals that one disk has a problem (you bet on redundancy here and the goal is to be protected from one failing disk -- what if this thing doesn't tell you when one disk is failing, you lost your redundancy and then soon after the 2nd disk dies?). Stop playing RAID, do backup instead (by using modern filesystems and their features, eg. snapshots sent to another disk or even host regularly, this can be done pretty efficiently). RAID is not backup, you have no data protection with this approach since it's only about availability.

This was broken from day one. Thanks for the report, fixed now.

Stuff that can be explained on the page that appears when clicking on it. Same with video. Anyway, I give up and only hope Igor is showing this thread to those UX experts...

No idea. I tried the script on ODROID-XU4 and Banana Pi and it always fails in the same situation: hdparm --fallocate $whatever file always returns with 'File too large' regardless of the size. Since the very same happens on the Banana Pi also when the SSD is connected via SATA maybe it's just a bug in hdparm v9.43 (that's the version Jessie and Stretch use, had no time to test with Ubuntu yet)

Hmm... does only apply to two updated Banana installations. I'll look more into...

Just for the record: /etc/init.d/armhwinfo on my 5.35 test installations is neither executed on startup nor shutdown and it needs a manual systemctl enable armhwinfo to get it working. Can anyone confirm?

Not in your situation on your board since this would require FEL mode, there's no FEL button on this board and to enter FEL mode you would need to boot a special mini SD card image. And since SD card is not working for you (check card detect pin)...

Yes, but not in the usual 'let's throw walls of text on users to ensure they don't read a single sentence' manner but context sensitive. If we would provide filter buttons like and if it's possible to display then individual headers/footers a mini explanation what 'fast storage' means over the listed devices with links to such relevant articles below the device listing would be IMO an improvement in guiding users in this 'pre purchase' stage. Same with video acceleration quickly explaining legacy vs mainline and that they can forget about browser support. Same with Wi-Fi explaining that onboard Wi-Fi is only usable with basic scenarios. And so on...

IMO it's not necessary to mention vendor names since why? If these filter links would be categorized itself unlike now with alphabetical order something like the following would most probably work (needs UX tests of course): Filter by board: Banana Pi, Nano Pi, ODROID, Olimex, Orange Pi, Pine, Others Filter by feature: Fast storage, very fast storage, Gigabit Ethernet, video acceleration, M.2/mPCIe, USB3, SPI NOR flash Filter by feature: 32-bit, 64-bit, BT, onboard Wi-Fi, A20, A31, A33, A64, H2+/H3, H5, i.MX6, Marvell, Rockchip, Amlogic

Why that complicated? As soon as we would start to look at Armbian from the outside (which I doubt will ever happen) it's as easy as this: We only need to unhide the invisible sort order that's currently hidden in a wall of text and name it appropriately. No, Armbian sorts by 'date of support added' by default which is OK since some users monitor the download page for devices becoming ready. But it needs an easy accessible way to switch to name based order. If it's the default make a large enough single clickable line called 'Sort boards by name instead'. If it's sorted by name then let this link read 'Sort boards by date of support added instead'. Problem solved.

If we would ever start to develop this kind of stuff from the right starting point (the user perspective) we would immediately get that there are two different use cases for the download page: pre purchase: user wants to buy a new board based on certain criteria (both hardware and software related, the latter eg. kernel support). Here user expectations and selection criteria are important. From a user perspective it's again not about 'SATA' but 'fast storage' and we do really no good job advertising GL830 boards as 'fast storage' boards (which we DO when looking at the download page from a user and not biased techie perspective) post purchase: user holds board in his hands, wants to download the appropriate OS image for his device. In this case filtering for board names -- ODROID, Banana, Orange, Nano -- would be nice (but by switching to 'name based' sort which no one ever does since it's hidden on the page instead of being directly above the individual board links this could already be achieved). And it would also be great if the names on the download page would be the real ones so differentiation is more easy. It's replacing the + sign with the five characters ' Plus' (expect for ODROID C1+ where it's not necessary). There's a huge difference between 'Orange Pi Zero+' and 'Orange Pi Zero Plus' especially with default sort order (date of added support) As soon as we would switch perspective and ask what's needed from a user perspective and not doing what's ALWAYS WRONG and NEVER WORKS (puzzling together some technical details and make some of them available for whatever reasons in a weird fashion) all these questions would already be obsolete. Seriously the buttons on top are overloaded with confusing stuff and itself ordered in a way that make them totally useless. Eg. there's a button 'm2' (should be 'M.2' instead!) that appears between 'legacy' and 'mainline' due to alphabetical order for no reason. Useless.

Hmm... not really since this should happen at the driver layer. He uses a script describing 'We need a very modern hdparm, for its --fallocate and --trim-sector-ranges-stdin flags' which is interesting since I'll try TRIM with my JMS578 then soon

Current categories: 64-bit: Useless since Orange Pi R1 is listed here. Drop the category if we can't manage to provide correct information!!! Wi-Fi: Useless since onboard Wi-Fi is crap on all the boards we support (on some even real crappy) and boards are listed that have no onboard Wi-Fi but mPCIe slots. Yes, it's known that for good Wi-Fi you need to buy another device (either USB or mPCIe) and attach it. So what is this 'selection criteria' for other than spreading misleading information? If we want to help users we would need to explain what onboard Wi-Fi is usable for. BT: What is this for? Working BT support or 'chip that could do BT if you use kernel xy and solve the remaining problems yourself'. Useless as criteria if Armbian can't provide full BT support so either it will be this or should be dropped entirely. A10: One board nobody is using, let's make pcDuino 2 EOL and get rid of the category H2 vs H3: Why? These SoCs are more or less identical and differentiation between makes no sense IMO SoC vendors: Is anyone ever searching for this? Almost all boards appear when clicking on Allwinner and with the other vendors it's not much to gain mpci: should be mPCIe msata: totally wrong Notebook: Why? We support only one and people will never search for this since they visit us only since they already own a PineBook and not since they want to inform themselves about 'laptops with good Linux support' USB3/SATA: Highly misleading though I have no idea how to solve this other than starting to implement subjective categories like 'fast storage' (A20 and i.MX6 SATA) and 'very fast storage' (USB3 and Marvell SATA)

Nope, they sort it by popularity or whatever (Pine64 at the top and ROCK64 at the bottom for example) and try to group by board names (eg. putting LeMaker's Banana Pro and SinoVoip's BPi M2+ in one section while both are totally incompatible -- same problem also with NanoPis). Doing so is HIGHLY MISLEADING since not brands are important but the technical base. A NanoPi NEO 2 and a NanoPi M3 are from two different worlds while a NEO 2 and an Orange Pi Zero Plus are almost the same (especially when Armbian is running on them it will be very hard to spot any difference in usage and performance!) If people search on the download page they search for features. If they're absolutely clueless we can't help them anyway. If we want to guide people a little bit we have to stop what we're doing now (focused on technical details) and start to get into the heads of our users (what are they interested in? And are these the correct reasons? Again 'SATA': Not the existence of a small port with 7 pins to connect a SATA cable to is relevant but what users associate with this. And on boards we list as what they consider the label for 'fast storage' they get just insanely slow and broken GL830 USB-SATA crap). Seriously: people looking for the NAS use case click on GbE, click on SATA, check the boards, think 'the more DRAM the better', think 'the more CPU cores the better', weigh some features and end up buying an Orange Pi Plus 2 instead of an ODROID-XU4 (which is magnitudes faster as NAS but is not even considered since users think 'SATA is better than USB3'). What we do here is highly misleading and must stop.

And both are WRONG! That's the problem. Better no information than misleading/wrong information. Unless this categorization can be edited/reviewed by us (eg. part of board config files) I would really prefer to stop 'advertising' wrong features. mSATA: the Hummingboard has no mSATA but mPCIe only, same with the Clearfogs by default: you need to rebuild u-boot and have to freeze the packages to get reliable mSATA/SATA on the mPCIe slot(s) SATA: This category is totally worthless if boards with crap SATA like the Orange Pi Plus and Plus 2 are listed here too. People look after SATA since they associate 'fast storage' with this. This is already wrong with those A20 boards but it gets bizarre when we're talking about the crappy GL830. And the only boards with real fast SATA -- not on mSATA slots but M.2 slot with key type B -- are missing here Again: user perspective. The features listed there should match user expectations (and that's fast storage and not 'technically a SATA port is on the board even if it's crap'). Just another part of the same problem...

Well, with SuperSpeed I doubt there will be any real differences since 5 Gbps with 8b10b encoding means USB bottelenecking here with ~400MB/s maximum. And if the host is SuperSpeed Plus capable (10 Gbps with 128b132b encoding) then the SATA 3.0 controller on the other side of the chip will be the bottleneck (6 Gbps with 8b10b encoding --> ~480 MB/s max, no idea how/why benchmarks show up to 520 MB/s here). Though there might be differences wrt random IO but honestly: if I need high random IOPS then eliminating the USB bottleneck is a better idea. These numbers here show that 'native SATA' provided by Marvell SoCs outperforms any USB3 solution easily especially wrt random IO (and I doubt ASM1351 will make a real difference here). BTW: same test with an EspressoBin shows only slightly lower numbers than the Clearfog from my link. Is needed at both ends of the USB cable (and AFAIK it's still missing in Linux for USB)

Doesn't work. If I today click on SATA I get a list of boards ranging from crappy USB-SATA (GL830 on Orange Pi Plus 2) over crappy native SATA (Allwinner A20) over mediocre native SATA (i.MX6) to nice USB-SATA (ODROID HC1) while the only devices that feature great native SATA (Clearfogs) are missing.

I bought two of them just to realize that they're based on crappy Norelsys chips (the reason why Armbian in the meantime does UAS blacklisting on its own -- the same happens on ayufan OS images for ROCK64 though there it's done differently). The JMS578 ORICO thingie looks different: http://www.orico.cc/goods.php?id=6355 Please read through this carefully again. The guy has one JMS567 and there's something wrong with it (queue size limited to 14 for whatever reasons). When comparing ASM1153 and JMS567/JMS578 they perform both pretty identical (JMS578 should be able to support TRIM but AFAIK there's still software support missing in Linux)

Hmm... I don't understand since this commit started to redefine LINUXFAMILY based on $something and when I got rid of the hardware detection stuff in armhwinfo relying on LINUXFAMILY being set to the value in board config files the problem started (and I only noticed recently testing with LanTest since performance was worse than months before). And I still don't have the slightest idea how a fix should look like since the root cause is redefining LINUXFAMILY based on $something and not code somewhere else trying to rely on LINUXFAMILY. How should this be fixed? Introducing REALLINUXFAMILY?

How should this solve the problem I was talking about?

Is not supported and as already said it makes absolutely no sense at all to use the dev branch if you do not want to contribute to Armbian in a reasonable way