I just remembered that there is a bug list out there. 

So how do we get 150,000 new QB64 users.  With sales of 30 Million unit's in 2019, who knows where that number is today with covid locking people at home.  And any available unit being scalped at ridiculous prices.  Or any online listing announcing stock all gone within 15 minutes.  The little sought after PC is the Raspberry PI.  If we can get 0.5% of the user base to install it's 150K new users.

So what will it take to get QB64 listed in the Raspberry Debian Repository ?  There are many locations the where repositories are holding code.  I could be wrong but all we need is one developer to compile and post a image of QB64 and support files.  I now the install script exists to compile QB64 but it's not "ALL" new user friendly.  I think we need to "APP" QB64 into a repository package.

So can we make this happen ?  I would love to help but I am too newbie even after a couple of years using Linux to know how to do this.

Thanks
BTW, With all the competition QB64 has under windows.  Nobody has listed there basic in the repository.  We could be a first.
 

So how do we get 150,000 new QB64 users.  With sales of 30 Million unit's in 2019, who knows where that number is today with covid locking people at home.  And any available unit being scalped at ridiculous prices.  Or any online listing announcing stock all gone within 15 minutes.  The little sought after PC is the Raspberry PI.  If we can get 0.5% of the user base to install it's 150K new users.

So what will it take to get QB64 listed in the Raspberry Debian Repository ?  There are many locations the where repositories are holding code.  I could be wrong but all we need is one developer to compile and post a image of QB64 and support files.  I now the install script exists to compile QB64 but it's not "ALL" new user friendly.  I think we need to "APP" QB64 into a repository package.

So can we make this happen ?  I would love to help but I am too newbie even after a couple of years using Linux to know how to do this.

Thanks
BTW, With all the competition QB64 has under windows.  Nobody has listed there basic in the repository.  We could be a first.
 

Is this a serious question?  If so, you need people with the PI devices who also support QB64.  PI issues would need to be resolved and the setup process would need to be documented.  Then you would need people who understand the PI implementation who are willing to answer questions.  I don't even know if there is a roadmap for QB64, let alone money to support PI.   

The question of "how to expand QB64's userbase by getting it to run on XYZ hardware" is a completely expired question. Forget it.

The real way to grow QB64 as a language is to return to its *intended* roots, which is to provide an accessible platform for anyone, at any level, to write code and get it to run. The true BASIC way. Listen boys, while QB64 as a *language* does this very thing, QB64.exe does not. QB64.exe, even with its GL backbone, is still a combustion horse trying to keep pace in an age of electric cars and rockets. The answer to the conundrum on hand is to somehow keep the *spirit* of QB64 whilst shedding the husk of its pasta code.

Enter dbox. Our Galleon 2.0. His qbjs project is SO good, came from such a new direction, that people don't even realize the answer has already arrived. I don't care if QB64.exe has more features, or has a dubugger, all of that is nil. What dbox has is a thing that runs QB64 code on any device (coming soon, just a matter of interface). This is it. Repent repent repent, for the lord has arrived early. Am I getting through to everyone?

The job now is to (i) let dbox round off the corners while receiving useful feedback from everyone, (ii) start to mass old-but-gold classics that can be showcased in qbjs, (iii) bulldog the hell out of this thing on the Internet. Make it known that BASIC really is back *in spirit*. It's on every machine that has a browser. It's in your face like it used to be. Microsoft blew it, every OS blew it, here now is your BASIC, just paste your code and go (just about).

Do that, and we grow. I'm sure of it.

The question of "how to expand QB64's userbase by getting it to run on XYZ hardware" is a completely expired question. Forget it.

The real way to grow QB64 as a language is to return to its *intended* roots, which is to provide an accessible platform for anyone, at any level, to write code and get it to run. The true BASIC way. Listen boys, while QB64 as a *language* does this very thing, QB64.exe does not. QB64.exe, even with its GL backbone, is still a combustion horse trying to keep pace in an age of electric cars and rockets. The answer to the conundrum on hand is to somehow keep the *spirit* of QB64 whilst shedding the husk of its pasta code.

Enter dbox. Our Galleon 2.0. His qbjs project is SO good, came from such a new direction, that people don't even realize the answer has already arrived. I don't care if QB64.exe has more features, or has a dubugger, all of that is nil. What dbox has is a thing that runs QB64 code on any device (coming soon, just a matter of interface). This is it. Repent repent repent, for the lord has arrived early. Am I getting through to everyone?

The job now is to (i) let dbox round off the corners while receiving useful feedback from everyone, (ii) start to mass old-but-gold classics that can be showcased in qbjs, (iii) bulldog the hell out of this thing on the Internet. Make it known that BASIC really is back *in spirit*. It's on every machine that has a browser. It's in your face like it used to be. Microsoft blew it, every OS blew it, here now is your BASIC, just paste your code and go (just about).

Do that, and we grow. I'm sure of it.

I think your response pretty accurate. In order to add new users, the support team has to be willing own and address QB64 / PI problems and be super helpful to people who ask for help.  I don't see that happening.

Galleon did an amazing job with QB64 and the QB64 team has also done a good job keeping QB64 going. I am not aware of any roadmap for QB64.  I get the impression that there is not much of an appetite to take on major changes to the QB64 engine anyway.   It would be easier to re-platform if the QB64 engine didn't compile tons of un-executed code.   Without support for ARM, QB64 is less useful to me, but I am only one person.   Qb64 is fine for the windows environment.  Qb64 works on windows, it's reliable and it's free.  It's basic that you know which works on new versions of windows. 
 

The question of "how to expand QB64's userbase by getting it to run on XYZ hardware" is a completely expired question. Forget it.

The real way to grow QB64 as a language is to return to its *intended* roots, which is to provide an accessible platform for anyone, at any level, to write code and get it to run. The true BASIC way. Listen boys, while QB64 as a *language* does this very thing, QB64.exe does not. QB64.exe, even with its GL backbone, is still a combustion horse trying to keep pace in an age of electric cars and rockets. The answer to the conundrum on hand is to somehow keep the *spirit* of QB64 whilst shedding the husk of its pasta code.

Enter dbox. Our Galleon 2.0. His qbjs project is SO good, came from such a new direction, that people don't even realize the answer has already arrived. I don't care if QB64.exe has more features, or has a dubugger, all of that is nil. What dbox has is a thing that runs QB64 code on any device (coming soon, just a matter of interface). This is it. Repent repent repent, for the lord has arrived early. Am I getting through to everyone?

The job now is to (i) let dbox round off the corners while receiving useful feedback from everyone, (ii) start to mass old-but-gold classics that can be showcased in qbjs, (iii) bulldog the hell out of this thing on the Internet. Make it known that BASIC really is back *in spirit*. It's on every machine that has a browser. It's in your face like it used to be. Microsoft blew it, every OS blew it, here now is your BASIC, just paste your code and go (just about).

Do that, and we grow. I'm sure of it.

I think your response pretty accurate. In order to add new users, the support team has to be willing own and address QB64 / PI problems and be super helpful to people who ask for help.  I don't see that happening.

Galleon did an amazing job with QB64 and the QB64 team has also done a good job keeping QB64 going. I am not aware of any roadmap for QB64.  I get the impression that there is not much of an appetite to take on major changes to the QB64 engine anyway.   It would be easier to re-platform if the QB64 engine didn't compile tons of un-executed code.   Without support for ARM, QB64 is less useful to me, but I am only one person.   Qb64 is fine for the windows environment.  Qb64 works on windows, it's reliable and it's free.  It's basic that you know which works on new versions of windows. 
 

Last time I asked, the M1 processor on the MAC is unsupported.

I've used this command to compile tons of QB64 programs from a batch file. 
qb64 -x sourcefile

that's awesome

Well done, as always, Steve!  Congrats on your retirement. 

I liked the timestamp on the development files.

@johnno56: Ok. But I'm so blown away with linux, I probably will wipe out windows all together on this laptop and end up trying Wine.   Q4OS plus the XPQ4 Desktop kit discussed here suits me perfectly, and I'm not missing windows at all.  Not saying I'm done using the windows version I own (Win7), but I'm sure done thinking of upgrading beyond that. 

Just to keep this on topic, QB64 works great in Q4OS.  _ICON isn't working in it however.  @mohai: If your laptop can run the Q4OS 32-bit trinity version, grab the XPQ4 for it too and it will look almost like running windows.   

- Dav

I followed that URL.  Those screen shots are amazing.  Thanks for sharing your experience.