It’s good practice to run the deployment pipeline on a different server from the application host(s) so that the deployment instances can be kept private, unlike the public app hosts, and therefore can be better protected from external bad actors. It is also good practice because this separation of concerns means the deployment pipeline survives even if the app servers need to be torn down and reprovisioned.

Of course you will need some kind of agent running on the app servers to be able to receive the files, but that might be as simple as an SSH session for file transfer.

Yes, exactly that.

That’s probably okay! =) There’s some level of pragmatism, depending on the sort of project you’re working on.

If it’s a big app with lots of users, you should use automation because it helps reliability.

If there are lots of developers, you should use automation because it helps keep everyone organised and avoids human mistakes.

But if it’s a small thing with a few devs, or especially a personal project, it might be easier to do without :)

Sure, but having a hands-off pipeline for it which runs automatically is where the value is at.

Means that there’s predictability and control in what is being done, and once the pipeline is built it’s as easy as a single button press to release.

How many times when doing it manually have you been like “Oh shit, I just FTPd the WRONG STUFF up to production!” - I know I have. Or even worse you do that and don’t notice you did it.

Automation takes a lot of the risk out.

I’m sure there’s nothing wrong with the program at all =)

Modern webapp deployment approach is typically to have an automated continuous build and deployment pipeline triggered from source control, which deploys into a staging environment for testing, and then promotes the same precise tested artifacts to production. Probably all in the cloud too.

Compared to that, manually FTPing the files up to the server seems ridiculously antiquated, to the extent that newbies in the biz can’t even believe we ever did it that way. But it’s genuinely what we were all doing not so long ago.

Yes

My banking apps work fine on Calyx.

Banking apps normally check for rooted phones as the thing they don’t like. Because pixels come with an unlocked bootloader, you don’t need to root the phone to install a custom ROM, and so banking apps are still okay.

Haha yeah, fair enough. Applogies for turning your deserved whinge into a serious question.

Wrangling annoying customers is always the most annoying part of the job isn’t it. How nice it would be to spend more time programming…

Technical requirements are often ambiguous when written as free text, the way someone would speak them, because as you have discovered the free text fails to capture where the linguistic stress would be that disambiguates in speech.

Instead, I suggest using a format that is more suited to text.

I would recommend a table. Email the customer back with your current interpretation of the requirements, with a column for outcome and a column for value. Ask them to check and sign off on the table, or to correct the table where it is wrong.

Example:

There are edge-cases with if outcome can be "Complete or Cncelled

My biggest problem is security updates.

The “x years of upgrades” model is okay when it’s for an app, where you can just keep using it with the old feature set and no harm is done.

But Unraid isn’t an app, it’s a whole operating system.

With this new licensing model, over time we will see many people sticking with old versions because they dont want to pay to renew - and then what happens when critical security vulnerabilities are found?

The question was already asked on the Unraid forum thread, and the answer from them on whether they would provide security updates for non-latest versions was basically “we don’t know” - due to how much effort they would need to spend to individually fix all those old versions, and the team size it would require.

It’s going to be a nightmare.

Any user who cares about good security practice is effectively going to be forced to pay to renew, because the alternative will be to leave yourself potentially vulnerable.

deleted by creator

Yup, my comment mentions the parity disk :)

Good to emphasise that a bit more though.

I agree as far as the feature set is concerned, but software unfortunately doesn’t exist in a vacuum.

A vulnerability could be discovered that needs a fix.

The operating system could change in such a way that eventually leads to the software not functioning on later versions.

The encryption algorithms supported by the server could be updated, rendering the client unable to connect.

It might be a really long time before any of that happens, but without a maintainer, that could be the end.

The clue with Unraid is in the name. The goal was all about having a fileserver with many of the benefits of RAID, but without actually using RAID.

For this purpose, Fuse is a virtual filesystem which brings together files from multiple physical disks into a single view.

Each disk in an Unraid system just uses a normal single-disk filesystem on the disk itself, and Unraid distributes new files to whichever disk has space, yet to the user they are presented as a single volume (you can also see raw disk contents and manually move data between disks if you want to - the fused view and raw views are just different mounts in the filesystem)

This is how Unraid allows for easily adding new drives of any size without a rebuild, but still allows for failure of a single disk by having a parity disk - as long as the parity is at least as large as the biggest data disk.

Unraid have also now added ZFS zpool capability and as a user you have the choice over which sort of array you want - Unraid or ZFS.

Unraid is absolutely not targeted at enterprise where a full RAID makes more sense. It’s targeted at home-lab type users, where the ease of operation and ability to expand over time are selling points.

Been using unraid for a couple of years now also, and really enjoying it.

Previously I was using ESXi and OMV, but I like how complete Unraid feels as a solution in itself.

I like how Unraid has integrated support for spinning up VMs and docker containers, with UI integration for those things.

I also like how Unraid’s fuse filesystem lets me build an array from disks of mismatched capacities, and arbitrarily expand it. I’m running two servers so I can mirror data for backup, and it was much more cost effective that I could keep some of the disks I already had rather than buy all-new.

Right.

What they really want to say is “We aren’t interested in investigating your personal theft. Things get stolen all the time and we really can’t be bothered. You are not important to us.”

But they can’t say that, so they instead throw out some excuse that puts the onus back on the other person.

Agree. I changed the way that I purchase games by setting myself a rule:

• Buy it only if you are going to play it TODAY

Previously I had a library of games I had never played because I bought them on sale and they just sat there, unplayed, making me feel sad and stressed.

Purchasing only when I want to play now is both less stressful, and less expensive!