Xojo Inc again … 🤦‍♂️

Something more to think about… Try building a statically linked binary for Linux with glibc. Then copy your binary into older version of Linux and shit hits the fan:

Fatal glibc error: dl-call-libc-early-init.c:37 (_dl_call_libc_early_init): assertion failed: sym != NULL
bad memory access or corruption 0000000b 0000000000494923: at offset 22580 in input: *** se ;
“libc.so.6” lib libc

I thought binary was supposed to be static… Are Linux binaries not real executables then?

1 Like

I guess we’ve opened up the computer biology book and discovered that things are perhaps not as clearly defined as we’d like. :rofl: :rofl: :rofl: :rofl:

1 Like

Found this article from 1995/january PC magazine that’s related. :astonished:

Personally I do not think that ANY modern tool creates a stand alone APP/EXE (with perhaps the exception of some console apps)… I believe that almost all others have hooks that rely on files that are part of the OS. SQLite and iOS for example. Unlike Xojo which embeds SQLite into its bundle, iOS relies on the SQLite installed on the device.

There may be exceptions to this, but I’d bet they are far and few between

Oh man. Stay in your single executable world. I have only one target: high performance software for big amounts of Data. Not gameplaying with freebasic. Sorry for that but it is a bit more complex in this world. And the next: if you have no Idea about glibc then you should stop with it. Also: not my business. I can’t find any need for that what you are discussing. It makes no sense. If Storage would be the matter we could talk.

Another thing: on all of my customers systems Java is installed (Prerequisite). A Java 11 Software is even running on Java 22 without any problems. My Customers have installed Java 17 (one of the domains) and the rest 21. What shall I say. To run a hello world is no problem. 1.3kb is the exevutable jar. And I can have tons of them. Compiled with Java 11 it runs on Windows, Linux, MacOS, Solaris, AIX, all BSD variants. So installing Java makes sense for my Customers. And the executables are extremely small.

So there is a solution for me. Why should I have any interest for a freebasic solution for one platform? When even a GUI Variant of hello World running on all OS-platforms (even MacOS) costs 8.1 kb? If there would be any need for it we could speak. But what we can do with freebasic? Looking on it’s GUI capabilities I can say: not usable at all. Looking at it’s eco-system I can say: not worth of looking on it. You can play games with it and start discussions like this. But where is the productive sense of freebasic?

Todays world of computing does not need freebasic anymore. And it does not need to shere small amounts of memory. In times where 16GB memory are normal saving one MB? When they had 512 kb the difference was counting. That is long time ago.

Silly and pointless argument. Even the “real executable” is going to load and use OS Libs/frameworks :upside_down_face:

2 Likes

PSSST…don’t say it out loud

You totally missed my point. You also seem to be making assumptions about my knowledge. I may just be an electrician and hobbyist programmer but don’t assume that your knowledge is above all of us mortal forum users.

1 Like

I am not making any assumption about your knowledge. I don’t know anything about your knowledge. Why should I? I would not even if I would have knowledge about. What I said is: there is no need about. Freebasic has nearly no ecosystem. So how shall I see that in any way as useful. Next is: why should I need this single executable. That was in old Dos times normal. Today not anymore. Looking on Macos, Windows or Linux, Android or IOS: no. Not at all. There is no modern system generating this kind of executables anymore.

So for me it is playing with it. Possible. But it makes no sense to compare it with anything else when there is no ecosystem. And there it is a bit complex to work with freebasic. Even with VB6 it is. You can work still with it. But you have to deal with all it’s limitations. Like with freebasic. That’s what I tried to say.

So if you feel that I was trying to speak about your education: no, not at all. I would not dare to do that to anybody. So I will apologize if you feel like this.

I debated App Size once on t’other forum, it is important especially if you’re competing.

The smaller the app size, the quicker and cheaper to download, install, get validated by the system and run.

2 Likes

Sam. It is not from interest if 3 or 30 MB. And that’s it. Nobody is interested. And really big apps are by self bigger. It is a useless discussion.

Don’t claim your opinions as fact. Strive to be better than Geoff.

I definitely care. I definitely judge. I definitely find alternatives if a one-shot app is 30mb and I can do it with a bash script.

6 Likes

There is value in small binaries. I have slow internet, a 3mb and 30mb download is a noticeable difference.

To a certain extent, as computers get more powerful, and have larger amounts of space, we’re afforded liberties to complete projects faster, and hopefully less buggy with languages and libraries that necessarily become larger and more complex. The cost of the extra storage taken, and the extra CPU cycles can be worth it for cross platform distribution, and faster turnaround when needed.

The problems start when it becomes just shortcuts, still release horribly buggy software, lose employees, are forced to do more with less because something like electron “saves fte’s” and loose all advantages of what has become a massive, not understood, binary/application.

Things like electron can work in some cases, but it starts to be used for everything, even when it’s the wrong tool, and before you know it you have massive chrome processes everywhere, with their own contained libraries, their own security flaws, each one needing to be fixed individually in a colossal mess.

I do not know the experiences everyone in this forum, but I have seen some shit. I’m not even that old! So much of the world is many different crowdstrikes waiting to happen, while companies lust after the next big thing.

The problem isn’t necessarily the languages, libraries, binary sizes, or the developers we criticize. The problem is that some out of touch executive goes to a conference, sees something like Flutter and thinks it’ll solve every single problem they have in the company, when the problem is lack of employees and cross training created rogue departments solving issues directly in databases using an unholy combination VBScript, Microsoft Access, and Microsoft Word that someone is getting paid overtime to watch run overnight.

They want mobile apps for everything, don’t want to pay the developers to make them, and start demanding their employees try to create things HTML wasn’t built to handle at the time (I know, lets demand Shockwave for our time clocks).

And on the employee end, its an endless churn of demands to learn Flash, coffeescript, then SASS, then phonegap, Silverlight, coffeescript again, then electron, then fucking tailwind, drupal, wordpress, drupal again, Virtual Machine Appliances are the future, nope we want Docker now, and on and on and on. We do drupal headless, then why are we recreating the drupal UI from scratch? We want our knowledegebase run on django. Why? “We don’t know, but it’s a thing we want.” Things that end up being 3 year cringe fads, throwing feces at the work of the past because “cool new shit.”

Many of these things are good to know, and useful for their purposes. Many are good to work with still. Many were good for the time they were created (except Tailwind, I swear to god). Even electron can be useful.

But cost and impatience have driven many to use fast tools and have terrible expectations at every level. When we have PWA, there has to be a good reason for using Electron. And when we have .Net and Java (yes, tho I don’t like Java, even Java – sorry I have an irrational hatred of Java), mature, tested, efficient ways to solve the problems of clients and employers, why reach for the wrong tools?

There are companies that export private medical documents from an application that can natively create encrypted PDF’s, send it through microsoft word to create PDFs that are encrypted in zip files because “HIPAA made us do it fuck the government,” and then post on a public FTP because companies don’t want to spend to train their employees. Then when the process becomes critical, they look for solutions purchase to automate that process to save money, ignoring they had a solution the entire time. And then the company they hired demands their employees do it in a day without testing, and then those employees need to pick something fast and easy, and they do, and thats what they learn and bring everywhere.

Then we have gigabyte binaries doing tiny tasks and everyone either accepts it or hates it, but the anger is directed in the wrong places.

Sorry for the rant, I’m just going down this thread all over again, and it’s frustrating, because there is value in smaller binaries, but sometimes the cost doesn’t outweigh the benefits: Honestly, does spinrite need to fit on a floppy disk when those don’t exist. We could have had SSD support years ago when Spinrites SSD features actually would have mattered, but instead, floppy.

And I also don’t like the companies that fire workers to save money to use wrong tools for jobs, or pressure their employees to be so much more productive and faster they have to settle for googling how to make a UI application in Microsoft Word to get the job done. I don’t blame the end users, or the developers, and not even the languages and libraries (except Tailwind WTF). It’s just ends up being a cool flex sometimes.

This is a medium size rant. The assembly version is simply, WTF 20 24. The Electron version went on for several more paragraphs restating the same thing in different ways. The tailwind version is unreadable but has pretty colors.

6 Likes

There is a difference. You are working with a server. You can do it with a bash script. Or with Python. Or with Java when JRE is installed anyhow. But if you can not do it with a Bash Script…what then? If you want or need to write an App with database actions and so on…does this makes sense? If I need a little thing I can’t do with bash I will prefere c. But when we are speaking about an app? Sorry. It makes no difference in Desktop environment to discuss about 30MB.

I was referring to my own experiences on macOS. The thing that came to mind was an invisible files cleaner that I opted to implement as a bash script instead of a waste of space. I am also considering fixing up my subtiles translator to not be a waste of space either.

Out of scope for the point that I was making. A database driven app is likely to be much more complicated than a one-shot app.

That is your opinion, not a fact or even an agreed upon standard. In my opinion, it absolutely does matter.

2 Likes

Then you should use ObjectiveC for your ultra small shots. Faster than scripts. End of discussion. Exactly that what I mentioned.

You had dismissed Sam’s concern for size in a very Geoff-esque manner. I do respect you, your skills, and your beliefs. I was standing up for my friend and my beliefs.

On a positive note, we do all three agree that using Objective C is an excellent way to reduce an apps size. :slight_smile:

3 Likes

That I respect. The entire point is: yes, sometimes it needs small apps. I use c in this cases on Windows and Linux and objective c on macos and I am linking dynamically. Using the system libs is then resulting in small transfer file sizes and in small app sizes. No question. For system utilities I am doing it that way since long time.

I was still in the discussion about the freebasic Idea. So I have to say sorry, I reacted in a wrong way. But. Is it a real problem toay? Not really.

As I have Java installed on all client machines I can say: most command line apps are a few kB. No question. While jre is there it is doable with Java. If not there is an always preferred language. And so I am landing at ObjectiveC for macos.

It results in fast and small executables. Enough for System tools. And yes, sometimes I am using bash scripts. While it is not worth to write an application from it. That’s it.

It also gives its opinion at times :sweat_smile:

1 Like

Guys, I am maintaining Enterprise Terminalservers (both Linux and Windows) and size matters in terms of filesize and memory footprint. One stupid Helper App made in Electron with 100 MB in RAM eats alone 10 GB of RAM (!) on an terminalserver with 100 concurrent Users. So do not tell me something something about size…

3 Likes