Friday, February 17, 2017

A developer perspective on portable

  • One developer's view (thanks smaragdus)
  • An argument for local software "I don't think I'd want tools for manipulating local media tied even loosely to the uptime of a remote computer (or network connection)."
  • A breakdown on Installer junk.
  • Advantages that your users gain with portability.

Sunday, February 5, 2017

Analysis of

It comes up every-so-often in my community why anyone would do anything but start and end in the the great project.  I decided to put some notes together why you'd want to go a different route.  As always, I had to add some positive notes as well.

Why avoid
  • Arguably a waste of disk and processor space, especially if the program is already natively portable
  • Lots of people dislike the start screen, which can only be disabled via the launcher or an annoying INI edit/move action.
  • Some programs never get out of "development" status for unknown reasons; governmental system for program addition is unclear to me.
  • Avoids dotNET-based programs - depending on who you talk to, this is either good or bad, but it for example cuts you off from most of the really good screen capture tools.
  • I strongly prefer the non-PA versions of Ditto and CubicExplorer, which I've only had problems with.  Note that these are in the minority as I've been using many other PA programs successfully for years.
  • Seems to rely on one individual for it's success (Haller).  If something were to happen to him, it's unclear if the project would continue.  This is a common concern with many open source projects.
  • I find the non-standard forum system they use difficult to read.

Why go with PortableApps:
  • Ease of updating (this is far and away my favorite part)
  • They have a thorough testing foundation that includes multiple operating systems, whereas we mostly seem to use Win7.
  • Seems to have solid relationships with big companies Oracle and Mozilla to help make jPortable and Portable Firefox happen.
  • Generally more stealth and often help make directories relative rather than static (.\Music rather than C:\Music).
  • Very pro-open source and make a big deal out of license compliance
  • Get programs in front of anti-virus services and help fight the false-positive issue, which we're constantly addressing.
  • Has been able to enforce a freeware status on a lot of programs that have gone the adware/bundleware route.
  • App Store approach is what people are familiar with now, drawing people toward freeware and open source options.
  • Very fast, reliable servers unlike any number of distributed freeware options which regularly break.

USB drive won't stop being "read-only"

Want to note about a trick that really helped me unlock one of my drives that was mysteriously set to read-only.  Note that this uses the command-line "diskpart" tool.

Why open source software is important

I wonder how much development time has been spent since the dawn of computers that is just sitting in a closet somewhere?  How many great programs, graphics, interfaces, and ideas have been written for computer users that for some odd legal reason never saw the light of day?  An open web ensures that software doesn't die; once its out there and once the code is available, it becomes part of the community of effort that lasts well beyond any one person.

Related quote:

"That's one of the things that Ellison, and Microsoft for that matter, don't get. You can't kill open-source projects. Companies come and go, but popular open-source programs like MySQL just keep rolling on." - Steven J. Vaughan-Nichols on Oracle and MySQL.

[When] are you moving to 64-bit?

This is a conversation I always wanted to respond to but I sort of missed my window.  As such, I decided to post here:

But that was about 3 years ago IIRC, so I'm curious about the reason(s) that make you stay in the 32-bit land as it's obvious that you'll have to struggle more and more against the flow? (source)

In fairness, there are still millions of perfectly good, plenty fast machines still in the 32-bit instruction set.

That said, I'm a bit of an outlier.  I'm running a 64-bit Mac with Windows in a 32-bit VM and I could conceivably switch or run a 64bit system right alongside the 32-bit (although that would be a bit of a pain).  The reason I'm keeping it at 32-bit in order to maintain compatibility with the many great programs we host here on the site that may or may not agree with a 64 bit API/handles and whatever compatibility layer Microsoft and Intel have tried to include.  I lost a few good programs when I bumped up from WinXP so I'm just dragging my heels.

With Linux, Google, and Apple, it's easy to recompile popular programs with minor modification because either the source code is open or owned by them.  However freeware projects that have been abandoned are out of luck.  I constantly see this happen in the Apple space, which is why I barely use my Mac.

Inevitably I'm going to have to move to 64-bit, especially as more and more development work is done to embrace available speed optimizations.  If that sounds silly, there are very few programs I've seen that embrace hyper-threading / SMP and those systems have been around for at least 20 years.

Portable automation tools

We don't quite have a category for it, but these are some portable automation tools:

Pulover's Macro Creator


Mouse Recorder Premium

TyperTask (my fav)

Friday, January 20, 2017

The scale of portable

When we're talking about portability, we're not just talking about "can it run from a USB drive"?  We're talking about whatever settings you change, they stay with the program, regardless of the medium it's launched from (USB, DropBox, OneDrive, etc.)  Re-running a process or re-changing a setting on each computer is not portable.

Most programs work on a scale from very portable to not portable at all:
  1. Command-line tools are very rarely anything BUT portable so we don't spend much time on them
  2. Writes unimportant data to C:\Users\USER\AppData\, but for example just a recent file list.  This is one that falls on the line and may be acceptable to some users.
  3. Runs outside of Program Files folder and without dependencies, but but doesn't write settings to the local folder.  This is considered "no-install" but is not portable.
  4. Windows Explorer integration by it's very nature isn't portable.  Registry entries don't transfer from computer to computer.  You would have to run this process every time you launched the program and it leaves behind junk each time you do so.
  5. Program requirements like DotNET 4.0, which mean that functionality on older computers (like WinXP) isn't a sure thing.