> > tl;dr version: Using other building processes simply hides the > shortcomings from the very people who are most likely to be able to fix > it. No packages for arm may be frustrating for users, but it also > reminds the developers (who are also users) they have work to do, and > the work needs to be done. > > long version: > Looks like there's a basic misunderstanding of computers on this list -- > that some computers are like some people, and are "weak" (or in my case, > overweight asthmatics) and that if made to do lots of work, will not be > able to take it and fall over dead, while others are more "fit" and can > do anything forever and ever. With the exception of really crappy > hardware that shouldn't be used, this is not true. Hardware should Just > Work. You should be able to beat the snot out of it for weeks or months > at a time...really, from OS update to OS update. I have no reason to > believe the ARMv7 hw currently available isn't like this. Yes, it's > cute. Yes, it's "cheap". Yes, it's small. That doesn't mean it is > frail (and if it is...it shouldn't be used). > > You have slow hardware and fast hardware. You have efficient hardware > and inefficient hw. But if you have non-broken hardware on which an OS > or application crashes, you have a software problem. Granted, > sometimes, there's buggy hw (for example, UltraSPARC-III, aac(4), almost > all modern processors) that requires SW work-arounds, but you can't just > wave your hands and pretend you have a great OS for a product when you > can't deal with the realities of that product. > > The problems with ARM systems are not (for the most part) issues of > insufficient RAM (hey, 512M is still a lot of RAM for an OS like > OpenBSD, though granted, not for many modern apps) or the processor > getting "tired" and crashes from fatigue. The problem is that when you > work the memory management (among other things) hard, the OS, as > currently implemented, fails. > > "Well, then, don't work the memory management hard!" is not a solution, > as again, this stuff is supposed to just work. A problem found when > working a system "hard" /will/ be seen, though less often, at other > times, too. > > Every once in a while, a problem is found and fixed on one platform that > impacts all platforms...just not often enough to have been spotted or > fixed before. Some platforms are better at exposing OS flaws than others. > > Nick. > > thanks for answering. it's just those virtualized guys they emphasized on how slow the building on arm is and how faster it could be with that qemu on their monstrous amd64 servers. they seemed suppose this was the problem. but then, if speed is a problem, a cross-compilation on their monstrous amd64 servers will be even more faster, actually all be compared to virtualized something. but since the main problem as you have outlined here is not about speeds or capacity of targeted machines, all the arguments previously given are out of scope of the problem.
ps. if i could i submitted patches to improve openbsd's code for armv7, but, having some knowledge in armv7 and continuing learning, i know few about openbsd's internals. so sorry, for wasting your time in this respect. -- B16B00B5
