SwiftSearch

[billon]

Added to the database, please vote

[billon]

Also for 64-bit OS users: you can only not use e.g. Resource Hacker for extracting 64-bit version, but also 7-Zip, opening it through "Parser" method - "Open Inside #"

SwistSearch_x64.png (4.26 KiB) Viewed 12754 times

[Midas]

Niccce.

I'm still on a very old v4.2.1 but Swiftsearch has been my quick searcher of choice -- and not my main only because it didn't follow symbolic links...

[smaragdus]

SwiftSearch version 6.1 crashes on start while version 6.0 works fine for me (Windows 8 x64). By the way there is absolutely no way to check which version one is using.

[lastaltoid]

Version 6.2 is available. The readme.txt says the crash problem is fixed. Seams to work normally.

[Midas]

By the way there is absolutely no way to check which version one is using.

True. Not even file properties can help you there. I keep a sidecar file with version details just for peace of mind. It's unfathomable why the dev would torture his users in such a devious way...

Incidentally, SwiftSearch doesn't seem to save any settings anywhere. E.g., if you uncheck the "Gridlines" option from its "View" menu, it will always be checked on next launch (maybe the afore mentioned Resource Hacker can be of help here, dunno).

Plus, none of the recent versions (v6.x+) seem to work on my Windows 7 x64... I always get an error on launch.

CORRECTION: Swiftsearch v6.2 starts alright!

[smaragdus]

I can confirm that SwiftSearch version 6.2 does not crash on start.

The developer refuses to add any version information (be it file version or "About"):

Regarding version numbers, other people have other mentioned them; please see the other discussion threads for my responses regarding that.

I did dig into the forum and found some irrevelant rant about version information.

Lack of version information hinders bug reporting in different ways- one should guess the version number by date if the particular version is not deleted from SourceForge and one cannot prove that a particular version is buggy. For me the developer misunderstands the meaning of simplicity, his comprehension of simplicity alludes to confusion, ignorance and obscurity.

I am done with SwiftSearch, I put both the program and its developer on my black list.

[user6878827]

I did dig into the forum and found some irrevelant rant about version information.

Lack of version information hinders bug reporting in different ways- one should guess the version number by date if the particular version is not deleted from SourceForge and one cannot prove that a particular version is buggy. For me the developer misunderstands the meaning of simplicity, his comprehension of simplicity alludes to confusion, ignorance and obscurity.

Hi! Developer here. I'm trying to understand your comment; I hope you can help me do so.

I never require version information for bug reports. If I ever ask for it and you aren't sure, it's not like I ignore your report -- instead, I just figure out the version number myself, and I can do that easily if you just let me know the file size. Why does a version number make any difference here?

Please also see below.

True. Not even file properties can help you there. I keep a sidecar file with version details just for peace of mind. It's unfathomable why the dev would torture his users in such a devious way...

I'm sorry, I didn't intend this to be torturing anyone.

The problem I see with a version number is that if I include it and make it easy to find, the following is far more likely to happen:
1. You notice a bug in the latest version.
2. You download an earlier version.
3. You see that the earlier version doesn't have that bug.
4. You keep using the earlier version and wait for the bug to be fixed.

Notice that in such a scenario, users will be far more likely to never report the bug, because they found an old version that works.
This is good for that user, I agree, but it's not good for everyone else who has a buggy version. If I find out about it, I can actually fix it.
(And you saw that I actually fix it! I fixed the latest bug in a matter of hours. It makes me sad that you think your bug report would somehow go unresolved just because of a version number.)

Does this make sense? It's not that I'm against version information inherently; it's that I do not see a benefit and yet I see downsides to it: it can harm the users of the programs indirectly as I explained above. That does not seem like a good trade-off to me. If you could let me know of a good reason for version information, I will include it. I just haven't received a good reason yet; I've only seen a desire expressed without a compelling explanation, and without any acknowledgment of the problems that it may cause.

However, I've updated the Files tab to include prior version numbers, in case for some reason you absolutely need version numbers (again, you don't need them for bug reports).
You can find them in the version table if you scroll down here: https://sourceforge.net/projects/swiftsearch/files/

[Midas]

Thanks for the clear and reasonable exposé, dear user6878827.

I would still welcome some kind of landmark to help me decide. I have always duly upgraded SwiftSearch in the past, thinking the lack of versioning was the result of oversight or laziness. I am more reluctant to do it now in consequence of the recent crashes. I.e., I keep both my versions side by side for the time being.

To tell you the truth, I am not sure your system works up to your intentions. I think the only way to do what you want is to time-bomb the executables and that is a serious no-no in my book. Let the user decide, I say.

You could always implement some kind of automatic opt-in reporting for bugs -- I simple automated call to a feedback webform would do nicely, thank you (at least that is the route taken by another utility I use a lot: 3D Youtube Downloader).

[user6878827]

Thanks for the clear and reasonable exposé, dear user6878827.

I would still welcome some kind of landmark to help me decide. I have always duly upgraded SwiftSearch in the past, thinking the lack of versioning was the result of oversight or laziness. I am more reluctant to do it now in consequence of the recent crashes. I.e., I keep both my versions side by side for the time being.

To tell you the truth, I am not sure your system works up to your intentions. I think the only way to do what you want is to time-bomb the executables and that is a serious no-no in my book. Let the user decide, I say.

You could always implement some kind of automatic opt-in reporting for bugs -- I simple automated call to a feedback webform would do nicely, thank you (at least that is the route taken by another utility I use a lot: 3D Youtube Downloader).

Thank you for the reply!

I'm very confused why the lack of versioning affects your inclination to upgrade! Would you mind elaborating on that? If the crash made you reluctant to upgrade, that's quite understandable, but I'm confused how that would have been any different if there had been a version number? It would have still crashed, so you would have still needed an older version, right? Similarly, if it hadn't crashed, then the version number wouldn't have changed anything either, right?

Regarding automatic opt-in bug reporting: I wish it was this simple. The first problem is that I would probably need to buy a domain name and pay for a server for this, since I don't believe SourceForge has this built-in. (?) That would require spending money, which, while not a lot, is not something I intended to do for an open-source project for which I receive no payments. The second problem is that there are privacy implications -- because I can't prevent a bug report from happening to contain sensitive user information, now I feel I would need to worry about the legal aspects, write a privacy policy, make sure to follow it, etc... issues that as you can imagine aren't very fun to deal with, especially for a free open-source project! And then there's the problem that I would be responsible if the server turned out to have a security vulnerability... etc.

[__philippe]

@user6878827

Pulease...

Software versioning information is a well established custom taken for granted
by most well regarded software developers and expected by their savvy followers;

By arguing against using such a standard system to differentiate successive program versions,
you are merely turning away potential users of your products…

[webfork]

The problem I see with a version number

We don't really have a way to deal with programs that don't have a version number. You're welcome to use the release date, but the functionality doesn't exist on the site to ignore version numbers.

I personally don't understand your rationale, but as moderator I'm just explaining the situation in terms of the system we have here for managing new software versions.

[Midas]

I'm very confused why the lack of versioning affects your inclination to upgrade! Would you mind elaborating on that? If the crash made you reluctant to upgrade, that's quite understandable, but I'm confused how that would have been any different if there had been a version number?

I never implied a correlation between the two. It's just that among the myriad programs that I use, it makes it easier to instantly discern which one is the culprit, instead of having to retrace my (absent) upgrade history just to make sure. Here again, consider it a userland prerogative.

Regarding automatic opt-in bug reporting: I wish it was this simple. The first problem is that I would probably need to buy a domain name and pay for a server for this, since I don't believe SourceForge has this built-in.

Dunno about SourceForge, but even Google Docs will allow you to do that.

[webfork]

I guess the developer gave up on the "no version number" angle and we're now at 7.2 (thanks billon for updating). Good to see.

If the dev shows up here again, I did want to point out that using the CC license folks recommend against it's use in software: https://creativecommons.org/faq/#can-i- ... o-software

[user6878827]

Yeah, unfortunately I learned about that long after I put up the project... I don't see a compelling reason to change it now though... I'd rather have it stay consistent.