tkaiser

Members
  • Content count

    3408
  • Joined

  • Last visited

About tkaiser

  • Rank
    Embedded member

Profile Information

  • Gender
    Not Telling
  1. For the 3 battery logos I would strongly recommend using those from here so users don't get confused about different charging 'behaviour' based on OS image running. Wrt our boot logo my favourite was bootlogo-armbian_blue_1365_767.png from http://kaiser-edv.de/tmp/NumpU5/ but in the meantime I think it's too large. Now I think we should use official wallpaper instead: (added some noise to compensate for TN panel crappiness)
  2. Are such assumptions backed by anything or at least some evidence? I mean I run here an OPi Zero 24/7 seeding Armbian torrents with a 128 GB Samsung EVO+ powered by an USB2 port of my router which is known to NOT provide more than 500 mA.
  3. Well, not entirely true. If a device comes with a Micro USB connector to be powered that is encouraging users to use crappy cables (made for 500mA max with insanely thin cable diameters) and crappy phone or 'smart' chargers (not delivering more than 500mA for example). So powering is always a problem with Micro USB just due to the fact that people are not aware that it's a problem (and while an electrical engineer would never think about stuff like that average users tend to use pretty bad powering equipment as soon as a device is equipped with Micro USB). Wrt SD cards: Fake/counterfeit cards do exist, are everywhere and it seems to get even worse these days. Every list of 'known cards' is therefore pretty useless unless you find a way to reliably differentiate between fake and genuine cards (I don't know one and the only strategy these days is to buy SD cards from big retailers that refund you without asking questions)
  4. Wow. And you think the sort of hardware acceleration possible with legacy kernel will speed up web browsing? It will not. Crapboard R1 is just a perfect example for numerous design flaws paired with surreal high expectations at the user side. And maybe most hours of life wasted on workarounding the many issues by so many people. I still think Armbian should ASAP phase out support for this failed board. Please let's stop now since this is really off-topic here. It would be great if you could post a mini tutorial in a new thread showing how this device can be operated as a router (solder tutorial and pictures of R1308 with resistor soldered) and provide some evidence that this works now and WAN and LAN ports are truly separated at all time if not configured differently otherwise.
  5. Board bring up is the less problematic part compared to board maintainance/updates. I still think Armbian needs a testing/beta branch so surprises like broken networking after just an usual 'apt upgrade' on a specific device (I would like to kick out of Armbian rather sooner than later) can be avoided. But I don't see us moving into this direction at all. Quite the opposite.
  6. As everyone else. This Roseapple Pi fail has been called 'Lemon Pi' in the beginning (the better name BTW) and has never been sold. Shouldn't matter. Phasing out support also doesn't mean that current OS images will stop to work. It's just clearly marking a board as not supported any more and not providing kernel and u-boot updates any more via apt.armbian.com so we can try to focus back on development and not dealing with crappy hardware. Stopping support for a board or linux family (S500) simply means we don't need to waste further time on testing (new releases, architectural changes and such stuff) or support. I would move those boards from download page to 'unsupported' page listing them all and keep latest working OS image in archive directory or dl.armbian.com. The board's config file should IMO be renamed from .conf to .unsupported (just to document that there was support for this board once, a new line in config file should point to online ressource where reasons are explained why support has been dropped). So in case in maybe 2 years Actions Semi's S500/S900 mainline support evolves we might easily reconsider the decision and rename .unsupported back to .conf then and adjust sources. BTW: This 'unsupported' page can also be used to announce no Armbian support (yet) for new hardware (eg. crappy BPi M2 Berry) using the same mechanism to display the reasons why this device is currently unsupported. So instead of dealing with 10 new threads a month asking for 'When Armbian cure my M2 Berry?!?!11!' users might pro-actively find the answer if they search for 'Armbian M2 Berry' already (partially kidding -- @Igorwould you mind trashing xforum.armbian.com since it pollutes google hits a lot?)
  7. Where did you spot those (at least here I don't find anything with 'hardware acceleration': https://dl.armbian.com/lamobo-r1/archive/)? BTW: Aren't underpowering issues caused by a crappy board design and video stuff with an outdated legacy kernel (and the whole idea to run a graphics stack on a device used as a firewall or router!) really on topic in a thread dealing with mainline kernel and DSA?
  8. How much did you pay for it?
  9. Well, creating/making such images isn't the hard part but how to deal with 'installation'? Adding a cp call to family_tweaks function or should we add the logos to board support package (same with the various 'Pinebook only' services/settings)?
  10. ...workarounds should maybe addressed at the NetworkManager level too (nmcli can be used to add a so called 'Cloned MAC address' to a connection profile and with nmtui --> 'Edit Connection' it's that easy that everyone should be able to manage this). The other way to create something like /etc/network/interfaces.d/eth0 as @umiddelbsuggested (taking Ethernet out of control of NetworkManager) will work of course too. Just to prevent the next step happen (NM blaming/whining). This is not a NetworkManager issue, it's about users misusing so called 'devel images' for production purposes, ignoring warnings and struggling with them. There are fully supported legacy Armbian images that are not marked as 'experimental' and this whole thread is as unbelievable as all the others dealing with the same 'problem' before.
  11. Doesn't work as Zador already mentioned. Users don't read stuff like 'you agree that this is experimental and you don't get any support'. They open up new threads every day and get angry if stuff that worked yesterday doesn't work today after latest upgrade (which is EXACTLY what is to be expected when using using 'nightlies' especially after kernel updates and stuff like that). They also fail to understand which efforts are needed to deal with mainline kernel images (upgrade process included) as long as the 'WiP' stuff is not somewhat stable (but since Armbian doesn't have a FAQ where we could add an explanation maybe some understand...) Anyway: It's also about expectations. Different devices, different user groups or 'target audiences'. If someone in 2017 buys any of those more recent Bananas this is a clear sign that he did not spent a single second on research first (just visit their forums: it's all about 'this totally sucks'). Then this specific vendor is not able to provide correct information, specifications or even schematics. Maybe they're too careless, too stupid or it's just a strategy (focussing their whole business on stupid people). Please read this about this 'M2 Berry': http://forum.banana-pi.org/t/banana-pi-bpi-m2-berry-quad-core-single-board-computer-with-allwinner-v40/3312 (archived version) They do not even give a shit about the SoC used (R40 vs. V40 -- both are more or less the same but it's just weird to talk about V40 and show pictures of R40, but maybe this single guy doing all this 'documentation', 'specification' and 'announcement' stuff is just not able to care about anything important or at all?). Anyway: I'm so sick of dealing with such crap that I think we should immediately think about no more releasing those absolutely useless 'nightlies' any more prepare a board phase out process (to get rid of shitty hardware we started to support by accident, eg. Actions Semi S500 boards) stop stupidly trying to convert Armbian project (good, secure and stable OS images) into a board bring up adventure (crappy and instable OS images adding more and more questionable hardware and frustrated users)
  12. Nope, this is not SATA here but the most crappy USB to SATA bridge found on any device. Please do a web search for 'crappy GL830' for details. Of course not, boards with GL830 aren't suitable for NAS purposes and should be avoided.
  13. May I introduce BPi M2 Berry? Inherits all the shitty support/software situation from BPi M2 Ultra but adds Micro USB crappiness to it: http://forum.banana-pi.org/t/banana-pi-bpi-m2-ultra-bpi-m2-berry-new-image-2017-05-25-raspbian-jessie-preview3-bpi-m2u-sd-emmc-img/3306 Please see at the bottom picture how thick the power cable inserted into the Micro USB jack is. Of course those morons do not test with an average Micro USB cable with the usual resistance way too high (that's what 99 percent of their users will use) so they repeat what happened 1.5 years ago with Banana Pi M3: While all their users out there struggled with crappy Micro USB and had even to solder a different power connector to stop this board from crashing and the other under-voltage symptoms those SinoVoip 'engineers' tested all the time only with perfect cables connected to bench power supplies and told users that they're wrong. Soon this forum will get flooded by Berry users asking for software that makes their BPi Berries stable if we don't take countermeasures.
  14. I highly appreciate you doing this and I'll also invite you to become moderator of 'Random Ubuntu flavours as build system chaos' subforum. You should keep in mind that you'll soon deal with important questions like 'Why is Linux Mint not supported?! It's based on Ubuntu!!' and 'What about Bash environement for windows 10 with xenial distribution' and other ways to deal with everything that smells like Ubuntu. Of course you should first test through all 22 linux families currently supported with all kernel and u-boot variants (that's the funny thing with that: we have some combinations where u-boot needs GCC below 5.4 in 32-bit while the kernel only compiles with 64-bit GCC 6.1 or above). Of course you also need all boards to test through (maybe a Kickstarter? The few hundred bucks for the hardware aren't the problem but your new full-time job will be) Maybe that's already enough to understand that this 'very little time' is better spent on real improvements? Besides that we recommend a virtualized environment for OS images for a single reason (not mentionend anywhere yet except forum): If there's ever just a little error when dealing with image creation (happens as root using dd and trying to overwrite sectors of the image) the build system can overwrite your whole OS or at least renders it unbootable! The main reason people like to use something else than Ubuntu 16.04 is that they already run something else that's Ubuntu-ish. And that's bad and should be avoided. So forcing users to setup an own virtual machine wit 16.04 is already fighting lazyness and preventing a mess if something ever goes wrong.
  15. [x] done. @ssuloev: BTW: I didn't want to be offensive above. Just give the other devs the idea that 'trying to be friendly/polite' is sometimes wrong. Overreading/ignoring warnings is just human (even providing partially wrong information when requesting support) and if recommendations turn into requirements (as it's the case with 'Ubuntu 16.04 only' now) then we should switch warnings into errors too. Saves everyone time and hassles. And also we should rethink answering questions in the forums. Now we have an infrastructure where commits below https://github.com/armbian/documentation almost immediately show up on https://docs.armbian.com. So when questions arise we should think twice about why (eg. 'why 16.04?' Nowhere answered below docs.armbian.com but multiple times in the forum) and then prefer to commit an unstructured entry to a yet not existing developer and user FAQ, wait until it shows up over at docs.armbian.com and then post a link to it?