Just a test

[rooted]

 

 

 

I'll just leave the public download statistics link here. I'm not an expert on hosting prices in EU, but you need to take into account both the storage space and monthly traffic.

Edit: clarification - this is daily stats that don't include torrent traffic.

 

That is a lot of traffic but you don't have to host the downloads, that's why I said necessarily. You can use sourceforge to host all the files, and you currently use torrents which is smart.

 

Thank you for sharing the information, it is interesting to see.

 

are you kidding me, do you think armbian is generated by some magical artificial intelligence?

Or do you understand that ALL together spend about 200 - 500 hours a month into armbian, most of them in Europe and North America. Let's take just 200h x 70 Euro = 14 000.- 

So, who cares about server cost, but it would be very nice if you (and others) also donate what you can to "at least" support server cost.

If a company uses for its products it would be nice they send quarterly an amount, just like they do for Microsoft or Adobe products.

 

I didn't realize there was so much traffic but file hosting can be had for free being Armbian is open source. I was strictly speaking of the website when I said 100/month.

 

I think hosting fees is very relevant since that money can be used elsewhere, especially since it seems like it must be expensive currently.

 

[sfx2000]

On 1/21/2019 at 3:19 PM, tkaiser said:

I confirm that provided information is true, complete and accurate.

 

Everyone is allowed to vent - in a responsible and respectful manner - does reflect on the state of the project and the challenges that should be addressed and the opportunities moving forward.

 

The fact that this thread is even here - well, that's a sign for change, as normally this should be resolved with the project primaries over email/slack/irc/chat whatever...

[manuti]

@tkaiser are you deleting the main part of your comments in this forum?

[chwe]

16 hours ago, sfx2000 said:

The fact that this thread is even here - well, that's a sign for change, as normally this should be resolved with the project primaries over email/slack/irc/chat whatever...

it should be addressed public cause it is a public issue.. I prefer to have it this way. For sure there are topics which are dicussed in a more 'private' space but this is one which affects users & maintainers and IMO it's important..

 

16 hours ago, rooted said:

I didn't realize there was so much traffic but file hosting can be had for free being Armbian is open source. I was strictly speaking of the website when I said 100/month.

the site/forum is just a 'side-product' of https://github.com/armbian

if the side-product now takes too much time.. the main 'product' - providing a stable reliable OS for arm SBCs, get worse. Means 'the great community' isn't as attractive anymore cause images constantly break. IMO the only rational behind 'stricter' forum-rules must be that it reduces the time for those who answer to the topics to find a solution. If a new forum-rule or tool doesn't fulfill this, drop it. If it helps to reduce time for support (and doesn't make support worse) keep it.

 

[TonyMac32]

Like most things there needs to be a balance, and where there is a balance, few of anyone is truly pleased with the outcome because it means compromise.  The compromise is reduced with more active participation all around. 

 

Now, who is participating?  

 

-Vendors: Almost every vendor has some software team, or they pay for one.  They could spend more time making sure their hardware is well supported here directly, or indirectly upstream (Libre Computer does well here, if only Amlogic wasn't playing games with their firmware)

 

-Advanced Users: OMV-like special distros, products with special hardware where our build system would be advantageous, etc.

 

-Users: buy the board, try our software, ask for/provide help from/to others.  Very important for a project, a bit lacking here.  Of course the bulk of users come from the RPi train and, because they don't care to improve the hardware support, can talk to users all day.

 

Targeting a group in this requires time of its own, but honestly we need the feet on the ground.  It's a paradox, @tkaiser disagrees with the terminology of support, I agree to a point, but also, @tkaiser is adamant about refusing to add shitty boards because of support issues.  I think we are all in this boat, I love seeing what Armbian runs on, hate getting insane questions or dealing with SD card issues, but also don't want to say (or really see someone have the ultimate authority to say) "no, you get no help because we hate your board".  A prime example is the Tinker Board, which somehow has failed to create the support issue even I thought it would despite a respectable download number. 

 

For other issues that have been a gnawing problem:

 

Decouple the kernel updates from the image type.  That way if we move our "next" images to 4.19 from 4.14 is doesn't cause a meltdown.  I'm going to guess this is on the "very complicated" side, but I think boards should maintain kernel number with only patch level increases unless the user specifically chooses to change.  The tag "default, next, dev" would be the build recipe only, ideally.  We require the diagnostic output that gives you the kernel anyway.  (Tinker has to have 2 dtbs because of adding overlays, and mismatch between vender kernel dtb name and mainline). Odroid C2 can never have a kernel update for "default" because there is absolutely no way to properly migrate from 3.16 to 4.19+ .  Etc.

[sfx2000]

3 hours ago, TonyMac32 said:

Decouple the kernel updates from the image type.  That way if we move our "next" images to 4.19 from 4.14 is doesn't cause a meltdown.  I'm going to guess this is on the "very complicated" side, but I think boards should maintain kernel number with only patch level increases unless the user specifically chooses to change.  The tag "default, next, dev" would be the build recipe only, ideally.  We require the diagnostic output that gives you the kernel anyway.  (Tinker has to have 2 dtbs because of adding overlays, and mismatch between vender kernel dtb name and mainline). Odroid C2 can never have a kernel update for "default" because there is absolutely no way to properly migrate from 3.16 to 4.19+ . 

 

You make a very good point - in a past life, I was part of a team that did an internal distro that supported multiple boards (same arch ARMv7a) - much more limited in scope compared to armbian, but similar in that we supported different ARM variants.

 

uboot and device tree were board specific to onboard a new board into the distro - kernel was the same...  uboot and device tree, once sorted, do not change very often.

 

So it was relatively straightforward to support Cortex-A9/A7/A12(17)/A15 and Cortex A53 (running in ARMv7A mode with 32-bit userland). Userland was the same across all boards - not upstream from debian or whomever, and built to a common set of features - wasn't super optimized perhaps, but it did make things easier for a CD/CI pipeline...

 

(but what about DT? well, DT got rebuilt every time, and we closely managed it, but all targets got every board/configs dtb file so while images were board specific a bit, changes were minor enough)

 

The basic build was a barebones kernel, glibc, and rootfs running busybox - which was enough to pull in the rest of the userland, including containers (we used lxc) - so with the same basic BSP, we could purpose the boards towards Set Top Box, Network Attached Storage, or even as a Router, all based on the containers loaded

[JMCC]

On 1/24/2019 at 8:03 PM, TonyMac32 said:

I think boards should maintain kernel number with only patch level increases unless the user specifically chooses to change.

Totally agreed. It is very likely that a user's project depends on features that are only available in a certain kernel and not in others. That is particularly true when it means jumping from a kernel that is actively maintained by the vendor (like Hardkernel's 4.14 for the XU4) to a vanilla mainline.

 

Practical examples: A user that has OMV installed on his Odroid HC1 with disk encryption on 4.14 kernel, would lose HW crypto support if upgrading to 4.19 (I think @tkaiser already pointed this out). Or if they have an Emby server with HW transcoding in that machine, it will stop working with the move to 4.19. Or if he has a media player/gaming station for the kids on a XU4. Etcetera.

 

Well, I think everyone is clear on this point already, I just wanted to show my support for the idea of being very careful when making big kernel moves.