In my case, they managed to BACK OUT some inter-account transfers I made on Wednesday, which screwed up some things (after rent payments and other things).

At this point, I have a negative amount in my checking account (it's all in savings), with no way to move money into it. Attempts to purchase with this account or draw money from it fail, so I have no choice but to pay for things with credit card. If I get billed either credit card interest or any sort of debit fees on the checking account, it will be their fault, and not because I waited until the last minute for whatever.

But the worst thing is that people aren't getting PAID. Some people do live paycheck to paycheck, even if it's only occasionally.

You're forgetting problems steps 3) and 4)

3) Someone needs to port it, and quite often that doesn't happen (or doesn't quickly. It's pretty rare that I get a new app update even the first week it's available, and out of luck if I'm running an oldish distribution)
4) It needs to be open-source for this model to work. Some software isn't. =)

I do like the idea of having a central application manager, though There is software to do that with Windows and OS X, though the distrib/repository method definitely works better for this. I guess the Mac App Store will serve this need (like similar software on IOS/Android), though obviously that's not ideal either.

Why in the world would you need an installer for something like this? I don't understand why 99% of applications are ever distributed that way, except for poor OS design or just bad developer habits.

OS X (and OpenStep) did it right earlier in the sense that the app is a self-contained unit, well-laid out and hierarchical but a single unit to the user. "Installation" typically involves a single move command or drag-and-drop of a single "file" (bundle), and portability across systems cannot be beat (providing the developer the ability to distribute a single bundle that transparently functions across as many platforms as exist for the OS) . It's a beautifully well-designed piece of work. The choice of usability/ease of distribution versus some amount of bloat is left to the developer, and I think it's a great trade-off.

> You're stuck at the mercy of some packager. This is the same situation as MacOS.

Do what now? In MacOS (or Windows, or...) typically the packager is the original developer, and software isn't going to be released without a package (which is a much, much simpler task due to a number of factors; platform fragmentation is only one of them). With Linux, non-commercial developers often are "lazy" in the sense that they often simply leave the program to be compiled/ported by the user, or wait for some 3rd-party to port it. In that case the need for a packager is more severe. But I think you're missing the point - we're talking about the distribution/repository model here, and what you're talking about is alternatives to that model.

> 3) What if the application you're trying to install is - horrors - not open-source?
Some of them use the "OpenStep approach".

And good on them. But you're off-topic. The points you're replying to was re: the parent's posit that in Linux, software installation is "easier" thanks to the distribution/repository model.

...How is the parent post a troll?

And yes, Linux really should look into the work done by NeXt on App Bundles in NeXtStep/Openstep (and inherited by OS X). It's a beautiful design.

> Installing software on linux is easier than on windows or osx.

Hahahahahahahaha

On OSX, 99% of application installs require one of the following:
1) mv Application.app
2) Drag application to any destination you want.

That's it.

> Either
> apt-get install foobar
> or find foobar in the GUI package manager/app store/software center.

That's great. Now:
1) What if the application you want to install hasn't been ported by the application maintainer (particularly smaller, less popular applications)?
2) What if the VERSION of the application hasn't been ported yet (I regularly need some new version of software but the update isn't posted to the repository for months)
3) What if the application you're trying to install is - horrors - not open-source?
4) What if you're using a somewhat older distribution and packages aren't being updated often or at all anymore? (And "older" in this case may mean only two years. Or less.)
5) What if you want to install multiple versions of an application?
6) What if you want multiple instances of the application, or to control where the application is installed?
7) What if you want to install two different pieces of software that have irresolvable library conflicts (possibly due to software not being updated on a regular basis)
8) End up in a broken state because package management and extreme library sharing like this is inherently more fragile?
9) Don't want to wait for 18 different pieces of software to be installed/updated just because you want to update your media player app?

I run into these problems on a regular basis. It drives me absolutely insane.

No. Not even a little bit.

That's probably another use, but I really don't think that's the main place where it'd be useful. I DREAM of being able to just download an application archive, extract it *anywhere I want*, and just run it. Just use it, without having to worry. Any application - not the apps (and versions) that some distribution maintainer has gotten around to porting to my flavor.

Maybe not, but it's something that a number of people that want to use Linux want to do. Including me. For the life of me I can't understand why people would resist this. If this takes off and works as well as advertised it will save all of us a tremendous amount of headaches.

Why is this a kludge?

App portability and dependency problems has been one of the Achilles Heels of Linux since, well, forever. We laughed at Windows for DLL-hell, and if anything package managers seem like the ugly kludge way to resolve it to me. I wonder how many tens or hundreds of thousands of man-hours have been lost dealing with these sorts of issues. It's by far the #1 thing that's prevented me from using Linux for those purposes, and I'd REALLY like to use Linux (though there are others). Hell, it's the main thing that's kept me from taking Linux seriously outside the server room. Particularly since people really don't seem to get why this is a problem.

- I should be able to install an application QUICKLY and easily. There's no reason why "installation" should be more complicated than "copying/extracting the binaries to wherever I want them to go".
- I should not be dependent on some third party to get around to porting each version of software to my flavor of Linux. When a new version of Wireshark or VLC or whatever software comes out, I should be able to install it *quickly and simply* without waiting on package maintainers to get around to it (even if some are very responsive)
- Along with the above, I shouldn't be in a state where I can no longer easily install applications because I'm using a somewhat older distribution (and packages are no longer being maintained for that version)
- Although the option should be there, it should never, ever, ever, ever, ever, ever, ever, EVER be considered "acceptable" to expect users to compile an application to install it (and all the potential headaches of getting that to work, including hacking make files, dealing with dependencies, patching the software, actually doing C++ debugging, etc).

Balloon up my applications with static libraries. Please. The trade-off in system administration headache would pay for itself 100s of times over.

There just wouldn't be as many PCs. Something else would have emerged. Nothing that exists today, I'd say. Maybe better, maybe worse.

"You are missing his point. On a non-deduplicated system if one block goes bad you lose one file, on a deduplicated system you can lose any number of files due to one bad block."

This is true, but he was saying "This is the opposite of RAID...it squeezes every bit of redundancy out of your data". Like having random duplicate copies of files scattered around a filesystem was a redundancy mechanism that is somehow on-par with RAID, and so enabling dedupe means that you have eliminated a serious data redundancy mechanism. It's true that it might be a higher-impact loss when you lose a single file (and require more restores or mean more users will be impacted), but it's not a situation where you've suddenly killed your data backup plan and lost all your data. You're just not going to be using random duplicate copies of files on your FS in this way.

"Personally, I'd be _terrified_ of using dedup for primary storage. What this does is exactly the opposite of RAID - it squeezes every last bit of redundancy out of your data, and makes everything dependent upon the integrity of your blockpool database. Loose a single blocklet and you stand to lose _all_ of your data. "

Dedupe reduces multiple copies of the same data *on the same storage*

I think you're implying that having - probably purely at random - multiple copies of some files on the same FS is somehow a proper backup/redundancy strategy. It sounds like you're saying that WITHOUT dedupe, if a file got corrupted you'd at least be able to go restore it from some other copy of the file. I can't imagine how this is true - you can't rely on chance copies of multiple files to be able to recover from a file corruption. That's crazy. With or without dedupe you better have BACKUPS of the data on some other storage.

Maybe you mean that if something gets corrupted in some of the deduped data that you'll lose ALL dedupe data (so maybe half of your filesystem or something). Most dedupe technologies don't work that way - if corruption occurs it will impact the actual data or possibly file that was affected (and obviously each copy of that data throughout the FS). But not more than that.

The NS20 goes head-to-head with that NetApp box, so I'm not sure if that's true in this case (need to be fortune 10 to afford it). And from what I read a couple of days ago, it's the most commonly sold NAS product in this class...which is why I thought it was weird not to include it in the review. I'm curious what they would have said about it.