Please support the ARM developers in getting the base OS stable, then we can worry about getting the packages and ports working.
It would be advantageous to have a stable OS before you can begin debugging issues with packages and ports. > On May 25, 2015, at 9:01 AM, Nick Holland <n...@holland-consulting.net> wrote: > >> On 05/24/15 00:00, valerij cotinskij wrote: >> 2015-05-24 3:46 GMT+03:00, Tobias Ulmer <tobi...@tmux.org>: >>> Of all OpenBSD lists, arm@ has the highest ratio of unproductive >>> whining. >>> >>> >> >> and then, in addition to all this thing, some stranger is showing up >> and adds his stupid question written in bad english: >> personally i hate hardware virtualization and hope that it will be >> thrown into hell, and for me it is clearly understandable why guys who >> write the OS dislike hv. but my question is, if it is so important for >> the project to do stress tests of the hw making on them the 'native' >> builds but this hw can not deal with such a task, for some complicated >> reasons, why just not to make the cross-compilation for this >> architecture? is not this a much better solution than to have nothing, >> not to saying about weirdness of using hv? the primary task of >> building is ... building not stress testing. so much people want see >> something another than linux on armv7, whether a cross-compilation is >> that unfeasible? i'm just asking, because this is the first thing to >> think about when you see how people are pushing that crappy hardware >> virtualization. > > 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. >
