pfeerick

Moderators
  • Content Count

    145
  • Joined

  • Last visited


Reputation Activity

  1. Like
    pfeerick reacted to chwe in Web page(s) redesign   
    To be honest, I'm not really familiar with WordPress, but this should be possible without problems. Maybe not 'anyone' but you could give 'limited rights' to the people which are responsible for the content of the webpage.  I'm more the 'DjangoCMS/Bootstrap guy' but this is more a 'personal preference', I'm sure WP can do this as good as Django. 
     
    I don't think that we should 'divide' the community into an Armbian-Blog and Armbian-Forum fraction. But why not use those forum sections (e.g. tutorial subforum) as a 'peer-review' place for interesting tutorials with discussion and when a tutorial is 'peer reviewed', we generate a tutorial on a 'tutorials.armbian.com' page outside from the forum (without possibility to comment, but with a link to the forum post).
    For example:
    SBCs as NAS is a evergreen topic. It doesn't really belong to armbians documentation, but a Tutorial which summarizes the performance of boards (e.g. USB2 based, all 'sort' of SATA based, USB3 based etc.) is something people would recognize. This tutorial can be edited when a new board which fits in this use-case came up (with discussion in the tutorial part of the forum). I think the armbian community has a lot of knowledge on various fields related to 'computer science' let's try to make this more visible.  Best distro is every time an opinion...  Things we shine: Support, support, support, maybe sometimes a little bit harsh (when people are to ignorant) but on most questions you get an answer to your question within 24h. That's even faster than most answers from the customer support of a *random company*. 
    But we don't shine on 'educate our customers' (e.g. a lot of people still think: If I get mali to work, my SBC could be the cheapes & best multimediacenter cause mali is the SBCs 'graphic card' and the 'graphic card' is needed for HW accelerated video decoding).
     
    Be careful about direct democracy we (the Swiss) are quite fast upset if you're against it...  I suggest forking the 'armbians upgrade policy' to a different thread to keep this one where it belongs too: Web page(s) redesign
    --> Cause I think the majority doesn't expect this discussion in a thread where it's about web page redesign. 
     
  2. Like
    pfeerick reacted to TonyMac32 in Web page(s) redesign   
    Well, I do agree we need to stick to web page topic, the other stuff is an elsewhere conversation.  
     
    So I spent some time in the documentation github, I saw changes go live instantly on the documentation page, nice.  What is the rate of update on the webpage itself?  I added the ethernet issues to the potato board notes, it wasn't there initially, but was several hours later.  I like the GitHub --> Web page link, that allows for direct community contribution via pull request, and allows for rollback of mistakes.
  3. Like
    pfeerick reacted to chwe in H6 boards: Orange Pi One Plus, Orange Pi 3 Plus and Pine H64   
    Did you open the box? Never spot any pictures of the PCB from this box...
     
  4. Like
    pfeerick reacted to Icenowy in H6 boards: Orange Pi One Plus, Orange Pi 3 Plus and Pine H64   
    Unfortunately the DRAM cannot even be initialized on this board.
     
    Yes, quite prototype ;-)
  5. Like
    pfeerick reacted to TonyMac32 in Web page(s) redesign   
    I have thrown myself out of the forums at least 6 times today by clicking on the "Armbian" banner image.  
  6. Like
    pfeerick reacted to TonyMac32 in Web page(s) redesign   
    I agree, but wish we had a way to "document-ize" the tutorial after all the discussion.  You get 40 pages of talk on a tutorial and it's easy to miss the important parts.
     
    Yes, there is.  I think we run into trouble that there aren't many maintainers to begin with, and we range from " This is good enough I don't need feedback" to "I want 100% absolute direct democracy on every decision".  This is difficult, and there are pros and cons to both.100% direct democracy does quite literally mean nothing gets done in a reasonable time, but everything will be more stable.  "Good Enough" gets you more bugs, but also more on-time releases and a sense that you're "doing something" to the general public.  (See the criticism Debian gets about their definition of "Stable")
     
    There is one thing I can say that is hard to dispute:  I can test something pretty thoroughly on my hardware in my laboratory with my equipment.  That doesn't mean it's going to work for anyone else repeatably.  So I test, and I commit the changes.  My changes are immediately live, there is no means to "trial" a change.  This is a discussion for another thread, but we should have a stable "release" branch that only gets updated for bugfixes.  Then our download page would have "Stable Release" and "development" images.  People want to use dev images?  Ok, but know that a 5.37-beta release may not be stable, even if it is a legacy kernel/etc. 
     
     
    For the Website: I think a CMS is best.  However, if the primary maintainer of the website is not fond of that idea, then a set of templates and a github would be a wise alternative.
  7. Like
    pfeerick reacted to zador.blood.stained in Web page(s) redesign   
    The thing is - forum.armbian.com is a separate site, not part of www.armbian.com. Logo on the forum should go to the forum index, not to www.armbian.com index. Same as dl.armbian.com logo goes to dl.armbian.com index, top left corner of docs.armbian.com links to docs.armbian.com index.
    To compare: if you are using Google services - the "Google" logo in top left on docs.google.com, drive.google.com, play.google.com, mail.google.com, etc. doesn't link to www.google.com but to the respective service start/index page.
  8. Like
    pfeerick reacted to Igor in Web page(s) redesign   
    Linux kernel development is anarchistic and our work is involved, dependant and related to this organizational type. Adding too strick wireframe and being harsh where is absolutely no need might be more damaging ... and a waste of time if you like that kind of word form. Scaring people not to come out with their ideas because somebody will bark at them how stupid they are might be also a waste of time. And damaging. Most people around the project are volunteers after all and demanding ultimate compliance won't work. Being a pro/cash has little effect on this either.

    Talking and discussing every possible matter consumes human resources which, frankly we don't have in indefinite capacity. Nobody has. Somebody has to lead and coordinate this web redesign and until this is mostly on me, I will resolve minor disputes instantly or I will not deal with this in any way. This is not a military precision stuff! Why do we need to panic? It's plenty of time, this is not print media and mistakes can be fixed. 
     
    And I will for sure do more mistakes in the future. Perhaps even repeat them, which I hope not.

    If you think everything is waste of time, take a break from extreme specifics ... even this can be considered as a waste of time from a radical point of view.  

    You have possible future boards in the dedicated section and there is a place for discussion if needed. There is no rush - take time. It's your right to write down that all boards sux and is pointless to deal with it. Should this change anything? Not necessarily and it should be this way.
     
    Can we now stay on this topic?
     
  9. Like
    pfeerick reacted to chwe in Web page(s) redesign   
    It's not uncommon that 'Home' isn't visible on a websites navbar,  but the logo is linked to it (said someone who was on armbians main page more than 6 times today.. ).  As soon as you've a template page it's annoying to program exceptions... 
     
    IMO this should be discussed in another thread. Otherwise, we fill this one also with a lot of stuff which doesn't belong to the topic.
  10. Like
    pfeerick reacted to chwe in Web page(s) redesign   
    I'm not sure if we need this carousel on the first page (R1 picture in the draft).  A small "news feed" should also do the job not? Downloadpage might be a little bit confusing (status & release). IMO only the 'Deprecated' flag is needed, on all other boards, you see from the release (testing, stable etc.) the status of your board.  A small 'getting started' guide on the first page is a good idea to avoid the major issues when starting with armbian.
  11. Like
    pfeerick reacted to Piv Klit in Web page(s) redesign   
    1. How about a uploader top100 to motivate users to share bandwith with torrents ? and that way limit your bandwith use on your servers ? (if it´s a problem)
  12. Like
    pfeerick reacted to zador.blood.stained in Web page(s) redesign   
    I just wanted to say that using those expressions as filters/tags is misleading.
     
    I'm not sure that UX people that are not familiar with SBCs can understand what and why we are discussing some things. So, again, ideally we would need a CMS with visual design being as close as we can get to the current one + enhancements suggested in this thread.
  13. Like
    pfeerick reacted to TonyMac32 in Web page(s) redesign   
    I think how to categorize the boards is a separate discussion, I'd link it in closely with the matrix of kernel support I've mentioned elsewhere, then that could be searchable via a specific function (like a filter:  "I want a mainline supported USB3 Gb Eth 64-bit quad core")
  14. Like
    pfeerick reacted to Tido in Web page(s) redesign   
    I also like Zador's idea for the download section.
     
    This I don't understand. I always click  for SoC and if it were then in alphabetical order, would be fine by me.
    H3 rush, is ending. H2, H5 and H6 is coming so the quantity of SBC is to me small enough per SoC, that I do not see the reason for a search.
    Unless you see indeed a problem.
     
    CMS: I agree that it would help. So Igor could count on the help from the community.
     
    Docs: I was wondering if we could have another step in it:
    Documentation Tutorials  - for example three lines intro text and a link to this or just a tutorial for xyz. This way it wouldn't get lost in the daily chats.
  15. Like
    pfeerick reacted to chwe in Web page(s) redesign   
    1. Navigation: unified on all pages. 
    I think this could easily be achieved when the whole page is maintained with a CMS-System. I don't know how you do it at the moment, but since I maintain some pages with DjangoCMS, I would never go back to not CMS maintained pages. Adding additional pages is a 30 seconds task, they show up in the menu on the right place - it just works.  Since I work mostly with 'standard' bootstrap elements, I can pick them by one click instead of code a single line in HTML.
     
    3&4 Download selection: search on devices must be somehow implemented Download board page: rethink and rework
    IMOH the download page looks nice but isn't easy to work with. Instead of 3 pages (stable, WIP, Deprecated), we should have one Download page with a better 'search engine' and a status for every board (needs some adjustments to program but would save us a lot of user questions - if I've time I'll do some testings to show what I think how this could look like). 
     
    5. Documentation under common theme
    As long as we use  MkDocs, I'm not sure how easy it would be to integrate this into a CMS. I like the 'Read the Docs' template for the documentation, not sure if this needs to be unified. 
  16. Like
    pfeerick reacted to zador.blood.stained in Web page(s) redesign   
    I think that download pages and device list pages should be redesigned and we should take some popular websites as examples for the layout.
    1. For download pages we could have a device picture on the left, stuff like download buttons to the right of that picture and other stuff below that (i.e. Aliexpress product page, Amazon product page).
    2. For the device list pages we could have a list layout - one device in a row, picture to the left, name and short description to the right (i.e. Youtube channel videos list page in the old design).
     
    To clarify - I'm not talking about copying any design features, I'm talking mostly about changing the layout to fit more important info on the page that is visible without scrolling and to improve the UX.
  17. Like
    pfeerick reacted to tkaiser in Rock64 nightly image   
    Should be fixed now in latest release: https://forums.resin.io/t/etcher-v1-2-1-release/2265
  18. Like
    pfeerick reacted to zador.blood.stained in Rock64 nightly image   
    To catch write errors that are not reported to the writing program.
     
    Please don't try to tell this to manufacturers of low-end SD cards and USB thumb drives. Writing to block devices doesn't have any feedback mechanism that would ensure that data was written correctly. And while some SD cards were becoming read-only after detecting internal issues, other cards just silently failed to overwrite specific blocks.
     
    I use a custom write-with-verify procedure integrated with the Armbian build system, and while when I had issues with the card reader writing was aborted with I/O error, writing to bad SD cards can only be detected by reading back and checksumming the data.
  19. Like
    pfeerick reacted to TonyMac32 in Rock64 nightly image   
    I built a cosmic ray detector once, good chance to play with photomultiplier tubes.  However it's hard to be sure unless you've tuned it right, random gamma events from the long decay chain of Radon, for instance, can make a mess of your data and make you think the cosmos is even noisier than it really is.  The important part about them though, is that they don't come from here, they also don't come from the sun, by and large.  And bit flips in extremely high density media has a lot more to do with the probability of an electron existing where you think it does, or not. 
     
    Google things like "hot carrier injection" (Safe for work, I promise ), and electron tunneling.  Just because we will it to be so with our machines, sometimes nature gives us a hand gesture we wouldn't want our children to see.  And sometimes, the carriers don't stay "stuck" in jail where they belong.
  20. Like
    pfeerick got a reaction from tkaiser in 5.35/5.36 bug / questions collection   
    Confirmed on my Orange Pi Zero w/ 5.36/legacy. After some digging, the extra
    [ ! -z "${SocTemp##*[!0-9]*}" ] on https://github.com/armbian/build/blob/master/packages/bsp/common/usr/bin/armbianmonitor#L346 that Igor added to make Soc readings more resilient with badly behaved kernels is the culprit.  I've added an issue for it, and some explanation as to what broke.
     
  21. Like
    pfeerick reacted to tkaiser in 5.35/5.36 bug / questions collection   
    All armbianmonitor thermal read outs are broken on at least pine64/legacy and odroidxu4/next
  22. Like
    pfeerick reacted to Igor in 5.35/5.36 bug / questions collection   
    At least that is correct  Only BSP package was updated and at least most non-cosmetic problems were fixed ... Well, we need yet another mini updated. 
     
     
    There are only experimental 4.13.y builds and yes its planned when ready and tested.
     

    That is completely normal.  SD card content is left as is. We only alter boot environment when SD card is needed for booting.
     

    We only fixed bugs inboard support package scripts. There were no kernel updates and this problem need to be investigated. It's nothing critical so you can normally use the board.
  23. Like
    pfeerick reacted to tkaiser in 5.35/5.36 bug / questions collection   
    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...
  24. Like
    pfeerick reacted to zador.blood.stained in 5.35/5.36 bug / questions collection   
    It won't solve the problem right away but it would be harder to miss such changes in a small file rather than in a 80+ lines long function in a 450 lines long file.
    Regarding solving the problem - IMO we should push a bugfix update in a week, replacing at least board support packages - this will include armhwinfo fixes and will properly mark images as "stable" rather than "user-built".
  25. Like
    pfeerick reacted to zador.blood.stained in 5.35/5.36 bug / questions collection   
    As an example - as I proposed some time ago: platform specific performance tweaks go to a function in config/sources/$LINUXFAMILY.conf and are maintained there, this function is "extracted" into a separate file that is included by /etc/init.d/armhwinfo
    Same with platform specific firstrun tweaks where they are required.
     
    this block (IMAGE_TYPE related) can be moved to line 260 and this should fix the problem.