Tiny Apps | Hacker News Reader

Tiny Apps

tinyapps.org

266 pointslsh111 comments

Tiny, single exe (and an ini for config) Windows programs have a special place in my heart. Perfectly portable, instant and lightweight.

I want to cry when I see simple software like Sticky Notes in Windows 10 using dozens of MB of memory and have a 30+MB install size with minimal functionality.

I don't have a big issue with .NET and Java based apps but I seem to be using more and more Electron based software and while the software isn't bad it sucks that every program comes with its own bloated framework :(

Although it was "removed due to copyright violations"[1] in 2003, TinyWindowsGames.com was a work of art. If you don't mind downloading random binaries you can still grab them via the Internet Archive. I will see if I can create a new screenshot of the playable, tiny thumbnail near the system tray (probably microscopic at today's resolutions).

https://web.archive.org/web/20030618002602/http://www.tinywi...

[1] Nintendo reported us to some software theft agency over "Tiny Donkey Kong" (I forget what the agency was called) and that got us threatened us with scary emails. We tried to protest that we just supplied emulators, and not ROM images, but it fell on deaf ears and we were too young and intimidatable to stand our ground. It's a shame, since it was a popular site in its day.

https://groups.google.com/d/msg/alt.comp.freeware/yKQBaHgjGD...

Which shows that copyright is a form of censorship.

Well, that's what it was invented for...

Apparently some of the games are in the system tray.

http://imgur.com/a/CuA6e

I miss GameHippo. Back when I had dial-up and a Pentium 100mhz with 16mb of RAM, it was the best place to download tiny games that would actually run; and it's why I got into programming -- a README with one of the games said a single person wrote it in Pascal, and that gave me the inspiration to learn to program myself!

Paging HN user miles!

https://news.ycombinator.com/item?id=12985672

I'm afraid (or perhaps the word I'm looking for is "glad" ;-) that the Internet has passed tinyapps.org on by. After its fleeting 15 seconds of fame back in 2001 (thanks to a Slashdotting and tiny blurb in Wired), the site has mainly served as an irregular tech blog lo these many years.

Ha! Thanks so much for the kind shout-out, j_s - what a memory you have! Glad to see my humble corner of the web is still of some small interest ;-)

Clearly there is still tremendous interest in the type of efficient software you curated so well back in the day. So many of the programs still work fine today even though their original websites are long gone -- a testament to minimal dependencies, your efforts to archive local copies, and Microsoft's commitment to backwards compatibility!

Your blog is always a breath of fresh air any time I happen to stumble by one of your solutions in response to searching for help. Definitely one of my "trusted" sources - don't ever let that domain expire!

interested 10 years ago, still do to this day :D

great job Miles

Longtime supporter of tinyapps.org. Go, Miles, go!

How did you know he mentioned you?

Is there some sort of @mention bookmarklet/browser extension in HN?

failing other explanation, i linked the thread when i sent him a couple of additions.

Thank you, steanne - it was indeed your kind email that alerted me to the post!

HNWatcher[1] appears to offer something close: "Follow keywords, users, karma, domains on Hacker News".

The first HN notification system I learned of and used was HN Notify[2,3] by Riyad of The Buzz Media[4].

I've been using edavis' hnrss.org[5] of late; it "provides custom, realtime RSS feeds for Hacker News", including for user posts and comments.

A quick search just now turned up dangrossman's HN Replies[6,7] and a few other monitoring options[8].

But in this case, it was indeed steanne's kind email that alerted me to the HN post.

[1] https://www.hnwatcher.com

[2] https://web.archive.org/web/20120103200449/http://hnnotify.c...

[3] https://github.com/rkalla/hnnotify

[4] https://web.archive.org/web/20120119135841/http://www.thebuz...

[5] https://edavis.github.io/hnrss/

[6] http://hnreplies.com

[7] https://news.ycombinator.com/item?id=11080539

[8] https://www.google.com/search?q=hacker+news+comment+notifica...

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.

Writing 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/IBM_System/4_Pi

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.

I'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".

I'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.

I'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?

I 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

absolutely. 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.

it'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.

This is a wonderful trend. I've been griping about bloated apps for ages. There's a huge accessibility issue for people in Latin-America and Africa, where most people's computers still have no more than 2G of ram.

I'm glad it's easier to write apps than ever before.

But it was easy before. If you are willing to forego completely native UIs (which you are when you are using Electron), it's always been easy to make GUI apps with Qt. Drag together an UI in designer, use (py|whatever)uic to generate classes, hook up signals/slots, and you are done.

I can only pin it on intellectual laziness of front-end programmers not wanting to learn anything else than HTML/CSS/JS and companies wanting replaceable developers. There is virtually no benefit for the end user over native applications or cross-platform applications written with e.g. Qt.

Is a PyQt app really more lightweight than Electron?

To be fair, Qt is a lot trickier than Electron - you've mentioned slots and signals which are not something you'd encounter every day (at least in webdev world).

Edit: I also don't buy any argument that relies on "intellectual laziness". There's enough elitism around already.

Well, I can't speak for today, but back in the early 2000s, I put together a simple web browser in Qt, which is easy because it already includes a simple web engine, added a simple JS engine, and the web browser was up and running.

I recall being disappointed it wouldn't run nicely on '98 for some people, because it used about 25mb of RAM, and many only had 128mb for their entire system.

Is a PyQt app really more lightweight than Electron?

I just tried, because it's only 5 minutes of work. The demo apps (including a movie player and an image viewer) are generally in the 30MB of memory ballpark on OS X.

you've mentioned slots and signals which are not something you'd encounter every day

It's something that you can pick up in a few minutes. Widgets emit signals. You can connect signals of choice to slots to handle those signals. In Python, a slot is just a Python method. In C++ is slot is also a method, but you have to add a small 'annotation' that is processed by moc.

Yes, much. And if that's too heavy for you, WxWidgets should be even lighter.

I'd say that with Lazarus (http://www.lazarus-ide.org/) it even easier - just drag/drop the controls to forms to build your GUI, double click on buttons/checkboxes/radiobuttons/whatever or click on menus or double click on the event editor to automatically write the event handling boilerplate code and you just write the actual code in-place. Creates native executables without need for runtimes or big DLLs (you can use Qt as a backend if you like though and in Linux you have to choose between Gtk and Qt).

Here is an old video i made 2-3 years ago where i write a small 2D tilemap editor with Lazarus (the first 5-6 minutes are downloading and installing Lazarus and a tile editing tool i wrote since i used Windows 7 for that vidoe and the Win7 paint program sucks) https://www.youtube.com/watch?v=_3JgeIUo1X0

In my previous life as a cubicle drone in the late 90s I have worked with Delphi under Windows and always dreamed about it being ported/cloned/whatever on Linux. After seeing a demonstration of Kylix many years ago I almost lost any hope (slow as molasses and buggy), then one day I saw this new project called Lazarus which promised high compatibility with Delphi code and to allow building of native apps. Admittedly it was very buggy then, but eventually it matured over time and I'd say it has been damn ready to be used for production for some years. Give it a try and you won't be disappointed.

I've tried to use Lazarus five or six times now, as a one-time Delphi developer: the main issue is that the lazarus ide likes to crash on the slightest provocation (and the 64bit mac versions don't work very well either)

This is strange. The IDE once surely had stability problems, but I've never encountered them since years. I even installed Lazarus on small NanoPI and OrangePI boards and although definitely not fast it runs natively there and produces native code for them.

Which version did you use and when? 10 years ago the IDE would crash at you sneezing at it and it wasn't until 7-8 years ago that things became stable. However i cannot remember the last time i saw the IDE crash (and wasn't my own fault with a component i was making that caused it to crash, but even that that is rare).

Note that there are a few versions flying around that are unofficial builds, some with addons that break it. Sadly one of them is the one from getlazarus.org which is both unofficial and often comes with unfinished and buggy features from development versions that cause it to crash and be generally more unstable. Combine this with the fact that the guy behind getlazarus.org tries his utmost to promote Lazarus (his version from his site) and there is a chance people who first learn about Lazarus will use the buggy one. He obviously means well, but i really wish he would link to the official site (http://www.lazarus-ide.org/) instead. The builds there are much better tested and there are many week-long release candidate builds that are tested by many people in the mailing lists, forums, etc before an actual final release is made.

Also note that the native Mac version is really in a worse state than the Windows and Linux versions. Thanks to Apple discontinuing Carbon (which is what Lazarus uses on Mac by default), a ton of work has to be done to rewrite the backend in Cocoa and there are very few programmers working on the Mac version so this progress is slow (also AFAIK this was delayed to implement the "Objective Pascal" extension to the compiler that would allow using Objective C classes directly without needing an intermediate C layer). Today you can use both Carbon and Cocoa as backend targets, but between the two the Carbon one is still the most stable. As an alternative you can use the Qt backend though that is more stable and featureful (thanks to it being also worked by the Linux devs), but you'll need to bundle a bunch of shared libs and are throwing all notions of minimalism out of the window :-P. Still it is the only way to get full featured stable 64bit apps with Cocoa made in Lazarus, at least until the Cocoa backend improves. And it isolates the bloat to a single platform, which while not ideal, is better than nothing (and IMO even the Qt+LCL combo is still better than bundling an entire web browser with your program).

So, I do most of my work on Mac, so that's what I'm using. It took me forever to figure out how to rebuild it as a 64bit app using Qt (I built the Qt5 version, maybe that's part of my problem?). Anyways, once I did that, it started fine but I ran into several issues where changing properties of Data Access components would crash the IDE. (postgresql-related things in particular). If I find time, maybe I'll submit some sort of bug report with a reproducible scenario.

You are one step ahead of me, i never managed to build the Qt version myself :-P. Although i didn't try much, i rarely use Macs these days and mostly wanted to see if some minor issue i had with the Carbon build would go away with the Qt backend (the Cocoa backend was basically unusable at the time, although i think today it would work ok).

TBH i'm not sure if it would be Qt5 or the data access components as personally i don't use either :-P. I use Lazarus to make tools mainly for game development (and mainly for 3D stuff) so i don't use the database features at all. Also i tend to use the Gtk2 backend on Linux, mostly because it is the default but also because it tends to fit better the minimalistic window managers i am using (mainly window maker).

Don't you need to be using Lazarus' language (Delphi?) for that? In most cases, that's very prohibitive, since a language with a large ecosystem is usually what you'd want to be writing stuff in.

Yes, but there is a ton of functionality already out there, Object Pascal is popular enough to have almost everything available and for the stuff that aren't available it is trivial to call into other native languages (and there are many bindings already available). If you have a C header you can even use a conversion program that comes with Lazarus to create a binding for it.

Of course it all depends on what you want to do, but for me at least that was never a problem.

The thing about electron is, there's a time and a place for it.

VsCode is an excellent use case for electron - a complex cross platform app with a very quick release cycle, a large plugin ecosystem and a requirement for display and processing of a lot of different types of markup.

But I've also seen a tray notification app worn in electron. It didn't even have a UI. There's also an sd card formatter, and a "quick" launcher.

Devs who wasn't to release some tiny single function app like this should rightly be ridiculed for using electron, but more complex stuff (gitKraken etc) should get a pass. Building a large, complex editor is hard work

typos - "app worn in electron" = "app written in electron" and "devs who wasn't to release" = "Devs who want to release".

> And yes, I know as a C# developer sitting on top of hundreds of megabytes of runtime, I'm "part of the problem".

This should be a solvable problem, IMO.

I mean, C/C++ apps are not inherently tiny - they sit on top of a large runtime too, but one that usually comes with the OS. What makes Python or Lisp apps (in binary form) multi-megabyte by default is that they can't depend on users having the runtime installed, unlike C/C++ apps. JVM managed to cross that gap too - most users, at some point, will install a JRE, which allows .jar files to be small.

I wonder why generalized solution for managing programming language runtimes OS/user-side didn't materialize.

Python runtime also uses that same C runtime so it's not as if you can replace one with another. Besides, stripped static binaries in C or even C++ can be relatively small. JRE is not installed by default on many desktops, let alone embedded.

You are deeply confused.

What makes managed/VM based languages big is that those runtimes are general purpose, and therefore have to embark what most people need. A C/C++ app embarks (mostly) only what's necessary.

I can compile a hello world for bare metal, replace puts with a routine that sends the characters to the serial output, add the necessary UART initializations, and the final program will still be a bunch of order of magnitudes smaller that a Python install. The comparison is unfair of course, but it proves one thing: no multimegabyte runtime in C.

> I'm glad it's easier to write apps than ever before.

I believe that it is Delphi which sits right at the sweet spot of 'native code', 'easy gui development' and 'easy deploy' and I am sad that it is not really in use anymore.

As others have mentioned there's Lazarus, an open source ide that duplicates the Delphi experience. Although, it still needs quite a bit of polish.

> 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...

Probably 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.

> 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. :)

One 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-...

Sticky Notes these days packs in a surprisingly large number of features. (None of which I use, but it explains the 22 MB footprint.)

"Stickes" from Zhorn Software currently running ~8MB private bytes. I've been using this software for...er...longer than I can actually remember. I don't recall it crashing once.

http://www.zhornsoftware.co.uk/stickies/

It'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.

This calls to mind: http://suckless.org/

> Home of dwm, dmenu and other quality software with a focus on simplicity, clarity, and frugality.

I love dmenu, its tiny and to the point and just works.

I've written a few small no-dependency things like this for Windows. Some random notes on writing them: https://news.ycombinator.com/item?id=11011857

These are all no-dependency, and all <100KBytes:

Keyboard layout switcher for Windows: https://github.com/tom-seddon/kbswitch

Windows window manipulation tools, for use with AutoHotKey: https://github.com/tom-seddon/align_window2, https://github.com/tom-seddon/align_window3, https://github.com/tom-seddon/dispswitch

Snack-size Windows clock: https://github.com/tom-seddon/NotifyClock

I think the large ones are only as large as they are because they statically link with the CRT. I used to do the full /NODEFAULTLIB /OPT:NOWIN98 thing, and leave out the CRT entirely, so the EXEs were tiny and had no dependencies - but this was a bit of a pain to work with. And dynamically linking with the CRT caused me a couple of deployment problems here and there, since I used to share my binaries folder between several PCs in the past. So eventually I settled on the purely no-dependency option: statically linking with the CRT, and ignoring the EXE size. The average app just isn't made meaningfully larger in the grand scheme of things by this, and by modern standards it barely even counts as measurable. Even if it's a tiny app, and now 10x larger, it might still be only 90KBytes...

I was curious about how small (file size) and efficient (memory) I could write a program with a GUI and came across this old gem. Most of them have links to their source.

This is refreshing to see. I was just at the doctor today, and they mentioned how a recent system update (they use a system called Epic) made their receipt printing go from an abysmal 30 seconds to a full minute.

It seems that programs get bloated and slower with each passing day. I'd love to see a Renaissance of small, focused, efficient applications.

Bloat wouldn't even account for a delay this long. This seems to be the realm of bad design or overly cautious developers. My guess is that 'printing the receipt' really means process the transaction hitting a bunch of different record stores and APIs along the way and that the system waits for all of that to complete before sending the print job.

From what I've heard, Epic is the best out of all the EMR (electronic medical record) software platforms!

Quite the back handed compliment! They are one of the better ones but the bar is extremely low.

I wonder why this field hasn't been disrupted yet. It seems ripe for it. Established players. Arcane systems. Poor performance. From what I've heard from employees at Epic their software is something of a nightmare.

Is it just something waiting to happen? Is there a company that is already doing this? It could probably be done one independent hospital at a time. Eventually you could get a small network, etc. I understand there is quite a bit of complexity involved, but isn't that what technology excels at?

Edit: Did I forget to mention expensive? These systems are not cheap, and usually involve engineers spending weeks or months onsite setting it up. That means there should be a significant of margin to cut out for competition, and/or healthy revenue for a startup, at least further down the road.

(not an expert in this field obviously) I believe that it might have to do with HIPAA compliance and the red tape overhead that scares away potential disruption. But I imagine if someone were willing and able to disrupt it, they'd make money hand over fist.

Weeks or months... Try 2 years.

I work in an industry you wouldn't think is similar (telecom). It's hard to establish trust, it's more complex than you think, it's more regulated than you think, more rules than you think, closing deals takes longer than you think (6 months is long? Try multi-year sales cycles!), big companies will ruthlessly undercut you to destroy you at their own expense...

You can't just slap together a single page javascript app and close a deal. You need credibility, capital, time, solid engineers... and most strong engineers will avoid EMR software like the plague given the riches they can make in other areas in 1/10 the time.

I wish everyone the best of luck, it needs to happen, but it will be hard.

I worked at Epic a long time ago. They're a bad employer -- churn that would make the worst valley sweatshop blush -- and even when I worked there had 10s of millions of lines of vb6 and the same in mumps/cache, the world's worst programming language. I'd imagine their systems have broken 100m lines of code by now.

You're essentially using software to automate how hospitals and outpatient clinics work. Each one of those has established workflows/procedures; each of those workflows have started or evolved to be (at bare minimum) subtly different than everywhere else. Each and every procedure has to be build into the software or adapted to it. Installs are comparable to installing ERP systems into fortune 500 or fortune 100 companies, with at least comparable risks. Imagine how risk adverse you would be if inaccessible, incorrect, or incomplete health records could quite reasonably contribute to severe medical problems for humans.

If you were ever in a hospital for something serious pre EMRs, you would be unsurprised to have a file that is several hundred sheets of paper. Every single scrap of paper in a hospital has to make it's way into Epic's EMR.

Oh, and hospitals / clinics often buy these systems piecemeal, starting eg with labs. Your code has to talk to their code.

Lots of these got started before web clients worked well, so they're deployed clients. You can't upgrade 10k seats simultaneously, so both the clients and the servers have to be compatible up and down protocol versions. Ponder just how much fun that would be.

Or ponder just how convoluted the logic would be to ask if a person who does X in clinic A is allowed to see record B for patient C. In, for example, a hospital chain that may employ 25k+ people in the hospital and various outpatient clinics.

And follow up with questioning the idea (and expense!) of retraining every nurse, doctor, aide, tech, etc in a hospital on a new system.

TDWTF had an article about MUMPS that stands out in my memory [1]

When I see COBOL fixed width data at my workplace, I just think about that article and thank my lucky stars.

[1] http://thedailywtf.com/articles/A_Case_of_the_MUMPS

Please tag this as NSFL.

If I'm not mistaken that is about Epic, but they didn't write the name to prevent lawsuits.

MUMPS really isn't a bad programming language. It has certain characteristics like allowing incredibly terse code, with abbreviations for all the commands and single letter variable names, but the trade-off of a NoSQL hierarchical datastore acting as variables to the programs with string values and string subscripts on arrays, hiearchical inter-process locking, high level variable management and garbage collection, run time code and variable evaluation, and other advantages. Modern MUMPS systems have high level database management systems as well.

There are companies that are trying. Athena was doing a good job in a lot of respects but then decided they wanted the hospital market and that hasn't gone well. The issue is that switching EMRs has a huge switching cost. You are looking at years just to get the sale. Then there is the time and cost to switch which can easily be 6-24 months depending on size. The biggest problem is that all the health care workers have to relearn a whole new flow and these things are not trivial. Add in that most health care workers are not as tech savvy as you would think.

Additionally, as was mentioned, the health care systems depend on the EMR for all government and compliance reporting. The EMRs also do NOT play nice together so even if you get customers, it is hard to get data out and shared with other systems. It is possible to disrupt this space but you better start with a war chest, start with a very focused niche (say Urologists) and be prepared to slog it out for a decade.

Thank you. It looks like Athena is trying to do just what I described. They even have an incubator for new health related startups[1]. Of course, it is difficult to know from the outside how well they are doing and their trajectory, but I am (foolishly?) optimistic.

[1] https://www.athenahealth.com/more-disruption-please/labs

The incubator program is fine but it is a little bit dependent on their cash flow. They sunk too much money into the hospital space and their free cash flow is down and so is their stock price. Johnathan Bush is a free spirit and willing to be disruptive which is their greatest strength. If I lived in Boston still, I would be working there.

The quality of programmers working for companies like this is terrible. I'm talking about programmers who claim to "know" C++ because they used it once during a computer science project and just managed to avoid getting segfaults too often after lots of trial and error. Writing a small, effective program has been a sign of competence forever because we know that you can't "fake" it. You really have to know what you're doing.

This is why i have the habit of never updating anything unless it's linux.

Have a look at this one (Winexplorer by Edgar Hansen):

https://web.archive.org/web/20160710205728/http://donkeyssta...

https://web.archive.org/web/20160619170739fw_/http://donkeys...

Via Wayback Machine,unfortunately, as often happens another dead piece of the internet.

The actual Winexplorer tool has not been cached, I just uploaded a copy here:

http://www90.zippyshare.com/v/OlyKhob6/file.html

The compiled executable is 164 kb, and the .zip includes sources.

It is a simple replacement for Explorer with a number of nice features.

Thankyou, I think I will.

The apps may be tiny, but the website itself is (also) a breath of fresh air from times past.

I ruefully sort of wish CSS was 100% client side so that all sites would be delivered as plain, unstyled HTML and it would be entirely up to the user how they prefer to see content. Obviously not at all practical, but would make it so much cleaner and easier to read when browsing 90% of sites out there.

the old presto version of opera had an option to default to user css for the whole program instead of the various sites'. don't know if that's still available in the new version.

Progress is modern computing has only been exceeded in the increased in bloatware! Using these lean and mean apps on modern hardware is heavenly - the way I imagined, 10 years ago, of how things would be today.

Yeah, heaven is old software on new hardware!

Not sure of your intent, but:

Even the latest MacOS, Windows, Linux, etc are all running decades old chunks of code. And yet, they still run well.

Old code is debugged code. It's (mostly) proven code. It's aged leather. It feels good and it just works.

Everything doesn't have to be "modern".

I wish it were easy to write such small apps, particular cross-platform. I'm developing a cross-platform file manager [1]. It's way more bloated with dependencies than I would like. But I can't justify spending time on trimming its dep's when there is so much functionality that needs to be implemented. Having said that, I did choose PyQt over Electron for performance reasons [2].

[1]: https://fman.io

[2]: https://fman.io/blog/picking-technologies-for-a-desktop-app-...

One thing that you seemingly missed in your review of toolkits is that PyQt cannot be used freely by a proprietary application such as yours. Qt itself is LGPL, PySide (the official python Qt binding) is also LGPL, but PyQt is GPL-only unless you pay them $500.

Fair point. Though tbh $500 really isn't that much in the context of how much work a desktop app is.

I love the minimal and efficient app mindset.

Back in the 90s I used this DOS text editor that fit on a single floppy sector (512B). I forget the name, but it was a part of my standard toolkit for many years.

These days, I run "evilwm" for my home desktop. That's about as small and efficient as a DE/WM gets anymore, and I love it.

this evilwm? http://www.6809.org.uk/evilwm/

Yes.

I've been using a replacement of network>Proxomitron proxy filter tool called Proxydomo available on github. God bless the guy that reverse engineered the original.

[1] https://github.com/amate/Proxydomo

Wow what a throwback..I've been using Fiddler for some quick proxying but it still doesn't compare to Proxomitron

Hey nice! I wrote a minimal Windows console-based hex editor [0] just recently for fun. Maybe I should submit it.

[0] https://github.com/samizzo/hexed

That's really cool! You should submit it

Perfect thread to mention AnyDesk, our remote desktop application. We practice minimalism as an art form, the size of the Windows executable is 1,8 MB. [0]

Disclaimer: Currently working at AnyDesk.

0: https://anydesk.com/platforms

Besides the file size restriction of 1.4 MB, I agree 100% with the requirements for good OS software. Portability and ad/junk-free is most important.

tangentially related: wasn't there a website of single page web apps a few years ago? I'd love to see tiny SaaS or software solutions listed somewhere.

https://www.producthunt.com/

You can write all sorts of tiny apps. We need to have 100 people just to tell the other 100 people what process to follow, how to write everything, what it should look like, etc. Plus another 100 people to run the process. Also another 100 people to manage those people. Bonus: the following version in this monster must be complete before the previous version is even live. No tiny for us...

Hm, looks like there are some old links - pfe (programmers file editor) links to sites.net, not the official homepage:

http://www.lancaster.ac.uk/~steveb/cpaap/pfe/default.htm

Ninite also follows an interesting concept and saved me some good time in the past. Can be really useful if you need to install the same subset of apps on more machines. https://ninite.com/

Missing this

http://www.bcheck.net/apps/hoe.htm

customized hotkey launcher.

Written in assembly I believe. You can modify it far beyond bosskey.

An even tinier approach would be to compute the Nix closure size of packages. That way, you'd pay for your libc implementation too.

Nostalgia (disclaimer I have moved on to Linux)

I always love playing around with busybox, which is more or less the Linux equivalent to this. Small software is beautiful.

nice! mailed them a couple more.

Perhaps you could add software links to your comment. I am always on the lookout for small applications that get the job done.

http://www.softwareok.com/?seite=Freeware/AlwaysMouseWheel

http://www.nirsoft.net/utils/nircmd.html

nircmd is great, although I wonder how much you could replace with PowerShell these days. Invaluable along with SysInternals [1]

1: https://technet.microsoft.com/en-gb/sysinternals

powershell requires .net. that is no longer tiny.

Depends what boxes you're normally on, but it's a rare day I'm somewhere without .NET.

.NET's memory management can be kinda crappy though, depending of course on the program. Evens out a bit when you start to get complex things.

nircmd is low in memory footprint as well as binary size.

A good ol' favourite of mine, the DSFOK toolkit:

http://members.ozemail.com.au/~nulifetv/freezip/freeware/

http://members.ozemail.com.au/~nulifetv/freezip/freeware/dsf...

Sort of dd for Windows:

dsfi.exe 5,061 bytes

dsfo.exe 6,637 bytes

fsz 6,144 bytes <- same use as /dev/zero can create files filled with 00's

And - as a side note - a related rant: http://reboot.pro/topic/15207-why-everything-is-so-dmn-diifi...

Quite a few links and sites offline - e.g. the top network tool, the top text tool.. :(

Reply on news.ycombinator.com