06:04 <tkaiser> TonyMac32: does it really matter whether anybody listens or not when here in this 'community' basic terms like DVFS, cpufreq, IRQ/SMP affinity, ASPM, PCIe link training, coherent pool size, stability, security and so on aren't understood anyway?

06:05 <tkaiser> And just to get an idea about Igor bragging about 'Armbian developers are more or less the only one that are progressing somewhere'... how many patches to improve upstream support for RK hardware have you or someone else genuinly being part of 'Team Armbian' sent upstream to the LKML? Just a rough estimate...

06:06 <tkaiser> Tens? Hundreds? Thousands?

07:29 <Armbian-Discord> <I​gorPec> We all want this and more. You are again asking 3rd party, from your perspective, to invest more, hundred thousands of euros worth of time that is never possible to get back, just to be a smaller idiot from your perspective? Or a bit less to find, organize and lead enough interested part timers & volunteers. While feeling like a retard doing it - good luck. If all this "small" work can be done by volunteers

07:29 <Armbian-Discord> that pays for this party, why its not done already? Just lack of organisation, direction of activities? For who? For common goals? You? For scammers profits? For every day Joe that market will keep him unsatisfied - to buy more junk hardware - regardless of where we could push it up? For commercial competitions which is already sucking out as much they can? Stop wasting your and our precious time repeating this BS? Who, out

07:29 <Armbian-Discord> of this group, would not like to have a better, without compromises, coding practices and sort out all what is needed, which is just more expensive for our time ... time getting wasted for wrong causes? Some certainly & always will. Is coding art, business or something in between? If you want that something is sorted out for your professional levels, make a PR, maintain the code. Do not expect someone else will do it for

07:29 <Armbian-Discord> you when you lost interest. Stop this complaining / suggestion / "cheering" BS since nobody needs nor listen. If you want that this becomes more professional, a lot more from multiple directions has to be thrown at the community / open source in general. And towards the project. Wishes are cheap and anything to cover them just raises already big enough maintaining expenses that nobody wants to hear about. Dealing with

07:29 <Armbian-Discord> (repeated) wishes, which we can often classify as nothing but blackmailing, goes on that that bill too.

07:48 <tkaiser> Igor, how many patches originating from 'Team Armbian' to improve RK hardware support went upstream to the LKML? Less than 1, 1-10, 11-100, 101-1000?

07:48 <tkaiser> Just give me a number. I really don't want to waste your precious time.

08:01 <Armbian-Discord> <b​albes150> The whole paradox is that the vast majority of users (ordinary users, not geeks) who use these devices to solve their SPECIFIC tasks are deeply indifferent to having 100% of the power of these devices. It's good if they use at least 60-80%, but in real life it's usually 30-40% of the possibilities. Question. Why should I spend a lot of time (to study possible settings, choose the optimal ones, test and

08:01 <Armbian-Discord> constantly monitor changes, etc.) if no one will appreciate this work or even notice. Yes, I agree with you that it is useful and interesting to achieve the maximum from iron, but the question is at what price (costs \ the result obtained). Another nuance, earlier, when ARM was very weak (similar to how it was with the first 286 \386\486 PCs, weak, with a meager amount of RAM, etc.), yes, the issue of optimization was

08:01 <Armbian-Discord> relevant and in demand, but now, having 8 cores of 16 GB RAM, SATA \ NVMe, many will they notice the difference in increasing system performance by 5-10%? For them, the price is much more important. And it will be very good if they at least think about (and use) the criterion - zataraty \ the result obtained. I'm not blaming the users, it's an objective reality. Look at the rapid change with phones - from simple ones with a

08:01 <Armbian-Discord> tiny screen to the current monsters. How many people use at least half of their capabilities ? But everyone studies articles with an intelligent look, where they make comparative analyses of characteristics and so on and make a choice based on this.

08:05 <tkaiser> balbes150: it all boils down to ignorance again. ASPM is Active State PowerManagement, a basic principle of PCIe. Armbian is all about dealing with e-waste from the Android world (just check the devices supported by Armbian. No TI, no Renesas, a few NXP, all the rest is junk originating from the Android world.

08:05 <tkaiser> Android defaults are suited for Android use cases. Armbian is about Linux. Linux is about different use cases compared to Android.

08:06 <tkaiser> Setting ASPM to powersave with Android makes sense, with Linux rather not.

08:06 <tkaiser> As such adjusting this is one of the first steps to be done when exploring a new platform / BSP kernel.

08:07 <tkaiser> Prior to such basic optimisations that are well documented (check the ODROID N1 thread in Armbian forum for example or the summary I wrote for this project here recently wrt Rock 5B) the homework hasn

08:07 <tkaiser> 't been done.

08:08 <Armbian-Discord> <b​albes150> do you remember why complete crap (from a technical point of view) Windows 3.1 "won" (became commonly used) over OS2? How many car owners use 100% of their power (capabilities)? People should be deprived of cars for this ? 🙂

08:08 <tkaiser> In essence this is a 'board bring up' checklist: https://github.com/ThomasKaiser/Knowledge/blob/master/articles/Quick_Preview_of_ROCK_5B.md#important-insights-and-suggested-optimisations

08:09 <tkaiser> Could be adopted by Armbian in the form of such a list. New Android platform? What needs to be addressed? Ah, there's a list.

08:10 <tkaiser> The way Igor's brain works this ends up like this: 'You are again asking 3rd party, from your perspective, to invest more, hundred thousands of euros worth of time'. He isn't even able to understand that there's the solution on a silver platter but things this is asking for precious time of those 'engineers' here. :)

08:11 <tkaiser> balbes150: Ok, understood. So Armbian isn't about low-level optimisations. I'm fine with this as long as Igor stops spamming the whole Internet with his ridicilous claims about 'Armbian's optimisations'. Since 'at Armbian' simply nobody cares.

08:11 <Armbian-Discord> <I​gorPec> there are hundreds of solutions on the forum that were never integrated. and never will.

08:13 <Armbian-Discord> <I​gorPec> yes, because nobody cares and the project exists because we don't

08:13 <Armbian-Discord> <g​ambl0r> 🍿

08:14 <tkaiser> 'the project exists because we don't' ... don't what? Care?

08:16 <Armbian-Discord> <b​albes150> to use your information (on optimization) - I think it is reasonable to use it and perhaps it will be used over time, I have already tried to use something myself, but alas, there are only 24 hours in a day and there is not enough time for everything. If you help (give recommendations) I think it's real to use. I am not a specialist in such optimizations, and I may be wrong.

08:18 <Armbian-Discord> <I​gorPec> "the project exists because we don't care". Yes. Isn't it obvious?

08:21 <tkaiser> Ok, Igor. Then please stop your advertising Armbian would be about low-level optimisations since *obviously* it's not. The 'project' (or to be more precise its owner) doesn't care.

08:23 <tkaiser> This stuff *obviously* was just a pet project of Mikhail and mine. We both left the project in 2018 and maybe even for the same reason. Mine is a four letter word.

08:27 <Armbian-Discord> <I​gorPec> advertisement is not tech problem. you should know it. And low level optimizations exists, you know that too. the problem is in lack of their perfection.

08:28 <Armbian-Discord> <b​albes150> maybe I don't know something, so I can write nonsense. What prevents you from acting as an independent expert and, as far as possible, make recommendations on what can be improved\changed? This does not oblige to anything - we have expressed your suggestion \ opinion. Personally, I would be interested to test try as much as possible (time). Moreover, I have my own "personal" fork, in which I can freely

08:28 <Armbian-Discord> experiment and send from it what I consider useful to the general build system 🙂

08:30 <tkaiser> balbes150: Check https://forum.armbian.com/topic/22348-rock-5b-with-vendor-u-boot-vendor-kernel-pr-and-test-images/#comment-144518 "Armbian developers are more or less the only one that are progressing somewhere"

08:31 <tkaiser> I've just seen amazingfate taking puzzle pieces that were already there, combining them in a PR to 'support Rock 5B' in the Armbian build system and that's it. No progress whatsoever other than OS image that work exactly the same (slightly worse in fact) than those provided by Radxa.

08:32 <Armbian-Discord> <I​gorPec> I know we don't do nothing. I am just wasting your time

08:33 <tkaiser> Igor, how many patches originating from 'Team Armbian' to improve RK hardware support went upstream to the LKML? Less than 1, 1-10, 11-100, 101-1000?

08:33 <Armbian-Discord> <I​gorPec> and who are you to ask this?

08:34 <tkaiser> balbes150: there's still https://github.com/ThomasKaiser/Knowledge/blob/master/articles/Quick_Preview_of_ROCK_5B.md#important-insights-and-suggested-optimisations (seems for Discord communities every URL needs to be posted at least 3 times)

08:35 <tkaiser> That's more or less what we as community (not Armbian) found when working on RK3588 so far. You're free to adopt this.

08:35 <Armbian-Discord> <I​gorPec> IgorPec — Today at 10:11 AM there are hundreds of solutions on the forum that were never integrated. and never will.

08:36 <Armbian-Discord> <I​gorPec> answer to that question first

08:36 <tkaiser> But the way RK3588 is dealt with in Armbian is weird anyway. Since when did reinventing the wheel without need helped? As with RK3399 there are two BSP kernel sources now in the build system. One originating from Radxa, the other from Firefly. Makes not that much sense since all the fixes that have been incorporated by Radxa as reaction to my review miss in Firefly's fork.

08:37 <tkaiser> Igor, which question? Is 'there are hundreds of solutions on the forum that were never integrated. and never will.' a question?

08:37 <Armbian-Discord> <I​gorPec> yes. that is the question

08:38 <Armbian-Discord> <I​gorPec> i mean you should answer to that problem first

08:38 <tkaiser> Yeah, it was useless trying to talk to you already years ago. Your definition of stability and security are not compatible with mine. Now also the term 'question'. :)

08:38 <Armbian-Discord> <b​albes150> With your permission, as far as possible \ time, I will try to use.

08:39 <Armbian-Discord> <I​gorPec> cover expenses of that stability if you need it

08:39 <Armbian-Discord> <I​gorPec> just don't pass that problem to me

08:39 <Armbian-Discord> <I​gorPec> its not my personal problem nor a problem of armbian - its your problem. if you want it better, you invest into that

08:40 <Armbian-Discord> <I​gorPec> don't tell other people to deal with your shit

08:40 <tkaiser> Igor, you will never understand that you're at the heart of Armbian's real problem. You doing Igor things. You bored on a Sunday afternoon fiddles around with a bootloader, package it, throw it in the apt repo and on monday morning boards out there are bricked.

08:40 <Armbian-Discord> <I​gorPec> yes

08:40 <tkaiser> And this won't change. Since Igor doing Igor things. Being the project owner :)

08:40 <Armbian-Discord> <I​gorPec> that's it. that's all what i do and you are just jealous because you can't

08:41 <Armbian-Discord> <I​gorPec> didn't know i own open source

08:42 <tkaiser> Same with security. It's just a matter of time until you integrate a local privileges escalation again. And again just for fun like the last time: https://github.com/armbian/build/commit/f0f10a5b68aff3c766f2e8790ac4ce9f3c3e2160

08:43 <Armbian-Discord> <I​gorPec> you are repeating yourself

08:43 <Armbian-Discord> <I​gorPec> in 10 years of coding around this, i made a lot more mistakes

08:44 <Armbian-Discord> <I​gorPec> if you don't bring up anything new, you are again just stealing resources

08:44 <Armbian-Discord> <I​gorPec> and attention

08:45 <tkaiser> Sure.

08:46 <tkaiser> Open source can be fixed. Broken structures obviously not.

08:47 <Armbian-Discord> <I​gorPec> to my estimation, there are around 1000 x more people (like you) complaining then those that can do anything

08:47 <Armbian-Discord> <I​gorPec> speaking in general. regardless of the structure of our codebase or a project

08:48 <Armbian-Discord> <I​gorPec> but this is something you don't care

08:55 <tkaiser> 'cover expenses of that stability if you need it'. The problem is (which you're obviously not able to understand) that the source of instability and insecurity is just _you_. Not related to code base or anything other that could be fixed by an 'open source community'.

08:56 <Armbian-Discord> <I​gorPec> not, its not me. anyone that can push the code

08:56 <Armbian-Discord> <I​gorPec> stability and security are principles

08:56 <Armbian-Discord> <I​gorPec> practices

08:57 <Armbian-Discord> <I​gorPec> all this cost investing and you keep forgetting that you don't pay not even for amateur levels of services demanding (!) professional ones

08:57 <Armbian-Discord> <I​gorPec> and btw. Armbian is most likely the only Linux provider that tests boot loader and kernel upgrade within CI processes alongside with performance testings. All your fancy numbers could be abtain automatically alongside with visualization ... if we had time / resources for that.

08:57 <tkaiser> Yeah, not able to understand. Maybe stability has improved within the last years since all commits (especially yours) need to be reviewed. But back then when I quit you being in playground mode constantly caused stability issues just by fiddling around with stuff that only pleased you.

08:57 <Armbian-Discord> <I​gorPec> yes it was a playground and with resons

08:58 <Armbian-Discord> <I​gorPec> it was a project on that level

08:58 <Armbian-Discord> <I​gorPec> you still have many linux project that tests almost exclusively on users

08:59 <Armbian-Discord> <I​gorPec> most of amateur linux projects is simply run in hippy style

08:59 <Armbian-Discord> <I​gorPec> not obligations - we try the best but if it fails ... we will fix it once we can

08:59 <Armbian-Discord> <I​gorPec> we are far away from that

09:00 <Armbian-Discord> <I​gorPec> stability in overall changes with years because upstream is not totally random as it used to be

09:01 <Armbian-Discord> <I​gorPec> now someone even test what it sends upstream

09:01 <tkaiser> Another free suggestion: Integrate a simple 'armbianmonitor -z' call into this CI thing so stuff like ODROID N2 being on lower cpufreq with latest release can't slip through.

09:01 <Armbian-Discord> <I​gorPec> but even tested, due to quality and revisions changes, boot loaders will keep crashing sometimes

09:02 <Armbian-Discord> <I​gorPec> i will ask people you are paying when they can pick it up

09:02 <Armbian-Discord> <I​gorPec> there are many wishes already in the system https://armbian.atlassian.net/jira/dashboards/10103

09:03 <Armbian-Discord> <I​gorPec> waiting for donations

09:03 <tkaiser> Yeah, 'hundred thousands of euros worth of time'... same old story :)

09:03 <Armbian-Discord> <I​gorPec> average issue closing date / resources is closing 400 days

09:04 <Armbian-Discord> <I​gorPec> well if you know a better way, why don't you do it?

09:04 <Armbian-Discord> <I​gorPec> graph below - you like that kind of representations

09:05 <Armbian-Discord> <I​gorPec> and again this is not a complete picture as there is a lot more wishes and problems that aren't getting recorded

09:05 <tkaiser> LOL! Sure, I like graphs. That's why I point out sbc-bench being a tool that 'tries to produce insights instead of fancy graphs'.

09:06 <tkaiser> A ticket system is close to 'patch management' IMO. There are companies/organisations that patch their machines and there are those managing 'work not getting done'. Instead of patching they play patch management and those are the ones with ransomware :)

09:07 <tkaiser> Anyway, it's really just a waste of time but it's nice you confirmed few specific things.

09:07 <Armbian-Discord> <I​gorPec> haha, so you will be blackmailing me 🙂

09:40 <Armbian-Discord> <b​albes150> Question to the owners of NanoPC T4. Check the latest image with EFI. I am interested in whether the choice of which system\kernel to run works on the first EFI\Grub screen. https://disk.yandex.ru/d/VjPGWf2rVPW4uA

12:53 <Armbian-Discord> <b​albes150> please perform another check on T4. After starting the system, install the second media-current kernel by regular means (via apt or synaptic) (I pay attention, you can only install the media-* kernel versions). And check, the choice in the startup menu, the choice of a different kernel version. Please note, there is no need to do any manual (additional) manipulations on configuring the kernel, the scripts of

12:53 <Armbian-Discord> the kernel package will do all the work automatically (i.e. the installation principle is similar to a regular PC, select the kernel and run the installation). You should have two cores in your system, and you can choose which core to use at startup.

21:08 <Armbian-Discord> <p​rofbbrown> Tried disabling the FUSB chip in the device tree file, by setting the status to "disabled." But it made no difference in the load average.

21:08 <Armbian-Discord> <p​rofbbrown> Is there a way to find out what process is causing blocked I/O?