34 ms·
When I see the specs of things like the Raspberry Pi and Apps like this, it makes me wonder how great a system like that could be. Executable size may not be
by Lerc 9y ago
When I see the specs of things like the Raspberry Pi and Apps like this, it makes me wonder how great a system like that could be.
Executable size may not be the best measure of these things though. Ram usage of some things can be quite huge. tinyapps.org seems to avoid this by disallowing things needing runtimes, which while not the cause of RAM bloat, often tends to be a common factor.
I'd actually like to see an interface for micro controller style apps. Like An 8 bit AVR emulator that could do some kernel syscalls to the hosted environment. It would allow for a class of apps to be written that would have a fixed memory footprint. There's some Irony here in that this would also be a runtime.
I once had a volume knob widget on my task bar that used 4 meg of ram. Somehow I feel it could have been done better.
- rebootthesystem 9y agoWriting tiny apps for small constrained systems isn't difficult at all. That's what we did thirty years ago. One neat trick is to use threaded interpretive languages (FORTH). https://en.wikipedia.org/wiki/Apollo_Guidance_Computer https://en.wikipedia.org/wiki/Apollo_Guidance_Computer https://en.wikipedia.org/wiki/IBM_System/4_Pi https://en.wikipedia.org/wiki/IBM_System/4_Pi https://www.nasa.gov/mission_pages/shuttle/flyout/flyfeature_shuttlecomputers.html https://www.nasa.gov/mission_pages/shuttle/flyout/flyfeature... The minute you start touching modern languages and OS's things become significantly more difficult to shrink into small platforms.
- voltagex_ 9y agoI've been thinking about this a lot, mainly due to being grumpy about the proliferation of Electron apps and the effect that's having on my available RAM. When I'm not being so grumpy, I'm glad it's easier to write apps than ever before. I think someone on here posited that it's a choice between something written in Electron or not written at all. I think that's fair enough - maybe we just need to make it easier to write tiny apps. Rust and Go look great, even with a very steep learning curve coming from C# and Python. And yes, I know as a C# developer sitting on top of hundreds of megabytes of runtime, I'm "part of the problem".
- lsh 9y agoI'm a python and clojure dev, and part of the reason for going in search of tiny apps with source code was to see how they managed it. I know I'm part of the problem too, I like working at a very high level, but I, too, am getting old and grumpy and detest how 16GB ram isn't enough these days. I was actually, partly, looking for a community who built or curated lists of apps with artificial constraints, for example: app must not use more than N MB of ram, must be open source, etc. there is the demo scene, but I want to build practical apps, and there is suckless, but I found their community and philosophy a bit ... hardcore and unaccommodating.
- voltagex_ 9y agoI'd definitely like to talk about this more - I don't have time for any more side projects but it's an interesting idea. "app must not use more than N MB of RAM" is a tricky one - how would you measure usage in all cases?
- roryisok 9y agoI think its less about a hard limit and more about comparing to other apps out there that do the same thing. Music players for instance. 1by1 < foobar < VLC < Songbird / Spotify
- lsh 9y agoabsolutely. I see a lot of css and js frameworks marketing themselves on how very small they are, both before and after minimization. I guess the first step is to accurately measure what is important.
- lsh 9y agoit's a good point and something I'm still investigating. with the jvm you can set the maximum memory available to the instance. I once did all the fundamental C and C++ type stuff, writing a memory manager and my own implementations of certain datastructures and algorithms, it doesn't seem unreasonable to write something that would enforce program limits in a transparent way.
- Jaruzel 9y ago> I once had a volume knob widget on my task bar that used 4 meg of ram. Somehow I feel it could have been done better. Yesterday, I decided to finally retire my old self-written 'sticky notes' utility, and migrate all my notes to the built in Windows 10 Sticky Notes. * My note app: ~3mb whilst running. * Win10 Sticky Notes: ~22mb whilst running. 22mb might not be a lot of ram, but I do struggle to understand how it's using that much memory just to display small squares with text in them... ... Anecdote: Two hours later, whilst trying to copy-paste text from one note to another, I lost the text completely, and Sticky Notes crashed... ~sigh~ back to my crappy app then...
- csydas 9y agoProbably because the Sticky Notes on Windows 10 has a bit more functionality built in. If I remember correctly, it has integration with other systems (including Outlook), so you can make a note and create a calendar event with said note. Basically there's just a lot going on under the hood for many of these "simple" apps that isn't user facing. For better or for worse, that's why.
- Jaruzel 9y ago> so you can make a note and create a calendar event with said note hmm wasn't aware of that, and didn't see the option - if this so, then I shall redact my outrage. :)
- ocdtrekkie 9y agoOne of the other things not yet mentioned here, is that Sticky Notes integrates all of Microsoft's new Inking and Typing features. On a touch/pen enabled system, you can write on the note, and if you have some of their cloud features enabled (I usually don't), it'll convert your handwriting into text, convert text items like addresses into clickable links, etc. If you put a flight number in there, it can turn it can add flight tracking, if you put a stock ticker in there, it can update you on that, etc. See: https://www.howtogeek.com/285944/how-to-use-sticky-notes-on-windows-10/ https://www.howtogeek.com/285944/how-to-use-sticky-notes-on-... Sticky Notes these days packs in a surprisingly large number of features. (None of which I use, but it explains the 22 MB footprint.)
- 0xcde4c3db 9y agoIt's fine as long as the runtimes themselves are tiny and low-overhead. Most C and C++ programs carry around a mandatory "runtime", usually denoted by the module name "crt0". It's basically just a translation layer between the OS's executable calling conventions and main()/return that weighs a few dozen bytes and only runs during startup and exit of the app to do things like set up argc/argv/envp and put the exit code where the OS expects it. The C and C++ standard libraries provide many of the services that a framework runtime would otherwise provide, but they're usually much smaller than a modern "framework" and provided as part of the OS. Modern Windows desktop apps are supposed to install their own copies of the DLLs (msvcrXX.dll/msvcpXX.dll and friends). You can link against the "known DLL" msvcrt.dll, but I don't think linking to it is officially supported for any non-ancient version of Visual C++, and IIRC it has a bunch of carefully preserved bugs for backward compatibility. Maybe there should be something like musl for Windows? > I'd actually like to see an interface for micro controller style apps. Like An 8 bit AVR emulator that could do some kernel syscalls to the hosted environment. It would allow for a class of apps to be written that would have a fixed memory footprint. There's some Irony here in that this would also be a runtime. As rebootthesystem suggests, this sounds a lot like a niche that would be well-served by a purpose-built Forth interpreter. Such interpreters have been used to e.g. facilitate interactive development or hot-patching on actual microcontrollers and other constrained systems. There's a surprising amount of symmetry with Lisp systems, but the traditions of Forth tend to value small code for both application and implementation. There's probably nothing preventing a tiny Lisp from filling the same role.