Djbsort: A new software library for sorting arrays of integers • Hacker News Board

Re: Djbsort: A new software library for sorting arrays of integers

#111

Post by mcguire » Wed, Jul 11, 2018, 5:32 PM UTC

Panino wrote: post #97

nrclark wrote: post #41

My job involves a lot of packaging/cross-compilation, and djb's libraries always seem consistently hostile to the lowly packaging engineer. Would it really be all that much work to package in autotools or CMake? Why do I need his special-snowflake build system with its hard-coded assumptions about system paths? I know that the cult of djb will downvote this into oblivion, but seriously, what is the rationale for a bu…

I've been using DJB's stuff for ~20 years and I don't like his recent build systems either. Without defending it, I'd just like to offer a theory on why he packages things the way he does. Back in the day, his build processes were atypical but still much more "normal" than now. He also released his software without licenses. During this time of heavy software development, DJB was concerned about people screwing aroun…

"He's also been putting out a tremendous volume of work in multiple categories. I bet he'd rather work on this stuff than on user-friendly build systems."

I don't know about that part...a halfway normal build process would be considerably less work to set up than this monstrosity.

Re: Djbsort: A new software library for sorting arrays of integers

#112

Post by ur-whale » Wed, Jul 11, 2018, 5:39 PM UTC

throwanem wrote: post #104

ur-whale wrote: post #79

Earlier quoted context omitted.

I have tried working with autotools. Many times. I guess it's down to mindset: some people don't mind working on top of a pile of manure and don't really see what the big deal is. Others just cant.

> the autotools steaming monstrosity which in 20 years of using opensource software I've never dared to touch > I have tried working with autotools. Many times. Well - which is it?

:)

I guess "touched" is the wrong word. I did enough "touching" of it unfortunately: using it to compile packages, trying to fix it, wasting precious time wading through pages of horrible shell code to understand why it fails when it does.

I even tried a couple of time to use it in my own projects , naively thinking that it's so widespread there's got to be something to it I'm not seeing.

I gave up on it in disgust everytime. The list of reasons is long, but I guess if I have to pick the one thing that really drive me nuts: most packages out there compile way faster than it takes to configure them.

If that specific fact doesn't make you walk away from it immediately, our brains just aren't wired the same.

Re: Djbsort: A new software library for sorting arrays of integers

#113

Post by tbirdz » Wed, Jul 11, 2018, 5:40 PM UTC

nrclark wrote: post #41

My job involves a lot of packaging/cross-compilation, and djb's libraries always seem consistently hostile to the lowly packaging engineer. Would it really be all that much work to package in autotools or CMake? Why do I need his special-snowflake build system with its hard-coded assumptions about system paths? I know that the cult of djb will downvote this into oblivion, but seriously, what is the rationale for a bu…

I really disagree with you on autotools, that has been a big problem for me when cross-compiling. Configure often detects features by compiling a binary and executing it, which can be a problem when you're cross compiling, since the generated target can't be executed on your native cpu. Most software build systems don't even take cross building into account at all, since they just copied someone elses' broken autoconf and automake source that only works on native builds so you have to work around a lot of issues.

Even "good" software packages written by people who understand autotools like glib have issues. Just look at the official glib cross compiling instructions: https://developer.gnome.org/glib/stable/glib-cross-compiling... The "correct" way to cross compile it is to figure out all the autoconfigured values yourself, and write them into the configure cache.

Personally, I have had the least trouble with plain Makefile based packages. Yes you often have to reach into the Makefile's guts and modify it to make a working cross build, and you'll have to set the rpath manually, and install the files yourself, but at least it's easier than having to modify an autotools based build.

Autotools "just works", and when it doesn't it's very hard to fix. Makefiles don't "just work", but it's much easier to fix them yourself.

Re: Djbsort: A new software library for sorting arrays of integers

#114

Post by [deleted] » Wed, Jul 11, 2018, 5:43 PM UTC

nrclark wrote: post #41

My job involves a lot of packaging/cross-compilation, and djb's libraries always seem consistently hostile to the lowly packaging engineer. Would it really be all that much work to package in autotools or CMake? Why do I need his special-snowflake build system with its hard-coded assumptions about system paths? I know that the cult of djb will downvote this into oblivion, but seriously, what is the rationale for a bu…

[deleted]

Re: Djbsort: A new software library for sorting arrays of integers

#115

Post by Nokinside » Wed, Jul 11, 2018, 5:59 PM UTC

nrclark wrote: post #76

ur-whale wrote: post #68

Earlier quoted context omitted.

1. You're assuming the software is intended to be deployed 2. Writing anything sane with autotools or CMakes is an exercise in frustration that borders on torture. Not to mention how either of these systems chafes on one's sense of aesthetics. 3. I've installed a few of djb's package over the years. While indeed non standard, unlike either of the solutions you've mentioned, djb's stuff: a) works b) is usually very si…

Why would somebody release software that they didn't want to see used? To your other point, Autotools is little crusty for sure. It's Yet Another Language to learn (and so is CMake), but it's really not as bad as people make it out to be. There are many thousands of examples in the wild, good and bad. Yes, Autoconf tests for a bunch of stupid things that don't matter. But so what? You can add the tests you _do_ care…

Because he provides reference implementation and functionality, not a a ready multiplatform software package.

You can use it to make your own library and then publish it if you wish.

Re: Djbsort: A new software library for sorting arrays of integers

#116

Post by R0b0t1 » Wed, Jul 11, 2018, 6:11 PM UTC

tbirdz wrote: post #113

nrclark wrote: post #41

My job involves a lot of packaging/cross-compilation, and djb's libraries always seem consistently hostile to the lowly packaging engineer. Would it really be all that much work to package in autotools or CMake? Why do I need his special-snowflake build system with its hard-coded assumptions about system paths? I know that the cult of djb will downvote this into oblivion, but seriously, what is the rationale for a bu…

I really disagree with you on autotools, that has been a big problem for me when cross-compiling. Configure often detects features by compiling a binary and executing it, which can be a problem when you're cross compiling, since the generated target can't be executed on your native cpu. Most software build systems don't even take cross building into account at all, since they just copied someone elses' broken autocon…

To clarify for anyone who doubts autotools has problems - it is true that the documentation mentions cross compiling options, but it appears that the vast majority of tests in use today do not actually use these values (host/target arch, etc).

Some users recommend compiling with qemu-user to avoid fixing the tests, but besides being very slow, that methodology will still generate garbage. What is the point of running feature detection code on a desktop that will be used to configure code compiled to run on e.g. a small ARM system?

The fix is to explicitly set configuration parameters or, even better, to detect features at runtime. However if you try to contact any given project using autotools to help solve these configuration problems you will likely receive "that's not our problem" and no help from the maintainers.

Autotools is in practice less work for me than alternatives, at least while using a FOSS operating system. On Windows CMake is very well developed but handling dependencies is always a chore.

Re: Djbsort: A new software library for sorting arrays of integers

#117

Post by eesmith » Wed, Jul 11, 2018, 6:13 PM UTC

nrclark wrote: post #76

ur-whale wrote: post #68

Earlier quoted context omitted.

1. You're assuming the software is intended to be deployed 2. Writing anything sane with autotools or CMakes is an exercise in frustration that borders on torture. Not to mention how either of these systems chafes on one's sense of aesthetics. 3. I've installed a few of djb's package over the years. While indeed non standard, unlike either of the solutions you've mentioned, djb's stuff: a) works b) is usually very si…

Why would somebody release software that they didn't want to see used? To your other point, Autotools is little crusty for sure. It's Yet Another Language to learn (and so is CMake), but it's really not as bad as people make it out to be. There are many thousands of examples in the wild, good and bad. Yes, Autoconf tests for a bunch of stupid things that don't matter. But so what? You can add the tests you _do_ care…

Not everyone wants to see their software used. Some want to see the ideas in the code be used elsewhere. In that case the code is meant so others to study and understand.

You can see this in software papers where the algorithm is described by pseudocode, or only the core part of the algorithm is shown. Presumably the rest of the code is obvious to others in the field.

Releasing non-portable source is a step above that common practice.

I've used Autotools. I've contributed to Autotools. I agree that it's a steaming monstrosity. I never want to look at an m4 macro again.

Re: Djbsort: A new software library for sorting arrays of integers

#118

Post by wnoise » Wed, Jul 11, 2018, 6:28 PM UTC

nrclark wrote: post #89

dilap wrote: post #81

Earlier quoted context omitted.

I don't think most software needs to care about these weird exotic systems anymore (MINIX? seriously?). Maybe if that's really a goal of your software, it's reasonable to use autotools.

For what it's worth, I agree that Autoconf tests for a lot of things that aren't necessarily relevant today. I don't think I need to worry about the existence of on just about any platform. But there ARE a lot of very relevant tests mixed in there too. These include things like: - Width of an int - Endianness - Availability of arbitrary functions for linking - Search through a list of libraries until one is found tha…

> - Width of an int

If your software depends on this, you're doing it wrong. As you said, depending on the existence of is just fine, and you can then specify what you need. Even in the incredibly rare case of needing the width of int (serializing inputs and outputs of existing libraries interoperably on multiple machine ABIs) has you covered, albeit in an awkward way, unless you can assume POSIX and thus have WORD_BIT.

> - Endianness

If your software depends on this, you're doing it wrong. If the wire/file format is little endian, input[0] | input[1] > - Search through a list of libraries until one is found that provides a requested function, then add that library to LDFLAGS

This is the exact opposite of what I want! If I'm depending on other libraries, I want that dependency explicitly listed and settable, not automagically found.

> - Does the C compiler work?

How is this reasonable to test? If it doesn't work, it can't actually do anything about it.

> - Do compiled binaries run on the build machine?

Totally ignores cross compilation, or deploys to other places -- e.g. containers.

> And it gives you control over things like:

These are generally useful, but the complexity required for autoconf is a huge cost to pay.

> Automake gives you:

All useful, yes. But these have never seemed to be particularly hard to do manually.

Re: Djbsort: A new software library for sorting arrays of integers

#119

Post by wnoise » Wed, Jul 11, 2018, 6:32 PM UTC

jy3 wrote: post #32

banachtarski wrote: post #8

Earlier quoted context omitted.

Unrelated to the article I recently learned Go just as a side-interest. I was appalled by how terrible the language is. Usually, language warts aren't apparent until you use it a bit but here annoyances were present on day 1 and never went away.

It's kinda hilarious to see that as more and more successful projects and companies use Go in their stacks, the number of comments like these increases in HN.

Stack adoption makes people have to actually use them, which then gives them something to complain about (whereas before they could just ignore something not to their taste).

Re: Djbsort: A new software library for sorting arrays of integers

#120

Post by geocar » Wed, Jul 11, 2018, 6:33 PM UTC

kbenson wrote: post #87

geocar wrote: post #71

Earlier quoted context omitted.

> You example script with python2 is not about pathing, but a separate problem or multiple binaries with the same name, and is exactly why you want to let package managers deal with this. > for example what the default python will be Except that package maintainers created this problem. It's not a real problem! Python's source code downloaded packages call itself python3. Some package managers decided to call it "pyt…

> Except that package maintainers created this problem. It's not a real problem! It is a real problem. People wanted both python interpreters installed at the same time, and a way for software written for each of them to functionally coexist on a system. Package maintainers provided a solution. > Python's source code downloaded packages call itself python3. > Some package managers decided to call it "python" creating…

> Did they create the problem,

Yes.

> or did they mirror the reality they saw, where people that installed python3 symlinked python to python3?

Evidence please.

I can’t believe any user would do this because it instantly breaks all their scripts.

Every python 3 program I have thinks python 3 is #!/usr/bin/python3

> I think it's pretty obvious from this that the Python developers intended to completely replace python 2.x

Of course they did, but there’s a good reason there are no directions for installing Python on the python website tell users to do this: As naive and full of hope as the python developers are, they’ve got nothing on the sheer hubris of Linux python packagers who think they’re doing gods work by commenting out random seeds in OpenSSL.