Smart use of unicode block elements (2581-2588 if I'm not mistaken), nice trick with the background for that double graph.
Edit:
Is there a "block-width" space in unicode? Like it's nice if one can assume a monospace font, but it would be nice to draw unicode-art using these characters and a space with the same width:
Edit2:
Hey, HN deleted my characters, I meant 2591-2593 (25%, 50%, 75% shading) and 2588(full block). What is missing is the 0%.
I tried out them, they don't seem to work with the fonts I tried. I skimmed the unicode standard for "block characters" and I didn't read any constrain for the block characters on width.
This project looks great, but I find the comparison point "How easy to install?" to be very misleading. It says that prettyping is easier to install than the alternatives, but all mentioned alternatives are all readily available as packages for your distro.
Also, I prefer installing via the package manager because of the integrity check. To do the same with the "curl" approach, I have to donwload the code, import the developer's GPG key, download the signature and run GPG ... Oh wait, there is no signature file for Prettyping. Not even the Git tag "v1.0.0" is signed. So I have to download from multiple sources, or email the author and ask for the expected hash value.
This process is much easier if prettyping was included in the distros. So the other tools are actually better off with regard to "How easy to install?"
I wish the project site would be more honest in that regard, or at least add another comparison point "How easy to install _safely_?"
I'm the author. Sorry about the lack of signature, I'm not well versed in GPG.
Also, I suppose the man-in-the-middle issue is mitigated by downloading directly from GitHub over https. Unless there is something else I'm missing (very likely, feel free to enlighten me).
Sure, I'd love to have it packaged on several distributions (I know Arch Linux already has it; and also brew on Mac OS X), but I can't do it myself. I hope users from other distros find it useful and contribute packages to their distros.
Still, I wrote that comparison with good faith and based on my own experience. For instance, I once wanted to run it on a university computer that only gave me normal user access. I couldn't install anything outside my home directory, and I couldn't rely on package management.
"How easy to install?" could be renamed to "How easy to install from scratch?", because everything is essentially trivial to install using a package manager.
> Also, I suppose the man-in-the-middle issue is mitigated by downloading directly from GitHub over https. Unless there is something else I'm missing (very likely, feel free to enlighten me).
There is no substitute for end-to-end encryption, from you, the author, to me, the user. The only generally accepted relaxation is end-to-encryption from the maintainer (e.g. Debian maintainer) to the user - which is what you have in the distros.
Compared to those best practices, the "HTTPS from GitHub" has the following flaws:
1) You have to trust GitHub. If GitHub is hacked, or starts to behave like SourceForge, you are doomed and nobody will notice.
2) Unless all of your users do certificate-pinning, a compromised CA (or a malicious CA) may be used to issue an alternative SSL certificate for GitHub, which is then used to deliver malware.
It may seem implausible that anyone would go that long way to attack your prettyping project directly. However, it is very attractive to attack GitHub as a whole and to manipulate all hosted programs systematically.
> Sure, I'd love to have it packaged on several distributions (...), but I can't do it myself. I hope users from other distros find it useful and contribute packages to their distros.
Maybe it helps to ask them. I know that Debian has a mailing list for that. Sure, you still need to find volunteers if you can't do the packaging on your own. But maybe there are people willing to do that, who just need a little more motivation.
As listed in the comparison, a similar tool would be noping, which is packaged in many distributions already (Debian/Ubuntu: oping, ArchLinux/MacPorts/Homebrew: liboping).
Hey, I'm the author of prettyping here! I'm a bit busy these days, but I'll take a look at the comments here and the pull requests at GitHub. In fact, prefer using pull requests and issues in GitHub.
The subject here is prettyping and not us, though. Try: "prettyping's color scheme is not compatible with my specific type of color blindness and I would like to suggest the author add additional color options". Sounds less egocentric IMO.
It took me a moment to realize the name derivation was pretty + ping. My eyes first grabbed onto "typing", then "pretty", and for an instant considered if it might be a portmanteau of those. I didn't catch on until actually reading the first sentence on the page.
Beautiful colored unicode output. But why on the Earth it's implemented in bash/awk? It's completely unmaintanable and unfrendly for contributors. Just look, how GitHub syntax colouring gives up on 46 line of prettyping script.
I mean, that it doesn't sound like a right tool for the job, and argumentation, that it can be just curl'ed and executed doesn't sound like a good one.
curl'ing binaries is not the way systems should be configured, while packages is. And if software is packaged, then it doesn't actually matter (from installation usability standpoint) will it use bash/awk or more convinient language for implementation (python, golang, whatever). But it will make huge difference for maintaining and further development of software.
PR submitted https://github.com/denilsonsa/prettyping/pull/3