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.
