I remember optimizing a huge build that took days. We optimised it to only hours on a cluster - it took years to get this right. We realised at the end of this that the packaging system (handled by another team) was taking about 2x longer than the build because there was one particularly huge zipfile that sat there compressing for ever and ever and ever while the rest of the cluster was idle.
As in this story we blew enormous effort optimizing something that was very difficult and because of our blinkers (and our management's blinkers) we missed that it was only able to achieve a limited result. We didn't look at the whole system. In the end it was never fixed because......siloed thinking...or something.
...and now with AI much more of that dreadful software can be built with all the bullshit featuritis that said managers who don't use it think they want.
Last release on Oct 14. Beta support for 3.12. It's not that bad really and 1/10 of the people who complain about it did something then the situation would be better.
Perhaps if the money which was spent on the built-in JIT had been spent on PyPy we'd be somewhere.
PyPy wasn't great for me because its startup time interfered with the main usecase I wanted it for in one instance and in another there bugs that made it not quite compatible enough. Money could solve the bug issue.
On the other hand I did get pygame working with it at one point and that seemed like a nice scenario.
PyPy's problem with slow startup is, in principle, easily fixable.
When it was created, PyPy did not seek to optimise startup performance. Instead, its aim was steady-state performance of JITed code, and it succeeded handsomely. A conceptually simple fix would be to optimise traces in one processor core, while the interpreter runs in another. Once when the trace is finalised, does interpretation stop and switch to native execution. But PyPy is currently a sequential system and making it parallel, while conceptually easy, is a lot of work and needs a rewrite of the whole system. But, for better or worse, the PyPy team does not have the resources to do this.
The other of PyPy's big performance issues (Python code using a lot of FFI calls via a suboptimal FFI) is also, in principle, easily fixable. But this is a social problem: the Python community would have to move towards better FFIs.
In principle, it would also be easy to fix PyPy's resource problem. I am not sure about the social problem ...
> What would have been really nice is if the $1M/y in funding the PSF rejected due to ideological purity could have been reallocated to PyPy.
It would certainly have been nice if the Trump administration had not retroactively obliged the NSF to add ideological constraints to its funding parameters which conflicted with the PSF's mission, so that money that had already been allocated by the NSF to the PSF could not be granted.
I'm not sure what the process is by which you purport that the money could have been redirected to PyPy, but I assure you that it exists only in your imagination.
I found this recently - couldn't compile it on HPUX. Trying to get rust on there would have been an absolute impossibility of course. I can get bash though, and lots of other GNU utilities - all written in C of course. Thank goodness some people care!
People who don't care about HPUX will never care about it but they would if e.g. we decided that only windows and Ubuntu were supported ... except for the windows and ubuntu python users who wouldn't care.
It's I'm-all-right Jack until it's your use case that gets bulleted.
Hi, one of the co-maintainers of GNU coreutils here. It is nice to hear things worked on HP-UX. I don't have access to it, and I don't think the other maintainers do either. See this commit [1].
[1] https://github.com/coreutils/gnulib/commit/c599eba7bed3baa30...
Yes we're using quite an old version 8.13 and yet it does the job for our build which maintains an EXTREMELY important bit of software in public service relating to healthcare.
It's on Itanium so obviously we have to move away from that to Linux but the existence of open source tools like coreutils gives us time.
No such luck with python. We have to postpone some changes as a result.
As I say, there's some kind of effect where changes that are only negative on the margins are cheered until one finds oneself on one of those margins.
Glad you could get an older version works well for you. We probably would have tried to continue supporting it if we had access to it. I'm a bit sad I never got the chance to use it once.
However, the other maintainers, who have been doing it for many more years than I have, and various other authors are certainly more deserving than I am. I am similarly thankful to them.
I think there’s a categorical difference between HP-UX (which seems to no longer even be maintained by HP) and something like Linux on the top 5-6 most popular architectures.
(But with all that said: there’s no ideological dispute here. If there was a reliable way to build and test for HP-UX, I assume a lot more people would declare support for it. The problem comes down to maintainers being asked to support platforms they ultimately have no ability to support, except in the weakest sense of “it compiles.”)
When you think about GNU autotools they're all about being able to compile on platforms that the software has never been compiled on before - that's why there are all those feature tests to see what the OS and compiler support.
I've done this many times on things like AIX 4.3 and HP-UX and so on. Sometimes you can get through the compile without any problems at all and the tool often works enough for your usecase and that's a win.
Sometimes there are particular little problems, sometimes it's something serious like an actual missing C library call or whatever and then you have to do some work. With nicely designed tools that have fairly wide support to begin with this tends to be easier.
Yes, optionally apparently but I think we'll end up with forks of Python if the Rust enthusiasts push it any further. I think the option will be off for me.
I presume that those who don't want to have to build rust just to get python will stick the rust code into an LLM and get out an acceptable analog in C.
The point of converting things is here already - existing code is like a very precise prompt. I've used it for Perl-Python mainly and the results are far better than trying to write new code.
> they do request nicely, but they also present the drawbacks for them as if they are absolute, and even claim that "its benefits don’t outweigh the drawbacks".
for some people the benefits absolutely do outweigh the drawbacks. Maybe not for you....but on the whole I don't know - if the whole issue had been solved without being given attention would you have ended up caring which way it went?
Sure, but again, you could in theory distribute said builds and stop wasting compute compiling yourself. I know nixpkgs, for example, builds with very generic targets and not super aggressive compiler flags, but at least the machinery exists to do this.
> Sure, but again, you could in theory distribute said builds and stop wasting compute compiling yourself.
Here are three links that you will find informative. [0][1][2]
While I'm not using the official Gentoo binhost, I've had one running on my LAN for my own personal use for roughly a decade now. It has been possible to set up a binhost for quite a bit longer than that... that's just when I got multiple machines with the same CPU in them, so it made sense for me to set one up.
Was ccache support much older than binhosts? It has been so very long since the introduction of both that my memory of the history has been thoroughly erased.
On my 10 computers for example? :-) Gentoo wasn't aimed at people with such luxuries.
I'm not a Gentoo user BTW but I do think building from source is attractive for the same reasons cargo (Isn't that build from source mostly?) and go do it.
The vast majority of desktop Linux users run Ubuntu (initial motto: Linux for human beings). So one may argue the literal opposite of what you wrote, in that if Canonical didn't invest into making a Linux distro that's accessible to normal people, it wouldn't have the relevance it now does. On top of that, Linux has (or had) a number of clear advantages over Windows that dwarf the presumed upsides of compiling everything from source vs. downloading builds.
There's not much of an argument for adopting obscure niche practices for their own sake
The rather large giant collosal planet sized argument that you somehow missed despite that, is that every single thing that you consider good and normal today doesn't exist except for the fact that at one point it was the obscure niche thing that annoyed intolerant "normal" people.
You, like the other commenter, disregarded the core argument of the matter in favor of contrarianness for its own sake: are you trying to argue that building literally everything from source is cool and good because it's niche and weird, whereas Linux was niche and weird once but it's cool and good now? As I said, Linux had and still has clear advantages over Windows to the point that Microsoft felt threatened by it fairly soon (cue Ballmer's chair throwing, cancer remark, etc.) and tried to undermine it before giving up with Nadella. What, exactly, are the obvious and objective upsides of compiling everything from source? Many posters in the thread dispelled performance-maxxing as a meme so it can't be that. You are comparing apples to oranges here.
I feel like I'm trying to explain a shade of colour to a blind person.
building from source has uses which you believe are worthless and other people don't think are worthless.
Anyone who uses cargo or installs a module for golang is building from source. But that, probably, is considered useful. It's only people who build C code from source who are niche and wierd. ....
Linux was obscure and niche for a very long time before Ubuntu existed and Ubuntu only existed because someone bothered to use and develop Linux when it wasn't normal.
The Ubuntu users are only there because after they had told the rest of us how silly we were for using Linux they eventually had to use it themselves for work.
Now we're going to listen to that sort of stuff again without rolling our eyes? ....
SLS for me. haha. :-) But now at least you have the choice! It's great really. I can use Artix because I like being nearer the bleeding edge but even that is really a lot easier to use than Linux was in the days when I had to compile my kernel.
Nevertheless I remember lots of my friends who started off saying Linux was hopeless and ended up using it and Ubuntu was their gateway. The Linux world now is full of people who are fairly conformist and don't care about how it all began and who don't value the idea that open source has margins from which who knows what world beating things might eventually come. The fact that margins can exist is what makes open source great.
As in this story we blew enormous effort optimizing something that was very difficult and because of our blinkers (and our management's blinkers) we missed that it was only able to achieve a limited result. We didn't look at the whole system. In the end it was never fixed because......siloed thinking...or something.
reply