jcollins

One downside for sure is lack of deep knowledge on all these platforms can make it difficult to see issues.

I'm trying it now with an app and so far it's working really well. I build what I can cross platform, the non-ui stuff, then have AI build the UI for each platform.

It even implemented native low-level graphics on each platform: metal, vulkan, and d3d12. It builds SwiftUI on Apple platforms, WinUI3 on Windows, GTK4 on Linux, Compose on Android. The cross platform stuff is Zig with a C ABI.

And yeah, it's a bit terrifying how fast you can iterate. I've built for all these platforms in about a month. It would have taken at least a year, maybe more before. I haven't even optimized the process by having AI agents follow my lead automatically, so as I finish features on the primary platform they could start building the others by watching. Requires some setup I haven't tackled yet (VMs for all platforms with agents waiting).

I imagine memory consumption is on par with running on Intel. I don't think Docker Desktop can really change that.

Gyro, a command-line cloud automation and management tool, started as internal tool over 5 years ago. We had a vision of building one tool that would pull together several different tools (Chef, Service Discovery, Authentication, Deployments, etc) into a single interface that would greatly simplify the day to day management of our systems. This goal was very successful in transitioning to a DevOps model. Our developers are able to make configuration changes, do their own deployments, and build there own test environments without help from the operations team. And most importantly they've embraced this model because it gave them the power to make changes without waiting for an operations team and in turn it helped the operations team by reducing their work.

We decided to clean up the code and open source it. The result is Gyro (getgyro.io).

What makes this different than what exists?

- Designed with logic (for loops, if conditions, etc) from the beginning (https://gyro.dev/guides/language/control-structures.html)

- Workflows provide the ability to stage complex changes and rollback (https://gyro.dev/guides/workflows/)

- Extensions allow for tight integrations with other operations tooling (https://gyro.dev/extending/)

For some screenshots of Gyro see (https://getgyro.io/introducing-gyro), source is available one Github (https://github.com/perfectsense/gyro)

We're really excited to open source Gyro and see how people extend it!

An example is doing blue/green deployments where you want to build a new web/application layer, pause to validate it (or run some external validation), then switch to that layer and deleted the old layer. All while having the ability to quickly roll back at any stage. In Gyro, we allow for this with workflows[2].

There are many other areas we allow to be extended. The language itself can be extended with directives[3]. In fact, some of the core features like loops[4] and conditionals are just that, extensions.

It's also possible to implement the articles concept of "non-destructive prod" by implementing a plugin that hooks into the convergence engines (we call it the diff engine) events and prevents deletions[5].

We envision folks using all these extension points to do creative things. For example, it's possible to write a directive such as "@protect: true" that can be applied to any resource and would prevent it from ever being destroyed using the extension points described above.

[1] https://github.com/perfectsense/gyro [2] https://gyro.dev/guides/workflows [3] https://gyro.dev/extending/directive/ [4] https://gyro.dev/guides/language/control-structures.html [5] https://github.com/perfectsense/gyro/blob/master/core/src/ma...

Our zipped distribution is 50mb. Uncompressed the executable is 26mb and the runtime is 75mb.

I'd love for it to be smaller but I can't complain. This also makes solving for Linux, macOS, and Windows pretty trivial. They each get their own zip with packaged runtime.

I'm never happier than when I'm flying. I can see how a similar effect happens to sky divers.

Backed by Imagemagick. We usually run it behind a CDN like Akamai or Cloudfront but you can also use Apache httpd’s built-in file caching.

I have the cloud key (the dongle) so I could be wrong.

It is easy but it’s still slightly harder than the average consumer would want.

The solution for us was to set this in sysctl.conf:

net.ipv4.neigh.default.gc_thresh1=0

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1331150... https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1331150...

https://github.com/perfectsense/dari

Here is the SQL schema: https://github.com/perfectsense/dari/blob/master/db/src/main...

We've used this model for almost five years now with great success. It's simplified rolling out "schema changes" since no tables need to be changed. It's also been optimized to a point where it's extremely fast.

If somebody did just re-submit it as a paid app I'd be fine with that. It is open source after all. I do think that's unfair to end-users though who probably wouldn't know it's free and it would add to the clutter of the App Store.

I've published 2 apps, one paid (Whiteboard Capture Pro), one free (Picture Me). Picture Me code is open sourced as well (http://bit.ly/7rmKdT). Originally I did some marketing with Google Adsense but it's too hard to track its success so I stopped. I've had some free marketing thanks to mentions in blogs, etc. Recently Apple even made a super awesome video about one of the apps (http://bit.ly/cbtkg3).

Income wise, it's decent. Surprisingly stable at it's current level. Let's just say it's paid for a WWDC trip, three iPhones and 2 iPads and there is plenty left over, plenty.

http://code.google.com/p/moddims/

Almost definitely won't detect a dog. :)

I'll slap it up on github in a few and update the links.

http://github.com/beetlebugorg/PictureMe/tree/master