[afghanPower]

I get (maybe) your argument when it comes to Windows 7 -> Windows 10, but I think you're overestimating how hard it is to get up and running with Arch Linux. Following an Arch install tutorial shouldn't take anyone here on Hackernews more than 2 hours to get their DE, networking etc. up and going.

You should try it. It's fun!

[cr0sh]

Arch isn't that hard to set up - I'll agree with you there. Where it falls down, though, is when you need to install something where there isn't a package for it.

Now, of course, you could just go old-school and "manual install" whatever you want. But let's say you didn't want to do that, because you got tired of having a system full of cruft due to all these funky pieces of software scattered about the system that the package manager had no clue about - oh my!

So - you want to install the software as a package under Arch. Oh - and just to make things more fun, the software is something proprietary and closed-source. There is more than a few bits of useful Linux software out there like this - much of it niche areas where a) probably no one else in the Arch community uses, and b) it's proprietary - so you can't distribute it anyhow.

What does Arch require you to do in this situation? Well - last time I looked anyhow - and that was a couple of years ago, so maybe something has changed... It seemed to me to create an install package for a piece of software, the process (according to the docs) was to install the software "manually" and keep track of where everything goes. Then, once you have done that (and the software is running fine), you are supposed to create your package manifesto (or whatever it was called) that tells the system how to install it, then take all the parts and bundle them up (as a compressed file of some sort) with that manifesto. Oh - and then manually "uninstall" your software you installed, then use your new package to re-install your now-packaged proprietary software.

That's basically the process I read about for any kind of software package for Arch; it was a very heavy manual process. While other package management schemes do require some manual effort, none of them that I recall seemed to require as much effort as Arch's did. This wouldn't normally be an issue with most open-source software, because once you made that package, it could be distributed and used by the community. But for a proprietary software package, only you could use it - so it was a ton of extra work for little gain in the end.

Don't get me wrong - I liked Arch, and their community support and forums, wiki, etc - is pretty top-notch (I like to use that part of the ecosystem myself for help and hint purposes when I need it). I honestly think it is a great distro, but it does have some drawbacks to it (and they probably don't have good solutions, either).

[wallacoloo]

> It seemed to me to create an install package for a piece of software, the process (according to the docs) was to install the software "manually" and keep track of where everything goes. Then, once you have done that (and the software is running fine), you are supposed to create your package manifesto (or whatever it was called) that tells the system how to install it, then take all the parts and bundle them up (as a compressed file of some sort) with that manifesto. Oh - and then manually "uninstall" your software you installed, then use your new package to re-install your now-packaged proprietary software.

This might be technically correct (not completely sure), but hugely misleading. Packages are defined by PKGBUILD scripts. When you run `makepkg` to create a package, it creates a directory called $pkgdir. In your PKGBUILD, you just delegate to whatever installer came with the source code & tell it to install into $pkgdir. e.g. `make install --prefix=$pkgdir`. makepkg takes all the files in $pkgdir and tars them and bam - there's your package.

If you look in most PKGBUILDs, they contain some metadata (where to get the sources, etc), and then it's more or less:

    build() {  
        cd "$srcdir" && make  
    }  
    package() {  
        cd "$srcdir" && make install --prefix="$pkgdir"  
    }

That's all you need for quite a few packages.

[JdeBP]

cr0sh posited that the application being packaged was not in source form. So perhaps the hugely misleading thing is to argue against xem based upon how one packages up things that are in source form. (-:

[wallacoloo]

Well as long as it ships with an installer, the above method still works - just omit the build step altogether (do a chroot if the installer doesn't offer a choice of where to install). If it doesn't have an installer, but comes self-contained, then just `cp $srcdir $pkgdir/opt` & call that good.

And if you're dealing with a non-source package that doesn't have an installer and isn't self-contained, then installing/packaging it is difficult on any OS - not just Arch!

For reference, here's a PKGBUILD for a non-source, proprietary application. It's pretty much as above, but includes some fancy .desktop files & such, too. https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=disco...

[JdeBP]

In fairness, that's pretty much how you are going to have to package a binaries-only software with most package management systems. Install the binaries. Make a package description of those binaries.

It's manifest, by the way.

[minitech]

Way more painful to make packages for Debian, IME, but I avoid making packages altogether:

> Now, of course, you could just go old-school and "manual install" whatever you want.

Yep, stop right there, do that.

[digi_owl]

I worry more about the long term support workload than the initial install.

[dTal]

I found this to be a real problem with using Arch in production. Updating is a bit of a catch-22: if you upgrade frequently, the workload of keeping up with the minutiae of not breaking your system is overwhelming. And the longer you leave it, the closer the chances of breakage when you do approach 100%. Result: you inevitably fall off the update treadmill at some point, usually during some sort of crunch time, and then never update again because who wants to tell their boss they spent a day debugging a self-inflicted problem? Safer to leave it alone and get on with your work.

This is why I switched back to Debian. Updating is stress-free and there's no downside to doing it as often as you like.

[anowell]

fwiw, I find the long term support pretty minimal. I'm only slightly more conservative in my use of`pacman -Syu` than I would be with `apt-get dist-upgrade`. If I notice a kernel or DE upgrade, I might hold off until the weekend on the off-chance that it needs a bit of extra maintenance. I appreciate handling these changes in smaller batches, as opposed to the 6-month system-wide major upgrade cadence. Of course, if I was just jumping between LTS releases, maybe only dealing with serious maintenance every other year would be an appealing trade-off.

[anowell]

(of course, I don't mean to undermine the argument for hesitating to jump to Arch on the grounds of maintenance. It certainly takes thinking about maintenance more often.)

[bsder]

> I think you're overestimating how hard it is to get up and running with Arch Linux

Not really.

Arch was a PITA. FreeBSD has a smoother install (not a compliment to Arch).

[oldsj]

And OpenBSD installation is even smoother than FreeBSD!

[peatmoss]

I didn't touch OpenBSD from, let's call it, the latter half of George Bush's presidency through the first half of the Obama administration. My first install of OpenBSD in years was a moment of "oh this old thing still?" followed by "huh, that was just as easy as I remembered."

It's all about audience. OpenBSD's installer is a thing of beauty for technical people. I can see where it would be daunting and texty to someone who's never touched a command line, but that isn't the audience.

At this point, I feel forcing technical users through a plodding GUI install wizard is as cruel as making grandma install OpenBSD with a complicated RAID configuration and volume encryption.

[wry_discontent]

I installed Arch earlier this week. It took two beer's worth of time to do.

Followed the instructions, hit a few snags, and resolved them by reading the wiki.