Show HN: I hate adding updating to my apps, so I created Pakkly | Hacker News Reader

Show HN: I hate adding updating to my apps, so I created Pakkly

pakkly.com

115 pointsenatik69 comments

For a developer-focused product, it's really painful that there's absolutely no technical description here. Tell us how it works!

Also, "free forever for open source" strikes me as problematic because of the above point: Isn't an open source product likely to prefer open source updating? Open source communities tend to get really sticky about apps installing things themselves and such, so this seems like a really iffy place to add a proprietary component.

That aside, I totally see a lot of room for more/better updating mechanics. There's two major culprits I find in a lot of large-scale apps, and I don't really like either of them. But then again... without knowing how Pakkly works, especially OS-specific install details, I'm not sure I'll like it either. ;)

A more technical description is coming soon! I’m planning to post a blog post to provide transparency on how the system works. I hope that will clear things up and I hope you will like it ;)

> Also, "free forever for open source" strikes me as problematic

They could rectify this easily with a dual license though.

Very cool idea, but my first thought is a worry that this will turn into Trojans-as-a-service. The last thing I want, as a developer, is to hand over binary build to an untrusted third party that's injecting unauditable code into my app. You need to provide transparency to hit the market you're after.

See recent Codecov compromise for how this can go wrong.

It seems publishing to https://sigstore.dev/ and having your update agent use that would be a solid starting point for smaller developers.

That’s a valid concern, but Pakkly has never and never will modify your app. It will be installed exactly as-is, with a proxy launcher to facilitate updates. I’m also working on getting that launcher PGP signed so you can verify it’s from us.

> Pakkly (…) never will modify your app.

Realistically, are you able to make that promise? In practice that would mean you could never sell the company, because current promises go out the window in that scenario (see every company acquired by Facebook).

Signing needs to be mandatory. By becoming the middle-man for packaging and shipping software, you have painted a giant target on your back for state-sponsored hackers and cyber criminals.

Your whole service could end up being one giant backdoor for every application that uses it, putting millions, even billions, of people at risk. Imagine hospitals using software from your system that was never signed. Nuclear facilities, oil pipelines, water treatment plants. If you think 'nobody would be that stupid to use unsigned software there', think again. Some organizations would probably ban the use of apps packaged by your service if it wasn't clear that they had been signed by the authors.

If you make the process seamless enough, people will be fine with signing their builds. And there's plenty of examples of supply chain attacks you can wave around for encouragement. You can even promote this as a core reason to use your service, as you can make it easy for them to securely distribute their software.

Yeah, to be honest I just wanted to get this out ASAP to see what people’s reaction would be. Currently that means it only serves direct downloads from https://github.com .

Currently the roadmap looks like:

Add macOS/Linux support with full signing on macOS and Windows. Add hosted binaries and private repos. Add cryptographic signatures both on the developer side and on our side. These are obviously not enough for total opsec, but should mitigate common attack vectors.

But as you said, the intention is to make the process as seamless as possible, that takes some design time though.

> Simply drag-and-drop your files to make it instantly available for your clients. The next time they start your application it will self-update to the latest version.

How does the latter half of this work? Specifically, if I haven't modified my app to incorporate your service, how does running it trigger the updater? I assume some sort of wrapper executable?

If the above is correct, how much overhead does that wrapper add? What happens if an update is available, but the user's internet connection is slow/down? Will my app be allowed to run while updates are checked for in the background, and if so, do you fire a message telling the user once an update is known to be available? Or just silently restart it?

Yes, you are correct, Pakkly adds a thin wrapper to your executable which is built with Rust to be as lightweight and fast as possible. This wrapper adds virtually no overhead besides taking up a bit of memory (around 8mb).

Update checking only happens on startup, currently. Your app performance will not be affected. In case the server is not responding during startup Pakkly will continue, after a brief delay, executing your app. The startup update check will fire at most once every 60 seconds (In case someone starts your app in quick succession).

Update notifications are planned, but these will be optional, and will never stop your app for you.

Kids these days - calling 8mb “a bit of memory” :) (yes indeed it’s not that much these days but I remember when 8mb was enough to run a multitasking OS with a ton of high-end applications.

That particular figure makes me think of the derisive backronym for emacs ("Eight megabytes and constantly swapping").

(Long-time emacs user here)

back then IT was not the workhorse of 95% of modern life, and only a handful of physicists needed computers for very niche usecases that needed next to nothing in resources

You can run a fully functional voip and chat client within that order of magnitude (Ripcord) whereas the 'real client' (Discord) doing the same thing is 10x that.

Don't downplay the resource wastes on nothing of value.

I'd understand if this were about something taking half a giga of ram like too many applications do nowadays. But this is a wrapper adding 8mb of ram. Your efforts should be re-directed somewhere else.

Right? I left it out of my recent thread about BREW development, but we were actually worried because our first app took up 120KB of phone storage space!

Ref: https://news.ycombinator.com/item?id=27220657

Be very careful about this. App toolchains love to create dependencies on services like this without asking you, and then you'll be bombarded with support requests.

This just gave me an idea: Would it be feasible for open source projects to charge money per support request addressed?

Charging for support is one of the main traditional models of monetising open source software.

As someone that uses open source for work I just wish folks would offer a "year of support" which gives me an invoice

Don't be clever about it, don't be per request about it, just give me a number and an invoice.

This actually is a thing with some opensource projects. I know canonical does this.

Per hour would seem ... fair

Per hour would seem "do we need to pay this? We don't really need support do we? We could just buy it if and when we need it"

You're talking fair while I'm talking about the only legitimate way I can pay you for your time as an open source dev.

It would be nice if I could have my client retroactively pay you for your dev time in full but I like working with the client and don't fancy being laughed out of the room

In case you missed the subtext I rarely if ever actually use the support, I can just justify it to bigcorp's beancounters. Chances are you already provide the support for free in Issues anyway but I have a way to pay. I just want people paid at all mate. We can work on fair later

This sounds like your problem and the world you are in. In my world I work for a company that offered a well paid devs months salary to get a bug fixed in OSS. They didn’t have the time soon enough so we ended up fixing it ourselves and doing a PR.

An OSS developer who wants to be paid needs to think like a business. They are more a business that happens to OSS. That would preclude certain OSS products while making others more viable. It is good to strategic. Best for most is to find a company to pay a salary for them to maintain it.

"per support request addressed".

"addressed" may be different from "resolved", and the more people are paying money for things, the more they will want 'resolved' to be in the direction they want. they will be less happy to have their 'resolution' be 'wontfix', even if that technically is 'addressing' the support request.

That's true, and because of that reason I am wondering whether it's possible to make people pay for having their issues addressed rather than resolved. The triaging/addressing process is where many people feel like open-source work is thankless, and throwing money in the mix can help make it feel more fair.

Maybe people will be willing to pay if the cost was lower? Maybe when you file a ticket, you can include a $10 fee to make sure it gets 10 minutes of the developer's time. (Or maybe you can attach $10 to any ticket, not just yours.)

To reduce the kinds of disputes that come up, there would be no guaranteed result other than that the developer spends 10 minutes doing their best to address the ticket and that they leave a reply. If people feel like the devs are just wasting their 10 minutes, they can simply not pay next time.

Actually, the more I think about it, the more I think this is a good idea, even just for the sake of optics: simply having the "paid ticket" there, even if no one uses it, might make people more thankful of the non-paid tickets the devs are addressing. And it offers a great retort/actionable step for those who complain that tickets aren't being addressed.

This idea pops up every month. It really needs to find the UVP. What's going wrong that it never takes off? What's the blocker? What are the buyers missing? What are the suppliers not getting (beside money)?

Hi enatik, I’m 100% your target audience, so I have some feedback.

I use Sparkle + Github Releases to update my apps (you can test the update process at https://fadel.io), and I’ve been looking to automate the process as it’s becoming a hassle. Your landing page’s value proposition isn’t clear to me. Yes updating is a hassle. The leading framework on macOS is arguably Sparkle. How does it do the job better than Sparkle?

I want my process to be fire and forget, as in: notarize the app, generate the appcast.xml, upload the binaries and update the remote appcast.xml after being asked for the changelog, and ideally also test that the update works correctly.

I’m not sure how Pakky solves that, if at all.

FYI I’m currently looking to automate the whole process with a script.

Just an aside for enatik, in the UK pakkly, if spelled wrong as done innocently here, can end up as a very racist slur for Pakistanis. I'd seriously consider changing the name.

Ouch. Agreed, that's the first thing that came to my mind, and it's an unfortunate to see it happen here. Definitely consider a name change!

Wait, do you mean Paki?

It's two whole letters away.

-1 for name change.

I had a similar problem – which I opened sourced here; http://replay.software/bump. Bump basically automates all of the Sparkle signing and appcast creation using GitHub Actions, and then pushes the binary & changelog to AWS automatically with Terraform.

I haven’t used Sparkle myself so I may be a bit off, but as far as I can see Sparkle requires you to constantly update an xml file so it knows what to update. Pakkly allows you to specify a glob to search for in the releases area. So you can simply target myapp_mac_*.zip and your users will automatically be updated when they next start the app. Notarization is a process I’m planning to integrate via a CLI, if possible.

Also, it’s cross platform, if you ever decide to branch out :)

Nice. I'd recommend negating the points mentioned on the landing page and replacing red crosses with green checks. For example,

Often limited to one OS => Supports all desktop platforms

Infrastructure setup takes valuable time away from actually developing your app => Spent time building your app, not update infrastructure.

I feel instead of speaking negatively about other solutions, speaking positively about Pakkly makes me want to try it out more.

> You will receive installer URLs that will stay constant for the duration of your project. You can distribute these URLs to your clients for installation.

It would be a bit more enterprise friendly if you let customers self host? Then again, I'm not sure if enterprises are even the target audience. I wonder how much infosec would like the idea of building the artifacts externally.

for FOSS projects i also prefer to self host

This service does not look transparent at all.

How does it work? What network protocols does it use? What are configuration options? Is this vendor lock-in or I can go self-hosted?

It uses fairly standard HTTPS for update checking (endpoints). I'm planning to write a detailed blog post on how it works technically so hopefully that will answer your questions.

Completely self-hosted solutions aren't currently planned.

The mobile design: layout and margins look out of place on Firefox Android. The lists with red crosses look disjointed.

Header: why do the Sign In and Get Started links point to the same URL? Do you need a Home link for what's essentially a single page site?

The Steps section: could probably be better presented by a video above fold in the future to take far less space.

The Newsletter section: the white background and wide margins makes the section seem like it belongs to the previous section (Step 3).

I think you could use a WP performance/caching plugin to easily improve site performance. My favorite combo right now is Breeze and Cloudflare.

Thanks for the great feedback, I’ll try to cover it all:

The mobile design: I absolutely agree, I didn’t expect so many of our users to come from mobile as the target demographic is desktop developers. I see now that I may have misjudged things a bit. Future plans definitely include a nicer website with better mobile support.

Header: They won’t very soon, Pakkly’s still in Beta, some things are placeholders for future functionality.

The Steps section: Absolutely agreed, we are already working on a video explainer.

The Newsletter section: I thought it fitting into 100% of the viewport height made it distinct.

In regard to caching, we had a caching plugin but it caused some strange layout bugs so we disabled it, I’ll look into those, thanks!

As a desktop developer, I would like you to know that I also have a mobile phone and I use it to read Hacker News during my breaks.

This looks like a very cool project. I wish it was around before I glued together my current hellish multi-platform release system. I will dig into it before I require it again.

Is this kinda like Microsoft ClickOnce (https://en.wikipedia.org/wiki/ClickOnce) but for FOSS?

Yes, but cross platform and works with any app. A paid plan is coming soon so it won't only be for FOSS.

> Use your valuable development time creating your app, not it's packaging.

FYI, “it’s” should be “its”.

Love the idea. Does this use any sort of checksum to protect the clients from potential attacks to your system? I'd feel uncomfortable using this without security being a primary thing featured on the website and explained in detail. I'd also be nervous using a third party service as my delivery/update mechanism for fear of them going out of business and now I have no way to provide updates.

Currently there’s have no way of generating checksums or cryptographic signatures as Pakkly doesn’t enforce any structure on apps. They are delivered straight from GitHub releases so the security considerations are the same as downloading from a browser.

I’m developing a CLI tool to allow signing and notarizing your apps and the installer itself. Hopefully that will alleviate some of the concerns you have.

The third-party service angle is understandable, but I’m not certain how it’s any different from any other third-party service.

There is a reason package managers are so called: their function is to manage packages. Applications should not update themselves.

Not always practical; many apps will never be in distro repos

Hence Flatpak.

Both flatpaks and snaps have been reasonably successful in distributing software in a cross distro way. Once apps reach any of these technologies they don't need to be in any specific distro repo. Snaps, for example, can update automatically silently in the background and it has been used at least by VSCode to bring updates to users.

Also consider that "stores" like ms/windows store, apple's app store, steam, google play store... are all mere glorified package managers which can update packages. Most used operating systems' these days offer such functionality. And yes, time has proven they are practical.

So, Firefox should stop updating itself?

Of course! Firefox never updates itself on my computer, it is a package managers' task to do such a thing.

Package managers aren't designed with this in mind. They're from an old-school development/operations model which doesn't necessarily fit with modern best practices (where app devs are expected to own more of the product lifecycle).

For example, say Firefox is the only package you want to automatically update itself (because I do want those updates), via the package manager. AFAIK, there is no simple generic UI to configure this. You have to be a computer nerd that's familiar with shell scripting and consoles to configure such functionality, or hope that your one package manager has a UI that's both friendly and functional enough to easily configure this. Versus Firefox doing it itself, which is more user-friendly.

On top of that, if you have to wait for a package update, this means new security fixes + functionality have to wait for all distributions to update their packages and push updates, and then for users to adopt the updates. If you need to patch a 0day, it's much faster to simply push the update to the users. And new functionality can be tested and rolled out much faster if you don't have to wait for all systems to get an updated package. One of the most annoying things about Debian is how old their software is, unless you're on -testing, where you basically expect your system to break often.

> Package managers aren't designed with this in mind. They're from an old-school development/operations model which doesn't necessarily fit with modern best practices (where app devs are expected to own more of the product lifecycle).

Package managers were designed with update in mind. Which apt version has no "apt update"?

>For example, say Firefox is the only package you want to automatically update itself (because I do want those updates), via the package manager. AFAIK, there is no simple generic UI to configure this. You have to be a computer nerd that's familiar with shell scripting and consoles to configure such functionality, or hope that your one package manager has a UI that's both friendly and functional enough to easily configure this. Versus Firefox doing it itself, which is more user-friendly.

Gnome software allows me to update a single package. It comes installed by default on most current major linux distros. It has a very simple and intuitive UI.

>On top of that, if you have to wait for a package update, this means new security fixes + functionality have to wait for all distributions to update their packages and push updates, and then for users to adopt the updates. If you need to patch a 0day, it's much faster to simply push the update to the users. And new functionality can be tested and rolled out much faster if you don't have to wait for all systems to get an updated package. One of the most annoying things about Debian is how old their software is, unless you're on -testing, where you basically expect your system to break often.

Not if you're using flatpaks or snaps. Even if you are only using your distros' repos, Ubuntu is now maintained for a reasonably long time, 0days on a browser will reach you very soon. It is nowhere near as long as microsoft does with windows support, but long enough that at least 2 other LTS releases are available before support is dropped.

It seems, from your comment, that you have not used any linux desktop distro for a long time.

I have no idea what this actually does.

Is it something similar to testflight?

Is is an auto-update service? If so, please stop, and just use the platform mechanics (App Store).

This looks like a neat idea! You might want to check the site out on mobile, the updating text in the header seems to change the number of lines that section takes up and makes the whole site jump up and down while I try to read it.

Thanks for the kind words and heads up, I removed the scrolling effect while I decide on a long-term solution.

> Different platforms have different requirements and their users are used to a certain style of installer.

So this means it'll provide repositories for apt-get, pacman, etc.?

The landing page says it supports Windows - does that mean it builds an MSI installer?

If so, how does it handle things like installing Windows services, custom actions etc?

This looks cool but can you share anything about pricing?

The pricing hasn't yet been finalized but it will be fixed per app.

I would post something up as soon as you can. You're front page of Hacker News but right now no one with a commercial app can really think about using it without some sense of pricing.

You can always change it later. Call it introductory pricing or something.

Any apps? What OS?

title gore

Looks interesting for sure. But without knowing any details, signing up with GitHub seems like a big barrier to entry.

Shit son, I’ve been hoping someone would do this. How can I contact you?

I'm hesitant to share my personal email publicly, but you can contact me at contact@enatik.com and I will get back to you ASAP.

Reply on news.ycombinator.com