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

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

#151

Post by gowld » Thu, Jul 12, 2018, 5:36 AM UTC

ur-whale wrote: post #79

nrclark wrote: post #76

Earlier quoted context omitted.

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…

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.

Some people like to get things done. Some people like to sit on the sidelines and complain.

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

#152

Post by viraptor » Thu, Jul 12, 2018, 6:12 AM UTC

gowld wrote: post #149

viraptor wrote: post #37

Earlier quoted context omitted.

Authenticity, sure. Humility - not after his approach to the students issue in recent years where he was more interested in being correct then helping people :-(

What is " the students issue "?

I don't want to add more bias from my side, so I'll just point you at https://twitter.com/hashbreaker/status/845057003642933248 https://twitter.com/hashbreaker/status/845072847705919488 as starting points. You can google a few articles, discussions via the names involved.

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

#153

Post by geocar » Thu, Jul 12, 2018, 7:39 AM UTC

kbenson wrote: post #141

geocar wrote: post #120

Earlier quoted context omitted.

> 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…

> I can’t believe any user would do this because it instantly breaks all their scripts. You mean those scripts which they are expected to upgrade to Python 3 using the 2to3 program, which installs with python? The same scripts that Python 3 advocates claim can be fairly easily converted? > Evidence please The fact that Python 3 has a documented option to install as /usr/bin/python and it mentions it on every regular…

> But did they initially? That's the question.

Yes.

> > Evidence please

> The fact that Python 3 has a documented option to install as /usr/bin/python and it mentions it on every regular install is evidence.

No it's not.

Finding a debian mailing list where someone is complaining about incorporating a python3 script "package" that assumes python is /usr/bin/python would be a start. Finding many people complaining would be evidence.

> I remember having lots of problems trying to get Python 2 installed on systems that shipped with Python 1.

Problems created by package maintainers "shipping" python in the first place.

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

#154

Post by masklinn » Thu, Jul 12, 2018, 12:13 PM UTC

johannes1234321 wrote: post #143

masklinn wrote: post #133

Earlier quoted context omitted.

> In that case, the material was still under copyright in Germany. Which is exactly the case of djb's work here. > In this case, the material has been placed in the PD by the original author and so no one in the world can possibly have any legal claim on it. Wrong. djb and any possible heir of his does, because you can't place things in the public domain in mainland europe. > But if this really concerns you, I would…

> Wrong. djb and any possible heir of his does, because you can't place things in the public domain in mainland europe. However a court could interpret this as a royalty-free license, at least until the moment they start sueing.

That is true, but there currently is no precedent for that. Until someone becomes the "sacrificial lamb" by 1. taking the risk and 2. being sued for it, anyone intending to build a business is understandably wary and unlikely to touch public-domain-dedicated assets.

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

#155

Post by [deleted] » Thu, Jul 12, 2018, 12:44 PM UTC

tinus_hn wrote: post #110

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.

Minix happens to be one of the most used operating systems because it turns out Intels Management Engine, the secret computer inside your processor, runs Minix.

[deleted]

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

#156

Post by geocar » Thu, Jul 12, 2018, 1:39 PM UTC

nrclark wrote: post #98

geocar wrote: post #84

Earlier quoted context omitted.

> Why wouldn't I want to use the chip's CPU to the fullest extent at runtime? Because you'd rather use GNU autoconf? If you wanted the fastest possible performance, you'd try each algorithm, profile them, then select the one that works best. This build process can do that automatically. GNU autoconf cannot. You can tell autoconf which to use, but the package maintainer can't be trusted to do this. Then the user will…

You could absolutely write an Autoconf script that runs those tests by default, but has overrideable behavior. You can make custom Autoconf macros to detect whatever arbitrary thing you want. At the core, an Autoconf macro is just a chunk of shell script that sets some environment variables with the result.

Surely you must appreciate this is more work than not doing it.

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

#157

Post by dilap » Thu, Jul 12, 2018, 2:56 PM UTC

tinus_hn wrote: post #110

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.

Minix happens to be one of the most used operating systems because it turns out Intels Management Engine, the secret computer inside your processor, runs Minix.

that's interesting! still, probably not a lot of software targetting it, though. :-)

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

#158

Post by tbirdz » Thu, Jul 12, 2018, 3:00 PM UTC

altfredd wrote: post #147

tbirdz wrote: post #113

Earlier quoted context omitted.

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…

"Configure often detects features by compiling a binary and executing it" — I am not sure, where this impression comes from. Autotools as whole have excellent cross-compilation support. Autoconf has feature-detection routines, checking for presence of headers, exported symbols and pkg-config files. None of those trigger "execute the binary" part when cross-compiling. In addition, custom-written host-side checks can e…

The impression comes from having to deal with multiple configure sciripts that do that very thing.

The capabilities may be there, but in my experience many if not most projects do not use those capabilities. Most autotools based projects I've had to cross build are made by people without a great understanding of autotools internals and capabilities, so they often end up copy pasting things blindly from other projects until they get their native build working. Advanced build system stuff like cross building is not even considered.

These builds end up trying to execute a binary to do feature tests, or compile a program and use that to generate code, or do any number of things that break when cross building.

Would things be worse without autotools? Maybe so. In my personal experience projects using a simple Makefile were much easier to cross build and package than ones using autotools, but that's probably confounded by projects using a Makefile being simpler overall.