>>>>> "Luke" == Luke Kenneth Casson Leighton <l...@lkcl.net> writes:
>> I even agree with you that we cannot address these challenges and >> get to a point where we have confidence a large fraction of our >> software will cross-build successfully. Luke> sigh. I don't really see the need for a sigh. I think we can address enough of the challenges that we are not significantly harmed. >> But we don't need to address a large fraction of the source >> packages. There are a relatively small fraction of the source >> packages that require more than 2G of RAM to build. Luke> ... at the moment. with there being a lack of awareness of Luke> the consequences of the general thinking, "i have a 64 bit Luke> system, everyone else must have a 64 bit system, 32-bit must Luke> be on its last legs, therefore i don't need to pay attention Luke> to it at all", unless there is a wider (world-wide) general Luke> awareness campaign, that number is only going to go up, isn't Luke> it? I'd rather say that over time, we'll get better at dealing with cross building more things and 32-bit systems will become less common. Eventually, yes, we'll get to a point where 32-bit systems are infrequent enough and the runtime software needs have increased enough that 32-bit general-purpose systems don't make sense. They will still be needed for embedded usage. There are Debian derivatives that already deal better with building subsets of the archive for embedded uses. Eventually, Debian itself will need to either give up on 32-bit entirely or deal with more of that itself. I think my concern about your approach is that you're trying to change how the entire world thinks. You're trying to convince everyone to be conservative in how much (virtual) memory they use. Except I think that a lot of people actually only do need to care about 64-bit environments with reasonable memory. I think that will increase over time. I think that approaches that focus the cost of constrained environments onto places where we need constrained environments are actually better. There are cases where it's actually easier to write code assuming you have lots of virtual memory. Human time is one of our most precious resources. It's reasonable for people to value their own time. Even when people are aware of the tradeoffs, they may genuinely decide that being able to write code faster and that is conceptually simpler is the right choice for them. And having a flat address space is often conceptually simpler than having what amounts to multiple types/levels of addressing. In this sense, having an on-disk record store/database and indexing that and having a library to access it is just a complex addressing mechanism. We see this trade off all over the place as memory mapped databases compete with more complex relational databases which compete with nosql databases which compete with sharded cloud databases that are spread across thousands of nodes. There are trade offs involving complexity of code, time to write code, latency, overall throughput, consistency, etc. How much effort we go to support 32-bit architectures as our datasets (and building is just another dataset) grow is just the same trade offs in miniture. And choosing to write code quickly is often the best answer. It gets us code after all. --Sam