Hacker News new | ask | show | jobs
by nekitamo 1653 days ago
I've been a customer since ~2010, and have been paying out of my personal pocket the $469 / year support renewal for a standard IDA Pro named license, which I've carried with me through various jobs in my career.

The new subscription model will almost double my costs ($900 / year), all while I've been getting less and less value with each update. Furthermore if I ever stop paying, I will lose access to the product.

Whereas if I stop paying now, I will maintain indefinite access to what I currently have.

I think I simply won't renew next year, and will rely on Ghidra to fill any gaps going forward.

7 comments

> Furthermore if I ever stop paying, I will lose access to the product.

Wow, not even a perpetual fallback license?

I wasn't super thrilled when Jetbrains switched to a more subscription-based system, but being grandfathered in (so I didn't have to restart the subscriptions as if I were a new client), the heaps of existing goodwill they'd built up, made the changeover much less of an issue, and super importantly finally listening to customer and adding perpetual fallback licenses alleviated much of the fear.

The real reason for many subscription models is to juice more revenue from users, charging over time allows for a higher price with less sticker shock.
The real reason for the software as a service model is that it makes it easier to extract/capture value. Many SaaS offerings would be better at providing value to customers with non-SaaS architectures, unfortunately providing value to customers is second to providing value to shareholders.

Don't pay for SaaS, don't encourage this bullshit. If foss offerings don't cover your usecase piracy is better for humanity than paying.

So don't pay the engineers that built the product and continue to maintain it?

That's fine with fixed priced software if the software is static and frozen in time, but most software is living and breathing and requires continual investment.

You can absolutely use an old WordStar license. In fact, several notable authors do.

> So don't pay the engineers that built the product and continue to maintain it?

Saas isn't the only way to pay people.

> most software is living and breathing and requires continual investment

Is it though? or is this broadly another side effect of value extraction focused engineering? I'm quite happy to buy a new version if it makes my life notably easier. CS2 is broadly a better experience than CC, etc. etc.

> > So don't pay the engineers that built the product and continue to maintain it? Saas isn't the only way to pay people.

> Saas isn't the only way to pay people.

> It kind of is if you have a product that people expect updates for, or you have to have very high prices, or a secondary source of income.

> > most software is living and breathing and requires continual investment Is it though? or is this broadly another side effect of value extraction focused engineering? I'm quite happy to buy a new version if it makes my life notably easier. CS2 is broadly a better experience than CC, etc. etc.

But are you happy to pay for better architecture that doesn't have shiny new features? Or support for new X (depending on the product this could be image formats, it could be architectures)? etc

To be clear I am not saying I want subscription based software, but I understand the business argument for it.

> But are you happy to pay for better architecture that doesn't have shiny new features? Or support for new X (depending on the product this could be image formats, it could be architectures)? etc

Depends on what product, and my use case.

> To be clear I am not saying I want subscription based software, but I understand the business argument for it.

Has nothing to do with more supported X or better architecture, its just about money. In fact SaaS offerings are often compromised and worse of than when they were standalone (at least in my experience with software that made transition from standard releases to subscription).

Additionally in my experience with software that went that route (standard paid releases to subscription) that just signals that the customer milking has become, and pretty much any new feature is looked at from how can we milk it standpoint.

There was once set of Christmas themed console controllers (one Red, one Green) with the model name "Profit Driver"

For whatever reason at the time, that opened my mind to why people do things

I'm a big fan of the radare2 suite. The integration of its ecosystem/plugin support is phenomenal.

Only the decompiler is better in Ghidra, IMO, but I'm sure there's a plugin for that.

There is. Rizin also has some interesting improvements (like mew save by serialization of state instead if command sequence) which is nice since it initially looked like a CoC fork.
For integration with Ghidra decompiler there's rz-ghidra[1]. It is also bundled in the Cutter[2] releases[3].

[1] https://github.com/rizinorg/rz-ghidra

[2] https://cutter.re

[3] https://github.com/rizinorg/cutter/releases

I'm in the same boat. It's finally passed the point where I'd rather spend a few slow weekends adding missing QoL features to Ghidra then renew IDA.
This is going to increase my costs from $4800/year to $8000/year, and yeah, no more perpetual license.

I’ve been paying for Hex-Rays out of my own pocket for a decade because it’s a great tool, but $8000/year for a personal license subscription? Forget it.

Just make sure you get the latest Ghidra update with the log4j issue addressed :)
... and readdressed. https://logging.apache.org/log4j/2.x/security.html

> It was found that the fix to address CVE-2021-44228 in Apache Log4j 2.15.0 was incomplete in certain non-default configurations. This could allows attackers with control over Thread Context Map (MDC) input data when the logging configuration uses a non-default Pattern Layout with either a Context Lookup (for example, $${ctx:loginId}) or a Thread Context Map pattern (%X, %mdc, or %MDC) to craft malicious input data using a JNDI Lookup pattern resulting in a denial of service (DOS) attack. Log4j 2.15.0 restricts JNDI LDAP lookups to localhost by default. Note that previous mitigations involving configuration such as to set the system property log4j2.noFormatMsgLookup to true do NOT mitigate this specific vulnerability.

BinaryNinja... Switch to that.