We decided to take the Arch Linux based distribution Antergos out for a test drive. Here’s how it handled, out in traffic and on the track.
A few months back, a fellow tech writer mentioned in an email exchange that I might try using the Arch Linux based Antergos distro as a way to grab the latest and greatest versions of popular software titles for review. Mainly because of Arch’s community repositories, in which users suggest and vote on packages to be included, many popular software titles are available within days after a new release. And since Antergos is a simple install compared to Arch, it would be easy to quickly throw up an installation on a test machine just to look at the latest and greatest from LibreOffice, GIMP and the like.
Photo courtesy Antergos
Like Manjaro, Antergos bills itself as an easier way to experience Arch. The distro was first released in 2012 as Cinnarch, using the Cinnamon desktop, but changed its name in 2013 when it switched to using GNOME 3 as its default desktop because of difficulties keeping Cinnamon current in a rolling release, due to GTK compatibility issues. Almost immediately after its initial release, Cinnarch/Antergos developed a sizable following and currently ranks 22nd on DistroWatch’s “Page Hit Ranking.”
About a week and a half ago, I finally found time to take a look at the distro. I figured this would be an interesting experiment, as I’d never played around with Arch nor any of it’s derivatives before. I wasn’t disappointed.
Installation
After downloading the latest ISO (2016.4.2) using BitTorrent and creating a bootable USB drive, I booted into live mode on our test machine, an older System 76 Pangolin laptop with a quad core 2.53 GHz processor and 4 GB RAM. As usual, I didn’t look around much while in live mode, my main purpose being to check that Wi-Fi was working before installing to the hard drive. With a wireless connection made, I clicked “install” and sat back to watch the fireworks.
Antergos uses an installer called Cnchi, a name which is probably derived from the distro’s original moniker. The installer is in beta and evidently has been for years, so users are given the use-at-your-own-risk-and-back-up-everything warning right off the bat, which is good advice even when using an installer that’s considered stable.
In my case, no backup was necessary. There was no data on the drive that wasn’t already saved elsewhere and although the drive does contain a partition with the only Windows installation I have at my disposal, I only use Windows once a year at tax time and wouldn’t loose any sleep if it were to be accidently destroyed during partitioning. I might curse a bit, but I wouldn’t lose any sleep.
Installing Antergos is pretty much like installing any other distro, but with a couple of extra steps that aren’t common to all installations.
For example, there’s a step for the user to choose a desktop environment, which is required by some but by no means all distros. Six choices are offered, as well as “base,” which is a command line only system with no graphical environment. For this install I chose GNOME, a desktop I haven’t even looked at since 2002 when it was at version 2.0, choosing it here because it’s Antergos’ default.
Photo courtesy Antergos
As it turns out, it’s important with Antergos to choose the desktop you’re going to want to keep during installation and not try to swith to it later. Although it’s possible to change to another desktop after installation, the new desktop won’t be thoroughly integrated with the Antergos system. I understand that the distro’s developers are working on making this possible, but as of now a reinstallation is required for a completely successful desktop change.
After choosing a desktop, the user is taken to “Feature Selection,” which is basically a list of features that can be added during the install, selected with on/off switches, with “Printing Support” enabled by default. In addition, I enabled Arch User Repository Support, LibreOffice, Flash player, and Uncomplicated Firewall. Other options include support for Bluetooth, extra Truetype Fonts, Firefox, an LTS version of the kernel, Steam and PlayOnLinux for gamers, and Windows sharing.
Disk partitioning is pretty straight forward, but might prove to be something of a stumbling block for new users wishing to install the distro to dual boot with Windows. Surprisingly, the installer only offers two choices: “Erase disk and install Antergos” or “Choose exactly where Antergos should be installed,” a rather advanced option that wouldn’t be appropriate for most new Linux users. There’s no “install alongside” option at all as there is with most distros.
Cnchi’s “advanced” option does little to help guide a new user through the partitioning process compared with similar options on other installers. The user is presented with a list of all existing partitions on the disk and their file systems without identifying the operating systems. Not good for a user who wouldn’t know ntfs or ext4 from ReiserFS or ZFS.
Indeed, with no sliders or other drag and click aids, I felt lucky that I wasn’t needing to resize anything or create a partition where none existed. I merely needed to replace a huge Bodhi Linux partition with Antergos, while leaving a small Windows partition intact. This was done easily enough by leaving the two ntfs partitions alone, checking the ext4 partition and setting the mount point to “/” and then setting a partition already identified as “swap” as Antegos’s swap partition.
After that, there was a “this can’t be undone” warning screen to click through, then it was all over except for creating a user account, pulling the thumb drive and rebooting.
Running Antergos
At this point it would be easy to make a hard left and turn this into a review of GNOME 3. I didn’t care much for GNOME 2 when I tried it for a while way back when, and I certainly don’t care for what it’s become. As a friend, another tech writer, said in reply to a disparaging tweet I made about GNOME a few days back, “It strikes that perfect balance between too simple and too obscured,” which I think sums it up well. Suffice it to say, if I were to decide to make Antergos my distro of choice, I’d be choosing another desktop environment.
Package installation
Like a lot of modern distros, Antergos doesn’t install with a lot of software. All of the GNOME applets such as a calendar, calculator, and the like, are installed, but other than LibreOffice (which I’d ticked for inclusion during the system install) and the Chromium browser, no applications were installed by default — an approach I actually prefer.
Antergos uses Pacman, the package manager developed specifically for Arch Linux, with a large number of repositories included by default. In addition, advanced users can take advantage of the Arch Build System and the Arch User Repository.
I used the graphical installer to install GIMP, which I found easy to use and even simpler than Synaptic. Never having used Pacman before, I opened a terminal and had a look at its man page to find the proper syntax for using it from the command line, where I found that installing an application requires use of the -S (sync) operator to instruct Pacman to include all necessary dependencies.
To install the Bluefish text editor, I entered: sudo pacman -S bluefish .
Pacman dutifully offered some information on the package and dependencies, and prompted for permission to continue. After being returned to a command prompt, I opened the newly installed Bluefish to make sure the installation was successful, then used the command line to install FileZilla and Firefox. It’s probably not wise to make a judgement on four successful installs, but so far, Pacman looks as easy as apt.
Because of its Arch Linux roots, Antergos is “bleeding edge” insofar as it installs pretty much the latest and greatest version of programs. In this installation, for example, it installed the latest stable version of LibreOffice, 5.1.3.2. Likewise the latest stable version, 46.0.1, of Firefox was installed. Bluefish and FileZilla were also installed in their most recent stable releases.
Performance
When not under a heavy load, Antergos is quick and responsive. To see how the system handles when doing some heavy lifting, I opened LibreOffice Writer, GIMP with an open 150 KB image file, Chromium with five tabs open, one running a YouTube video, and Firefox, also with five taps open.
The system performed fine until Firefox was added to the mix, at which point the system became all but totally unresponsive and the laptop’s cooling fans went into hyperdrive. After about four or five tries, I was able to coax the graphical System Monitor that’s included by default in Antergos to open, which indicated the problem to be with CPU use, which was off the chart, as well as memory issues.
Trying to close a few programs to regain control of the system brought “program unresponsive, force close?” dialog boxes. The forced closes worked, and soon the fan speed returned to normal. We had returned to impulse power, so to speak.
I was a little surprised by this, as the old 32 bit desktop running Linux Mint that we use for the majority of our work at FOSS Force has a slower dual core 2.3 GHz processor and half the memory, yet handles similar loads routinely. At the same time, however, I was not surprised and I’m reluctant to lay fault at the feet of Antergos. I’ve seen similar performance issues in the past when running Firefox. Enough so that I no longer use the browser for anything but backup.
Was it live or was it Memorex? Who knows? But it was one or the other.
Recommending Antergos
Needless to say, Antergos isn’t for everybody, nor does it try to be. Although the distro does a good job of simplifying and making the Arch Linux base easy to use, the distro is designed with tech savvy users in mind. The distro would probably appeal most to experienced Linux users with good command line skills who’re looking for a highly configurable operating system with the latest software packages easily accessible.
Experienced user or not, I would be wary of using Antergos in a production situation, such as in an office setting for example, where stability and near 100 percent uptime is required. The fact that the repositories lean towards the most recent releases — certainly a desirable strength in many cases — might quickly turn into a big liability in uses where keeping the computer running and data protected is job one. If running in a production environment, I would strongly suggest installing new software on a test machine first just to make sure nothing breaks.
Although the distro is user friendly enough, most new Linux users have nothing to gain by having a go at Antergos before at least getting their feet wet on more consumer oriented distros, such as Linux Mint, any of the *buntus, Mageia or PCLinuxOS.
Christine Hall has been a journalist since 1971. In 2001, she began writing a weekly consumer computer column and started covering Linux and FOSS in 2002 after making the switch to GNU/Linux. Follow her on Twitter: @BrideOfLinux
@Christine,
On a tangent note, I use the TaxAct software for tax preparation. It’s browser-based solution, so arguably it’s one of the Software-as-a-Service-Substitute programs that the FSF (rightly) disapproves of. But it works fine on Firefox on Linux and it covers all of the tax features I need.
Thanks for the Antergos review.
I did a double-take. Wow. I’ve been using Antergos for over a year now but will only recommend it to ‘gear heads’. All others I send to Fedora.
I will say that rolling release is the ticket. Static package management should be abandoned in favor of it.
But, Fedora has one nice feature that should be incorporated into every Distro — the ability to transparently ‘snapshot’ the system prior to installing a package or upgrade (Btfrs) which makes rollback a cinch should things go wrong and they can and do go wrong when one least expects it.
I personally don’t trust Btrfs and believe it whacked the superblock of one of my drives a while back rendering it a paper weight.
So, my ThinkPad has sported an external docking BlacX eSATA 1TB WD HDD to which I send midnight backups (Backintime, rsync incremental). This piece of insurance is well worth the cost of investment and has saved me from certain ‘reinstall’ several times using Antergos.
Okay, yes ZFS is there in the install options but it is not ready for prime time. Thus, the internal 1TB SSD and external drives both use stable ext4.
A story on ‘static vs rolling release package management’ should go on your punch list. 😉
Thank you for the review.
I would use pure arch any day, we can easily install it using http://architectlinux.boardhost.com , cnchi installer crashes for me when I tried to install antergos, however architectlinux is very stable and you can install vanilla arch with it.
You should try Manjaro rather… It is to Arch what Ubuntu is to Debian.
If you only use Windows to do your taxes once a year, why not run it in a VM instead of keeping it on a dedicated partition?
Tons of install via cnchi and never ever crashed. if one reads the Arch boards before big updates, its as stable as any but yes, for production critical work, use Ubuntu LTS.
1 Arch is not a bleeding edge distribution – I might agree on cutting edge but it does not do bleeding . Arch testing would be more like bleeding.
2 We all know what pacman lives of right? Pacman eats apt for breakfast 😉
@blackpenguin,
How is pacman better than apt?
I support anyone’s right to use the software of their choice, so if you prefer pacman that’s fine. And from what I’ve seen it has more or less the same features as apt. But is it actually better?
I am using Antergos in productions systems: build servers with 24/7 uptime, workstations, mediacenters, backup machines, and even the notebook I am writing from.
The tech savvy guy should be in charge of upgrading, that’s the only rule.
@Mike S.
Where most see the limits of ‘static’ package management (apt being an example) is when ‘that special app’ doesn’t exist in deb format.
The user is then required to install build-essentials, then iteratively make, make install each dependency and then finally make the application.
This can be quite the ‘manual intensive’ process combined with troubleshooting make errors.
Unlike the above scenario, and generally speaking, pacman will, if needed download all dependencies and app source code, recursively perform a make for each tar.gz and then create a tar.gz which pacman will then automagically install with makepkg. This is with just ‘one click’.
I know of no other package manager that does that besides emerge for Gentoo.
You get up to date software all the time.
It’s a no brainer.
@Dietrich Schmitz,
You seem to be saying that Pacman will detect and download the dependencies automatically. How does it know what dependencies are missing, where to get the dependencies and what version to download, if the package is not already distributed in the pacman format?
I’m familiar with emerge, and in order for it to download and build everything you still need to tell it everything that is required.
I haven’t checked the Arch repositories, I think it’s possible that the Arch repositories are colossal and “that special app” already has an Arch package and no equivalent repository or ppa package for Ubuntu or Debian. But that doesn’t seem to be what you’re describing.
Agreeing with Mike S. on the fact that pacman can’t do magic…the package must exist somewhere first.
> “The user is then required to install build-essentials, then iteratively make, make install each dependency and then finally make the application.”
That is absolutely the WRONG way to build an application for a DEB based machine, i.e. Debian and derivatives).
You should never be running ‘make install’, but rather using the existing tooling to create a deb file the package management system can track. Using a raw make install is a great way to hose your system.
I don’t use Arch (and haven’t investigated its derivatives) because it’s too difficult to tell what is FOSS and what is proprietary due to the Arch dev’s not giving a rat’s a$$ about the difference.
@Mike S
Pacman keeps a database of what packages are installed, it checks against that database when installing/updating a package, if a dependency isn’t installed it adds it to the install queue.
@Mike, you’re completely uninformed, the Arch devs DO care about what is FOSS, anything not FOSS goes in the AUR, otherwise it goes in the repositories (core, community, multilib, etc)
@Phillip M Stephens
Respectfully – Bullshit
You can easily find proprietary software in the multilib and community repos (here’s a hint – look for skype).
Combine that with the fact there is no way to filter software on your system by license like Gentoo or separate it into distinct repos like Debian and it becomes difficult to know if your machine is really FOSS or not.
Top that off with the fact that comments have been made in the past by at least some Arch devs that they do not care about the distinction (I’ll leave it to you to find them) and you have the situation exactly as I described it.
Hell, here’s a quote directly from the Arch wiki: “The large number of packages and build scripts in the various Arch Linux repositories offer free and open source software for those who prefer it, as well as proprietary software packages for those who embrace functionality over ideology.”
The users who care about the distinction between FOSS and proprietary are definitely looked down upon in the Arch world. Their attitude has been clear for years.
No thanks.
Some of you are too funny with your FOSS reverence.
OK, now, let’s discuss should it be Linux or Gnu/Linux?
(kidding)
Try not to get too carried away. (wink)
@Dietrich Schmitz
> “Some of you are too funny with your FOSS reverence.”
More insults…nice. So anyone who has the intelligence to realize security, privacy, and anonymity can ONLY be achieved through FOSS is a religious zealot with extreme “FOSS reverence”?
With the state of security in (or lack thereof) in computing today, only two people run proprietary software: the uninformed (who are excused), and idiots. Which are you?
@Mike,
No matter how much rage or disappointment we might feel for people who still use proprietary software despite knowing better, diplomatic communication is the *only* path forward. I disagree with Dietrich’s position as much as you do, but I guarantee your post won’t move so much as one person from proprietary software to FOSS.
@Phillip M Stevens,
Dietrich Schmitz claimed that Pacman could automatically install the dependencies for a software package *that wasn’t packaged for Pacman*. At least, that’s my read of his initial claim that it’s superior to apt-get/deb. He seemed to be saying that any old .tar.gz with source code can automatically be installed on Arch without any extra work by the user. That’s incorrect – Pacman can only track dependencies for software that has the appropriate Pacman format metadata attached, just like every single other Linux packaging system. Gentoo’s emerge packager only stores package metadata and the fetch URL for the package source, but it still needs the metadata.
@Mike S.
> “I guarantee your post won’t move so much as one person from proprietary software to FOSS.”
I am not interested in converting other people to FOSS. Unlike (apparently) a lot of people I don’t see Linux as some engaging in kind of popularity contest with other OSes where we need to root for “our team”. That’s childish bullshit akin to rooting for a sports team. The facts are what they are: Proprietary software is a real danger – to privacy, security, anonymity, and self-determination with regard to computing. Either people see it or they don’t. I won’t waste my time with a distro that doesn’t see that as it tells me they don’t really know what they are doing.
With regard to pacman, it’s obvious Dietrich Schmitz is confusing the compilation of source based packages (vs. binary packages) with the compilation of raw source. He doesn’t realize someone still had to put that package together and put it in the repository with dependency information for it to work. Of course he’s giving out bad advice for compilation of raw source on apt-based systems too.
To have him criticize anyone for their devotion to FOSS is comical when it’s clear he doesn’t know what he’s doing.
@Mike,
I absolutely am interested in the popularity contest. The freedom and privacy that FOSS provides is only relevant if lots of people use it. Right now the government can closely monitor literally 99% of the population that uses technology through the proprietary software everyone uses. Those of us with FOSS stand out and it’s cheap for them to assign assets to monitor us the outliers through other means.
If 10% or more of the population that uses technology is using FOSS, then it becomes prohibitively expensive to monitor us all through other means. Individually identified threats can be tracked, but as a whole we maintain the same privacy that our grandparents or great-grandparents took for granted in 1930. That’s what we need for freedom to be preserved, that’s why I’m proud to be a GNU/Linux (and FreeBSD, OpenBSD, ReactOS, anything FOSS) cheerleader.
@Mike wrote:
“To have him criticize anyone for their devotion to FOSS is comical when it’s clear he doesn’t know what he’s doing.”
Yeah, I don’t know what I am doing. hmmmft. I only use pacman. You don’t. LOL.
Seriously, you are too funny. Are you on some kind of crusade? Lighten up.
@Dietrich Schmitz
> “I only use pacman. You don’t.”
I know what I’m talking about. You don’t.
> “Seriously, you are too funny. Are you on some kind of crusade? Lighten up.”
Deflect and belittle to distract people from your mistakes instead of admitting them. Who are you, Donald Trump?
@Mike S.
Sure it’s good when more people use FOSS, but it’s one thing to show facts to people and it’s another thing entirely to try to persuade them.
As with anything, people have to decide for themselves. Proprietary software is like a drug and you can’t persuade a junkie to quit; they have to come to that realization alone.
I will gladly explain the importance of FOSS to people *if they ask*. I may even volunteer some information if I think the person hasn’t been exposed to the idea before. But I absolutely will not waste my time with someone who knowingly makes bad decisions.
@Mike,
The persuasion is a slow process and it doesn’t always work, but the alternative is losing. Again, if we can’t get a sizable chunk of the population on our side, the FOSS freedoms mean nothing.
I don’t hold it against people who stick with proprietary software. I got into FOSS around 2000, when Windows was crash-happy and slow, when there was no Facebook or Netflix and there were no iPhones. If I was younger, or the same age but not working in technology 16 years ago, I would probably take proprietary software for granted too.
On the other hand, persuasion isn’t always hard. Why can’t you watch your iTunes content on your Chromecast? Why can’t you take the kids’ shows on your DVR and play them for the kids in the back seat of your minivan? Why does your Android phone come with 20 applications you can’t remove even though you don’t want them? Why can’t I watch my Disney DVDs without being forced to watch two previews first with no way to fast-forward? Why does Facebook keep showing ads for things I searched for on Amazon? Why does this mobile app want access to my contact list, when it’s just a game? Why do you need a fancy gadget to get computer diagnostic codes and their meanings from the car?
At least all of that is a starting point for the discussion.
@Mike,
Your comments are ‘amusing’ at best.
I offered up ‘useful’ information to those readers who may take an interest in using Arch based Distros.
I label you as ‘uninformed’ until such time that you can spend 30 days or more using Arch ‘exclusively’.
Thank you again @Christine for posting this story.
Footnote to my previous comments:
Here is a link to a PKBUILD for pacman’s makepkg:
https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=retroshare-git
Study it, those of you who may want to pursue using Arch.
No other Distro, to my knowledge, functions in this manner.
The closest one can get to the Arch methodology would be to use Gentoo or one of its derivatives.
DTS
@Dietrich Schmitz
> “I offered up ‘useful’ information to those readers who may take an interest in using Arch based Distros.”
Your information is *wrong*. It isn’t a matter of debate or opinion. You are empirically wrong.
> “I label you as ‘uninformed’ until such time that you can spend 30 days or more using Arch ‘exclusively’.”
I’ve used Arch. I won’t use it again for the reasons already stated. I’ve used dozens of distros. I’ve built several of my own semi-private distros entirely from scratch. I label you as “uninformed” until such time as you realize you are spreading misinformation.
That you won’t even acknowledge the mistakes with your statements as pointed out by Mike S. speaks volumes about your character, or lack thereof.
That you refuse to acknowledge that doesn’t make you less wrong, it makes you stupid.
@Mike,
Now that you’ve established that I am wrong and stupid, I am reviewing your comments.
You wrote to another commentor:
“Respectfully – Bullshit
You can easily find proprietary software in the multilib and community repos (here’s a hint – look for skype).”
I can only assume your point was that Arch stores proprietary software in its repository. Yes?
Well, yes and no.
Yes there is a way more convenient way to install skype than any other Distro is willing to offer — here is the PKGBUILD for skype:
https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/skype
I remind the readers who are FOSS devotees, you probably have one or more proprietary drivers running in your alleged FOSS instance.
If you look at how the package build is designed and in this case how skype is scripted to install, very cleverly, the PKGBUILD wgets the precompiled Skype 32 bit version and then gets the 32 bit libraries, automagically.
This shows the flexibility of pacman package management.
This story isn’t about FOSS. It’s about a singular Distro and its relationship to its parent Arch Linux and the distinctions one can make about it.
So, please put your personalizations aside and give it more thought.
The point of my saying make, make install for the static package management world was to highlight the ‘necessity’ of going through the overt steps of recursively making the application binaries and dependencies ‘before’ creating a package (deb, rpm). Regardless of which package, the end-user is still faced with the prospect of doing a series of ‘manual’ steps of make to create their beloved application not found in the repo system of their chosen Distro.
This is a ‘manual’ process.
With Arch, it is NOT manual and the entire make process, if needed, is handled automatically for the end-user.
That is the primary distinction.
Please make a note of it. 🙂
Thank you for being you.
@Dietrich Schmitz,
I think you’re not making a fair comparison. An Arch developer had to put together that installation script and list of dependencies.
A Debian developer would put together a .deb package and its dependency list. It’s the exact same thing, just in .deb instead of PKGBUILD – so PKGBUILD is not superior.
@Mike S.
The point is, all of the necessary steps required to build the ultimate package for deb or rpm require
MANUAL INTERVENTION.
That does not hold true for Arch pacman.
pacman’s makepkg handles and automates the ‘entire’ iterative process that other Distros fail to do.
And that was my motivation for mentioning it in the first comment I made in this thread.
This is not an unfair comparison. It is a comparison which clearly distinguishes a primary virtue to using pacman over other package management formats.
Please make a note of it.
@Dietrich Schmitz,
We’re talking past each other. The exact Skype PKGBUILD script and retroshare-git PGKBUILD scripts you linked to had a *manually assembled* list of dependencies, compilation flags, sed commands, chown commands, chmod commands, and so forth.
makepkg does not download the Skype package and magically detect its dependencies, the accounts it needs, and so forth. An Arch developer had to type that information in by hand – which is no different from making a .deb file!
@Mike S.
Here’s a better example. Chromium for Debian or Ubuntu.
Can you install the most current up to date version of Chromium for Ubuntu from the repo?
The answer is NO.
Look at this PKGBUILD for Chromium:
https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/chromium
Line 27 pulls the binaries from google’s common data storage and then makepkg packages the files and installs it with one click.
To approximate the same, necessarily, there is no equivalent for getting the source and dynamically creating a package while the user waits after pressing ‘apply’ (install).
Of course, developers expensed time to create a script. Nothing happens out of thin air.
There you have it. No denying. We are not talking past each other.
And the packages that aren’t in the repo are then found in third party repos like launchpad.net, but, again they are voluntary and static builds which a dev built.
Arch builds the Chromium package dynamically in /tmp pulling binaries from google, updates its pacman db and the user (me) is happy.
Clear? I hope that helps.
@Dietrich Schmitz,
Let’s flog this horse carcass one more time. The Ubuntu or Debian developers will get around to packaging a newer version of Chromium browser, and then users will be able to install it the exact same they can for Arch. So there is still no important difference between pacman/PKGBUILD and apt-get/deb besides the fact that the Arch developers work more quickly. And for that particular example the latest stable Chromium release is 53. Debian and Ubuntu offer the latest bug fixes and security fixes on the 50.0 major release branch, and you linked to the latest bug fixes on the 51.0 major release branch, but even Arch is behind the latest release.
Arch users will often have never software, because Arch is a rolling distribution and Debian and Ubuntu are not. Debian unstable is arguably similar to a rolling release distribution, but even it does not move as quickly as Arch or Gentoo.
@Mike S.
You wrote:
>”The Ubuntu or Debian developers will get around to packaging a new version of Chromium browser, and then users will be able to install it the exact same they can for Arch. So there is still no important difference between pacman/PKGBUILD and apt-get/deb…”
Incorrect. It is not the same. Pacman makepkg gets a current copy from google of the binaries ‘on demand’ (when the user presses ‘apply’) and builds ‘dynamically’ (realtime) a package in /tmp and then installs, and updates the pacman db to register the new app.
It’s not difficult to understand. It’s different. It’s better. I get ‘today’ what I want and don’t have to wait until a dev does the build and package creation gets around to it.
With respect to the above Chromium PKGBUILD script, the ‘package’ DOES NOT EXIST until the user presses ‘apply’ and makepkg creates it dynamically.
Clear? This isn’t me beating a dead horse. This was the point in my opening comment.
As I said, ‘Mike’ is misinformed. You are on the path to enlightenment, I hope 🙂
Good Luck.
@Dietrich Schmitz
> “I can only assume your point was that Arch stores proprietary software in its repository. Yes?
Well, yes and no.”
There is no “yes and no” – It’s definitively yes; There are proprietary packages in Arch repositories.
I was in fact responding to Phillip M Stephens’s accusation I am “completely uninformed” in claiming Arch devs don’t care about FOSS/proprietary distinctions (they have said they do not). He claimed Arch does not mix FOSS and proprietary software within a repository. Clearly they do; He was proceeding from a mistaken assumption.
With regard to pacman – The “magic” you keep describing is very simply the difference between distros that offer source based package management and those that offer binary package management (what you keep calling “static”). Gentoo and Arch offer both, but there are other distros that offer this same magic: Gobo Linux, Source Mage, Lunar Linux, Funtoo, CRUX, etc.
This is ABSOLUTELY not the same thing as automatically figuring out dependencies and compiling any arbitrary application “automagically”. I could point to hundreds of applications on github for which there is no Arch magic script.
@Dietrich Schmitz,
I still don’t follow. The chromium package you link has a big list of dependencies and optional dependencies. The chromium tar.gz from the commondatastore URL did not provide that information to the Arch package file, an Arch developer did. So I’m still just seeing a difference in process, not outcome.
Arch process: developer builds package file, package file goes to Arch repositories, user PC downloads package file, pacman reads package file and downloads binaries from Google chromium website, and installs them.
Debian/Ubuntu/(Red Hat/Fedora/OpenSuse too) process: developer downloads binaries from Google chromium website, makes package .deb file (or in Red Hat/Fedora/OpenSuse case, .rpm file), package file goes to Debian/Ubuntu(Red Hat/Fedora/OpenSuse) repositories, user PC downloads package file that already contains Chromium brinary, and installs it.
The amount of work and the amount of bits downloaded are the same either way, the only significant Arch advantage is that the Arch repositories only need to hold the package files and not the software binaries themselves.
@Mike S.
If you want to continue the conversation with this ninny, it might be of assistance to know he doesn’t think of the “magic script” as a package, not realizing that it effectively *is* the package and where the individual files come from is irrelevant.
*facepalm*
@Mike S.
What part of ‘dynamic’ package creation in /tmp do you not understand?
@Mike
You would do well with understanding the difference between a script and package.
https://wiki.archlinux.org/index.php/PKGBUILD
PKGBUILD is a shell script. It is read and used by makepkg to create pacman packages.
And, in the Chromium example, it creates a package dynamically at the point the user presses ‘apply’ to install Chromium. Up to that point the package does not exist on the Arch repo nor in the local pacman cache.
Again, pacman handles all build issues as specified in PKGBUILD, which is downloaded, executed by makepkg which then calls pacman (pacman -U package) to install the just created package.
This cannot be done by static rpm or deb.
Please make a note of it.
@Dietrich Schmitz,
Mike (the other Mike)’s point stands – the PGKBUILD shell script *IS* the Pacman package. It’s the Arch equivalent to a .deb or .rpm file and requires the same amount of work to create. They are functionally equivalent, they yield the same results.
Debian developers make .deb files to install packages.
Red Hat developers make .rpm files to install packages.
Arch developers make PKGBUILD shell scripts to install packages.
The chromium binary isn’t on your Arch machine until the PKGBUILD script is executed, but you still need someone to make the PKGBUILD script first. It is not more efficient than .deb or .rpm, it’s the exact same amount of work.
> “You would do well with understanding the difference between a script and package.”
ROTFL, Dietrich still doesn’t get it.
From the Arch wiki:
“A PKGBUILD is a shell script containing the build information required by Arch Linux packages.”
The metadata is in the script and the files are hosted on someone else’s dime. That’s ABSOLUTELY NO DIFFERENT than hosting the metadata and files in a single tar file and calling it a package.
I can write a shell script on Debian to do THE EXACT SAME THING but produce a deb package.
Dietrich should probably stick to a topic he understands. Package management isn’t one of them.
Going back to my opening comment:
http://fossforce.com/2016/05/kicking-tires-arch-antergos/#comment-18149
I wrote:
“Unlike the above scenario, and generally speaking, pacman will, if needed download all dependencies and app source code, recursively perform a make for each tar.gz and then create a tar.gz which pacman will then automagically install with makepkg. This is with just ‘one click’.”
I stand by that statement. Chromium was the example.
Here’s a script where it will do the needed get into /tmp of github tar.gz source code, configure, make, ‘on the fly’, dynamically, with no manual intervention by the user and then call makepkg to create a pkg.tar.gz, then call pacman -U to install the package.
Not all packages are built statically on Arch mirrors.
But they are ‘rolling release’ newest versions if found on a mirror from upstream providers.
So, please carefully reread the text of my comment above. It says:
“if needed”
The two of you need to work on reading comprehension.
I take care with how I choose my words and so should you.
I hope that helps.
Ok that should do it. 🙂
re my comment:
http://fossforce.com/2016/05/kicking-tires-arch-antergos/#comment-18188
A PKGBUILD Script with dynamic build from github codebase example:
https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=retroshare-git
Go ahead and try it for yourself.
apt and rpm cannot do this dynamic compile, installation.
The End.
Wow, Dietrich is…thick.
He quotes his original comment, but not the relevant part:
> “Where most see the limits of ‘static’ package management (apt being an example) is when ‘that special app’ doesn’t exist in deb format.”
He then proceeds to compare it to an example where a pkgbuild script EXISTS and pacman automatically goes about all the stuff a user would “have” to manually do with deb, conveniently ignoring the fact that all that work was done to produce the pkgbuild script. If a crazy Debian dev wanted to encourage the random downloading of unvetted binaries, they could do the exact same thing with deb files. Fortunately Debian developers have more sense.
To compare apples to apples, you’d have to compare “no deb file” to “no pkgbuild script”. Still easier? Didn’t think so.
> “Go ahead and try it for yourself.
apt and rpm cannot do this dynamic compile, installation.”
Actually they absolutely can. You said it yourself, it’s just a shell script being interpreted.
You could easily make a deb that executed code to pull down some arbitrary code and compile/install it. But chasing shiny new bits isn’t what Debian is about, so saner minds prevail.
Not to mention the security implications – Is that download being vetted? Better hope the arch dev used the ENTIRELY OPTIONAL signing and hash checking on every file, and didn’t just SKIP it as allowed in the pkgbuild settings. Again Debian shows greater sense here, requiring every package to be digitally signed.
Do either of you work in a developer capacity?
The source code of a given github account is keyring protected.
Some project managers opt not to sign daily pull requests.
That is quite common.
They vet the code of the PR before acceptance (merge), so, there is no risk whatsoever.
Here’s the same application as of a feature freeze commit:
https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=retroshare
Note it does include checksums for the finished production version of RetroShare.
Typically alpha,beta,rc revisions append to the package name “-git” to signify they pull github daily builds.
But that is besides the point.
I’ve shown how pacman package management exceeds the capabilities of deb and rpm.
Hope that helps.
LOL, and he’s still wrong.
> “Do either of you work in a developer capacity?”
Yes.
> “The source code of a given github account is keyring protected.”
Irrelevant. A pkgbuild can pull from anywhere, even over unencrypted http/ftp. The hash checking is optional in the pkgbuild and it would seem digital signatures aren’t used often. (no they are not the same thing, or even close to equivalent in security).
> “I’ve shown how pacman package management exceeds the capabilities of deb and rpm.”
No, you only think you have. But you are still very wrong.
@Mike
Try to install the current daily build of Chromium in a deb or rpm Distro.
You can’t. See if you can summon up some bile to explain that.
Arch pacman can.
@Dietrich Schmitz
> “Try to install the current daily build of Chromium in a deb or rpm Distro. You can’t.”
Hehe, of course I can. How do you think deb and rpm packages get made exactly, black magic? I could even make a script to download, build, and install the package automatically, just like pacman. It WOULDN’T BE ANY DIFFERENT than the Arch devs writing pkgbuild scripts for pacman. The fact that Debian and other distros don’t has nothing to do with technical ability and more to do with distro philosophy. It’s a shame you don’t understand that.
@Mike,
I should have listened to you earlier. This discussion has been a waste of our time for a while now.
@Mike,
Their isn’t a daily build deb for Chromium.
Provide the details of how.
@Dietrich Schmitz
> “Their(sic) isn’t a daily build deb for Chromium.”
So? There’s nothing stopping you (well, most people anyway) from making one. Certainly no technical issue.
> “Provide the details of how.”
*sigh* I already know this is wasted on you, but maybe someone else will get some useful info from it:
Start here:
https://wiki.debian.org/DontBreakDebian#How_to_avoid_problems
There’s tons of good info there on how not to wreck a Debian or other deb-based system by doing stupid stuff like running *ahem* “make install” scripts on your machine. If only more Debian/Ubuntu users would read that the world would be a better, happier place.
Specifically read up on checkinstall. It will take a compiled application for which no deb exists and produce a deb that accomplishes everything make install would have, but in harmony with the packaging system.
Reading the debian package “packaging-tutorial” will also reap rewards.
If you don’t want a package limited to today’s files, but one which will always build using the the latest, then just create a package around a shell script (gee, this sounds just like pkgbuild. I wonder why.) to gather the various dependencies and build them into a final deb package (This is trivial shell scripting). Anyone can then install the script package which will automatically trigger the download/build/install of the latest Chromium. Not sure why anyone would want to do that since Chromium (and Chrome) suck eggs, but there you go, exactly like pacman. This really is NO DIFFERENT than the work put in by Arch devs to create a pkgbuild script for an application. Like I said, and at the risk of repeating myself into the wind, There is no real mechanical difference here, only philosophy differences between the distros. When it comes to Arch, that’s not a philosophy I can live with because it puts its users at risk.
@Mike
So, such doesn’t exist in Debian. And one must create a script to do so. Why hasn’t Debian done this? Huh?
Arch already has it. Pacman is better than deb, rpm for this reason. Told ya.
Please make a note of it.
@Mike,
I’m no fan of Google, but I wouldn’t say Chromium and Chrome suck eggs.
@Dietriich Schmitz
You obviously didn’t read the link I posted. Package managers for deb and rpm can do the exact same thing. For pacman to do what you say, an Arch dev MUST CREATE THE SAME BLOODY SCRIPT, YOU MORON.
As I’ve said several times now, it doesn’t exist in Debian for PHILOSOPHICAL reasons.
Here’s an excerpt from the link I posted that explains it. I hope it is in simple enough terms for such as you to understand, but I doubt it. Instead you’ll likely just move your goalposts once again like you do every time you paint yourself into a corner with your ignorant drivel. From the Debian wiki:
Don’t suffer from Shiny New Stuff Syndrome
The reason that Debian Stable is so reliable is because software is extensively tested and bug-fixed before being included. This means that the most recent version of software is often not available in the Stable repositories. But it doesn’t mean that the software is too old to be useful!
Before attempting to install the newest version of some software from somewhere other than the Debian Stable repositories, here are some things to keep in mind:
Debian backports security fixes and new features, judging software by comparing the version number of the Debian package to the upstream version number does not take this into account.
The latest version of the software you’re trying to use might also have new bugs.
Installing software from places other than official Debian repositories might not get security updates.
Sometimes newer versions are available from http://backports.debian.org/.
Those wishing to assume more risk and responsibility can sometimes make their own backports of the latest Debian software. While not without risk, self-backporting is usually safer than other approaches. When self-backporting fails it is likely that any other approach will break your system. Instructions are available through one of the Debian IRC bots (as are instructions for self-backporting the very latest from the software’s authors). The judd IRC bot provides the checkbackport command to provide some guidance as to whether backporting is possible. You may wish to consult on IRC or elsewhere to investigate the risks and rewards of self-backporting.
@Dietriich Schmitz,
I’m starting to think Mike and I are being trolled here. Creating the script to make the .deb is no different from making the PKGBUILD script. Same work. Same task.
@Mike S.
Chrome sucks because it’s proprietary and full of spyware. It won’t allow users any real privacy or security.
Chromium: I lost all respect for it when it was caught last year in Debian downloading and installing a closed source binary blob to listen via the microphone. No user action was required and no notification or option to prevent it was given.
Don’t trust Google.
@Mike S.
> “I’m starting to think Mike and I are being trolled here.”
He’s not smart enough to be a troll. The only reason I even bother to reply is that some other people might find the info useful.
@Mike,
No, not trolling. You set up your own trap and fell into it.
Debian has no script to do what pacman’s Arch Build System does.
The Chromium install example I gave is a perfect example of what rpm, deb package managers have heretofore never shown themselves capable of doing, despite your assurance that it ‘can’ be done.
And if it was ‘easy’ to do, why hasn’t it been done? No answer necessary.
Have a good day.
@Dietrich Schmitz
It can easily be done. The work is no harder or more complicated than creating the pkgbuild script for Arch.
I explained why it hasn’t been done: They don’t WANT to do it. Neither do most of the users who run those distros as they prefer working systems over shiny new crap for its own sake. You said it yourself: “things go wrong and they can and do go wrong when one least expects it” Things don’t “just go wrong” in Debian stable unless you ef it up yourself.
You just can’t admit when you are wrong. Keep moving those goalposts though. I pity anyone who take computing advice from you.
@Mike S.
Trying to explain things to Dietrich Schmitz is like explaining them to a parrot.
He only knows a dozen words and just repeats them in random order.
@The Mikes: I see Dietrich Schmitz hasn’t changed.
Oh look, it’s @Tracyanne from down under.
Kind Regards 🙂
Hi Mike
Dependencies are defined in the PKGBUILD along with their source URL’s
I hope this answers your question
Regards
Hello @Cirrus,
Thank you. Mike (who is a different person from me, Mike S.) had explained it.
Regards.
BTW for the record, my shiny new arch install is going on for 5 years old, thats the longest ive managed to run any distro without it breaking or more commonly, me breaking it.