Well, the front page did recently have people complaining about a bunch of paid products (github, twitter, everything IBM does). I'd expect us to treat open source projects like any other, and part of that is by noting their failings. Incentivising fixing those (or doing the fixing) does happen in different ways, but this isn't a development forum :)
I'd say:
> don't post anything publicly if you want only [warm fuzzy feelings]"
There is 'total compensation' to consider, though. If you're getting paid big money to work on something, you can probably swallow the criticism fairly easily. But if you're not being paid any money, and there are zero warm fuzzy feelings, it's harder to stay motivated.
I wish the package-query maintainers would stop hard coding the pacman version in their PKGBUILD as requirements. It means that every time there's a minor release of pacman, updating breaks for the 6 hours it takes the AUR guys to catch up.
yaourt & co. are very useful when you have to build packages with tons of dependencies. I had to build the 32-bit gstreamer stuff from AUR for some Wine work recently, and it saved me tons of time. Just remember to set --noconfirm or it'll ask you to confirm a dozen things for every package :)
A bunch of AUR packages, like Yaourt itself, download their sources over HTTP and verify them with MD5, so even if you trust the AUR maintainer you have no idea if you're getting the same file they did.
It's sad that makepkg still uses MD5 by default in this day and age because "it's faster".
I assure you Yaourt doesn't have an .asc signature either.
They should be using SHA-256, or Blake 2 if they think the extra seconds spent verifying matter, but insisting on using MD5 is pretty much going out of your way to increase your attack surface. There is no reason to use it in a modern system.
> I assure you Yaourt doesn't have an .asc signature either.
That's yaourt's problem, not makepkg's or the AUR's.
> They should be using SHA-256, or Blake 2 if they think the extra seconds spent verifying matter, but insisting on using MD5 is pretty much going out of your way to increase your attack surface.
It doesn't matter what algorithm you use, file hashes are not a security feature. Use GPG!
The widespread use of MD5 in AUR is because that is the default in makepkg, making it both AUR's and makepkg's "problem".
> It doesn't matter what algorithm you use
Of course it matters, they have different guarantees. A secure hash would at least guarantee that the file you get is the same one the packager got, MD5 doesn't. They are refusing to use strictly better alternatives out of pure stubbornness.
Personally though, I've never had an issue with the performance of `pacman`. Even without parallel downloads I've found `pacman` generally outperforms most other package management tools I've used.
I don't think it would be. Parallel downloads would simply mean that more of the client's bandwidth is consumed by connecting to multiple mirrors at once. Each individual mirror will, at most, still supply the same total bytes and bandwidth (though it's likely that being able to download form multiple mirrors at once would end up lowering an individual mirror's overall load by more effectively spreading downloaders between different mirrors)
XferCommands are confusing to write. I have one, and it makes my downloads faster, though I wouldn't have a clue how to write it myself. Here's what I have currently:
It's fast, but doesn't have download progress. I had another one, which printed several lines of output per file (but did have progress!).
My point is, the fact that you can make pacman download stuff quickly as-is, doesn't mean that inbuilt support wouldn't be beneficial for everyone who doesn't know how their downloading program works back-to-front.
iirc, apt has support for it (it will only download a single thing at a time from a given host, but does appear to download different things from different hosts at the same time).
I believe gentoo's emerge also has support (though I'm not as sure here as I typically have the downloads happen in the background while building).
The overall goal here is to more effectively utilize the available bandwidth on the client side even when there are limitations a given server.
It's great that we can customize how to download 1 package at a time. But there is room for improvement.
Am I the only one that read the title and thought this was Pacman the game? I am surprised they let you use the name for something else considering it's supposed to be highly copyright-protected.
Sidenote: I am having trouble finding the link to an explanation what this really is. any help?
It's open source software so it can (given enough time and motivation) be ported to whatever platform you wanted. Because of this I think there's a few other OSs / distro forks that also use pacman. But primarily, `pacman` is developed by ArchLinux maintainers for ArchLinux.
It's great, it has a wonderful collection of libs, sometimes it can feel a little bit too cutting edge, but after the stagnation of Mingw I'm not complaining about that.
Not that confusing really - the two applications couldn't be more different in use.
"Pacman" is abbreviated from "package manager" while "Pac-Man" is derived from "Puck Man", named so because the yellow avatar looked like a hockey puck. (the reason for the name change is quite interesting too[1]).
While it's true that the ArchLinux devs do play on the name similarities (there's even an easter egg to turn the `pacman` progress bar into a little Pac-Man eating up ASCII pills[2]), I think most people who might confuse the two wouldn't be familiar with the package manager anyway. And those who are familiar with `pacman` are likely technical enough to tell the difference.
[1] Renamed because of worries that some US audiences might vandalise the Puck into Fuck.
[2] Put 'ILoveCandy' (without quotes) under the [options] in /etc/pacman.conf
Names aren't copyrighted, they're trademarked. And since:
a) Arch Linux isn't selling pacman.
b) I don't believe Namco still own a registered trademark for Pacman. And they probably don't make enough money from it for them to win a lawsuit about it (trademarks require a reasonable commercial interest in order to be protected).
So there almost certainly isn't a legal issue. IANAL.
Namco is very involved with Pacman and still involved with arcade equipment based on it. Here's something my friends at Raw Thrills just introduced a little while ago:
From what I've heard on the inside, Raw Thrills has been actively working on new Pacman games based on the original 1980 source code given to them by Namco.
TLDR: They definitely still own the trademark and they are still making money on it.
Bandai/Namco certainly do hold multiple registered trademarks on PAC-MAN, at least in Europe. They cover not just the video game side[1], but everything from kitchen appliances[2] to lotteries[3] and even beer[4].
Namco still own the trademark, they do ill-advised attempts to revive the franchise every few years. Arch Linux best defense here is that it's not in the same business, so there's no risk of confusion (trademarks aren't all-encompassing).
>Do not start an open source project if you need praise, warmth and love from your fellow human beings. [ https://news.ycombinator.com/item?id=11053810 ]
>Folks forget that most FOSS work is volunteer & berating the hackers who make it won't help one bit. [ https://news.ycombinator.com/item?id=11054809 ]