In reply to a post by aabloor:

SOOC manufacturers tend to assume you will be running something like Linux on their chips. Certainly out approach of an entire ground up OS, hardware drivers, networking etc is rare to the extend that some initially have trouble believing it to be true. But it really is.

Hmm.As a business model that sounds over ambitious for a relatively small company. Is your core expertise developing embedded systems or is it running an ISP network? If you are not 2 separate divisions with an arms length commercial relationship, such that the ISP is free to source its embedded systems elsewhere, I would not look at you as an ISP.

As for developing without Linux, you are again requiring 2 different core expertises, OS development and embedded network system development. There is a dichotomy on something like this between starting with nothing and building upwards or starting with Linux and cutting it down. The first course seems more suited to a large player, where the OS and the application development operate at arms length and you are forced to maintain abstraction between layers rather than taking [road to hell] advantage of the potential to abrogate abstraction when it gets in the way of an easy solution. As an outsider, I don't have the insight to what is going on with A&A, but the troubles reported here look like what I expect some time after strict layering of software has been abrogated.

Of course I could be wrong about the situation ...

It is an ambitious business model.

But this is (quite extremely) not our first product.

In the last 20 years, we have done hardware and firmware on the FireBrick Plus and Soho, FireBrick 105, FireBrick 2500, FireBrick 2700, FireBrick 6000, FireBrick 2900, and now FireBrick 9000. We have many thousands of units out there in the wild, not just with A&A customers. We did change architecture after the FB105.

In summary, we do have considerable experience in this field.

We are a company of between 20 and 25 people.

Some of them work on the ISP business (only).

Some of them have a split role.

And some are essentially FireBrick only.

We have people whose only job is FireBrick software development and nothing else. This is not a case of some people who know devops "having a crack" at low level firmware development, by a very very long chalk.

The two business activities are somewhat symbiotic. It would not really make any difference, other than adding admin overhead to try and split them up. A&A The ISP absolutely is free to buy hardware from wherever. Splitting them up really wouldn't change that.

I feel your reply may possibly (entirely reasonably) assume we have far less experience and track record than we do. We have been doing this for years. It is hard but historically we have punched considerably above our small weight.

We have a website that has some in-depth blog posts which should also highlight broad aspects of our approach www.firebrick.co.uk if not perhaps in this subject area. We cover mistakes we've made in the past, and how we've resolved them. We fully intend to document this current situation, once we are comfortable it has been resolved.

Example of such a blog : https://www.firebrick.co.uk/about/news/fb2700-psu-tr...

And a bit of general history : https://www.firebrick.co.uk/about/history/

Alex.

Edited by aabloor (Wed 24-Apr-24 11:39:57)

In reply to a post by aabloor:

It is an ambitious business model ...

I am not doubting A&A's experience - it is needed to get away with what I consider actually to be a low level of issues for the ambition you have. Obviously you are a long way with this, so I wouldn't be suggesting a switch to Linux, but I if I am questioning anything about your development it is the decision not to start with a Linux core and strip that down.

And I don't think that it is people who know devops "having a crack" at low level firmware development. One of the hardest things with some development is holding it all in one head, which can lead to breaches of abstraction - this is where abstraction carried out between layers owned by different people leads to a conversation where neither side knows too much about the other and a conversation between 2 people is far more effective in splitting a problem than trying to resolve it all in one mind. Yes, your size makes you nimble, but it can also place too much of a load on someone who understands both sides of a problem.

I think its worth re-evaluating your business model from time to time as what may have worked successfully for 20 years may not work for the next 20 years.

No more LNS drops for me since 7th April 2024 - now that the FB9000 firmware has been reverted.

I am so glad to no longer be a beta tester, and once again have the reliable connection that I pay for!

- Perlen

I have had no issues since FTTP circuit activated. (week 3 April)

Edited by Chrysalis (Sat 04-May-24 01:48:17)

In reply to a post by perlen:

I am so glad to no longer be a beta tester, and once again have the reliable connection that I pay for!

Maybe they could consider some kind of discount to encourage use of beta LNS instead of foisting the updates on the unsuspecting.

They publish how to use the "test" device. No discount mentioned.

I am aware, but it seems they've said part of their issue may have been not having enough folk on the test LNS before it went to live; there isn't any incentive at present to be on the test server (particularly given the premium pricing). Some kind of discount might encourage more to sign up for the test LNS.

In reply to a post by jimbof:

I am aware, but it seems they've said part of their issue may have been not having enough folk on the test LNS before it went to live; there isn't any incentive at present to be on the test server (particularly given the premium pricing). Some kind of discount might encourage more to sign up for the test LNS.

Something sensible might be divide say 20-30% of the monthly sub by 30 and then add a automatic compensation scheme, that will credit the account by that amount for every 24h when on a test LNS, this would also apply during periods when a open incident within their control is affecting service. If AAISP ever decide they dont need people testing, or they decide the testing after all isnt as valuable as they say it is then they could avoid paying this compensation by capping max connections on the test LNS or take it down.