311–320 of 545 posts
> and how stupid your argument is Didn't Linus recently go to sensitivity training or something? I think he missed out on the bigger picture. It seems like his argument is more about shaming anyone who disagrees with him, instead of expressing an opinion.
People may be offended if they identify their ideas too much, but that's insensitivity from their part.
Earlier quoted context omitted.
Undefined behavior is not a compiler specific guarantee. UB can change based on almost random factors, especially between newer releases of the same compiler. They are bugs, they were just masked.
This honestly depends on what undefined behavior we are talking about. Sometimes it will be guaranteed to behave a certain way on a compiler. A few will also be the same across compilers if your compiling for the same architecture. However, I do agree that cross compiling is good for finding bugs like this. And really if we are letting the compiler or architecture define undefined behavior, I find it better to break…
That is implementation defined, not undefined, behavior.
It's extremely hard to agree with Linus on that. One problem in his argument is that he believes that everybody has a kernel hacker mindset: most today's developers don't care about environment reproducibility at architecture level. The second problem is that he believes that every kind of development is as platform sensitive as kernel hacking, and he even makes the example of Perl scripts. The reality is that one ye…
Earlier quoted context omitted.
Node and Ruby applications do fail on ARM though, when it comes to native libraries and extensions. And now your whole distro is different than your development machine, which adds complexity. Do I really want to be debugging why node-gyp fails to compile scrypt on the ARM distro on the new Amazon A1 ARM instance (which it did in my case)? And if I solve that, what about the other 2451 dependencies? Let's pessimistic…
On a related note, if Apple does switch to ARM chips for their laptops, that will make mainstream ARM server-side development more viable than any cross-platform story ever can. Or kill the Mac desktop. One or the other :)
The onlything i would run locally would be the frontend, and it is web/mobile anyway.
Earlier quoted context omitted.
The NetBSD people vehemently disagree. By ensuring your software works on various architectures, you expose subtle bugs in the ones you actually care about. Lots of 32-bit x86 code was improved during the migration to 64-bit, not because the move created new bugs, as because existing ones (i.e. code that relied on undefined behavior) couldn't get away with it anymore.
Well nobody uses NetBSD so... Sure portability increases code quality, but at what cost to time to market which seems to be the primary concern for most developers these days?
Earlier quoted context omitted.
> I think I'll side with Linus on this one. I saw first-hand how non-existent the x86 Android market was, despite Intel pouring megabucks into the project. Doesn't that refute Linus' argument, not strengthen it? Almost all Android developers develop on x86. Intel thought, as Linus apparently does, that this would drive adoption of x86 on phones. It didn't. Intel even got competitive in power efficiency and it wasn't…
Phones are different than servers though. The primary customer of a phone is Joe Somebody who doesn't know or care about architectures, only battery life and cost. Well ARM wins there. The primary customer of servers is developers who care less about cost and more about time to market.
For servers, developers are often the customers of their own software.
I disagree with Linus here, in large part because modern system architectures are so distributed. There are so many parts of modern deployments which are not developed in-house anymore. Databases, organizational productivity software, monitoring systems... the list goes on. So let's say the developers of PostgreSQL or Prometheus or JIRA or Mattermost or any one of numerous others were to come to their audience and sa…
Earlier quoted context omitted.
I don't think you are not really disagreeing with Linus - he's not saying ARM is not viable - he is saying it will not win . With your current setup (cross-compiling), are your ARM executables more performant than x86? Or do they have any other advantage at all over x86? Without an advantage, ARM can't possibly win. Having a cheap, viable ARM-native development platform drastically increases the chances of ARM-only k…
He's not saying it won't win, either. He's just saying that for it to win, it needs a viable dev platform. Which, if you reverse cause and effect is blatantly obvious. If ARM comes anywhere close to viable enough to be "winning", there will be a good market for dev platforms, and somebody will step in and fill the need. Heck, some are even arguing here that the Pine64 already meets that need.
Earlier quoted context omitted.
Node and Ruby applications do fail on ARM though, when it comes to native libraries and extensions. And now your whole distro is different than your development machine, which adds complexity. Do I really want to be debugging why node-gyp fails to compile scrypt on the ARM distro on the new Amazon A1 ARM instance (which it did in my case)? And if I solve that, what about the other 2451 dependencies? Let's pessimistic…
> now your whole distro is different than your development machine Can you not develop on an ARM emulator? Or just buy an ARM machine for dev work?