But if there is nothing to develop for... Chicken and egg problem.
However, I think that Windows on ARM will soon become a real thing, this could bring the developers, it will also help the ARM devices spread among Linux users.
Regarding what Linus wrote, I do not buy it. There is so much stuff can run without cross-compilation: js and other scripts, java, c#. Also look at things like Android and iOS, you are already happily developing for ARM, you can develop for servers with the same approach.
I do buy Linus' argument, you need to be able to do native development.
My ARM64 development machine is a Pinebook, ARM32 a Cubietruck. Both have only 2GB of RAM and could really do with more. At least the Cubietruck has SATA so mine has a SSD.
> However, I think that Windows on ARM will soon become a real thing, this could bring the developers, it will also help the ARM devices spread among Linux users.
Windows an ARM has been a real thing for years, and it is horrible. Nobody in his right mind would use this for development.
Windows ARM (Windows RT) has been a mess, but Microsoft is committing more resources to make proper Windows + ARM it a real thing. Will it work? I don't know, but they are trying, probably because of Apple & AWS moves toward ARM.
Windows 10 on ARM has come a long way in recent builds. The SKUs have many fewer differences from x86/x64 Windows 10.
On top of that, x86 emulation on it is now stable, including full Win32 emulation, and reports are coming in of even doing things like running Steam and old PC games on ARM devices.
No. It's unlikely that they'd be able to anyway - products (like, say, a Macbook Pro or ThinkPad) get targeted at developers. RISC-V is an instruction architecture, which gets used by a chip designer, which gets sold to a computer manufacturer, who does the actual marketing to end users, so they're about 4 links removed up the value chain.
What they should do is make RISC-V useful for computing at the edge - applying computation to areas where it's previously been infeasible (eg. smartwatches, wearables, RFID, drones, vehicles, etc). Developers go where the end users are. If a new end-user market opens up that suddenly needs a lot of software, developers will buy the same ISA that their customers are using. And then there will be strong pressure to run the other software that developers write (eg. servers, as Linus notes) on the same ISA to prevent cross-development.
Yes, very much so.
Having a C++, GO, Java, RUST, Python and F# IDEs running on Risc-V.
Allowing to debug, experiment, without relying on centralized hosting providers -- would be a huge boon to Risc-V.
Early adaptors will be developers, than their family/friends circle. Then there will be Risc-V-First movement (mirroring mobile-first movement), and there it will start...
> So RISC-V CPU designers should aim for the developer market then? First win the hearts and minds of developers, then everything else will come.
I am so not looking forward to Apple leaving the x86 space behind. I really do not want to wait years for software to catch up nor leave behind the options I have today for "an improved user experience" which is just walling the desktop off too.
It literally won't matter, as Linus explained. As the infrastructure will be x86. This is what he's saying. Unless a new paradigm emerges on drastically different tech, ARM has too far to go to catch up to create an isomorphic environment where the code is created. A few tenths of a percent of mac developers won't make a jot of difference.
Not sure that's what he was saying. I understood that instead of targeting the server-market directly first, he recommends that it would be better to target the developer market first. And if it's popular there, it will naturally bubble up from there into the server market.
Sure it will take more than a few tenth of a percent of mac developers but it won't need total domination like x86 either. But just imagine if Apple really just switches its MacBook (not even the Air or Pro ones) to ARM64 that would already be millions of users. A lot of devs will at least try to compile their app for that platform for the first time. Quite some developers will be curious and get one just to test their software on it. I am pretty sure this is going to help the adoption of ARM64 way more than a slightly improved CPU or another experimental support by a cloud provider.
Personally I don't care too much about ARM64's success (although more competition would certainly be great), I am more rooting for RISC-V and I hope they follow a more developer-first strategy.
I wonder whether Apple’s arm PCs will go more the way of chrome books and ms surface laptops. Although since people that buy these are looking for significant value, it’s hard to think Apple will be successful.
And if Apple switches pro line to arm, they’ll probably lose all non iOS/macOS developers. So, good luck to them then there.
> Some people think that "the cloud" means that the instruction set doesn't matter. Develop at home, deploy in the cloud. That's bullshit. If you develop on x86, then you're going to want to deploy on x86, because you'll be able to run what you test "at home" (and by "at home" I don't mean literally in your home, but in your work environment).
But developers can ssh to the cloud, and develop there, right?
And he's wrong. In the enterprise, the vast majority of devs are on Windows, for Java for example. That doesn't mean that their deployment target is Windows, most of the time it's Linux. And the development differences, chance of bugs, performance profiles are way different between OSes than they are between CPU architectures.
I can install a reasonably performing x86 Linux VM on an x86 Windows host. If the same can be said for an ARM VM on an x86 host, please share how, I'd love to learn that trick.
> Most of those enterprise devs don't even get to touch the test/staging/prod environment, yet they still do their jobs.
They can usually run at least some part of the stack locally. Maybe not the full thing, at least part of it.
> Regarding the VM, today I guess it would be a bit ugly through Qemu but tooling is always solved if there's a need.
Tooling doesn't magically fix perf. Have you actually tried that specific setup? Searching online I get results like https://raspberrypi.stackexchange.com/a/12144 which aren't impressive, and I don't count as "reasonably performing".
Those results also jive with my experience - the meager demands of mobile apps are outrageously slow inside an ARM emulator running on x86 every time I've tried it, although I'll admit I haven't tried it on Qemu specifically. I can only imagine the horror of trying to run a full ARM server stack on x86 via emulator - perf is bad enough when it's native. For mobile, the first thing I do is fix the x86 builds (so I can use an x86 device emulator), buy a real ARM device out of my own pocket, and/or educate and/or fire my employer for their outrageously wasteful use of my time if they're serious about me and my coworkers using mobile ARM emulators on x86 for any serious length of time (that kind of waste of expensive resources like developer time can't possibly be a sustainable business decision.)
> That doesn't mean that their deployment target is Windows, most of the time it's Linux.
I don't feel like that's true. I don't have data to say otherwise, but my impression for the majority of non-tech businesses I encounter is that they are very much still Windows shops, and still on-prem.
I've worked for a few, consulted for others, have friends working for yet others. It's a mix. Java shops go Win/Lin, .NET generally is Win/Win, for now.
He isn't wrong since most linux servers run on x86 architecture and obviously most windows desktops run on x86 architecture.
To your last point, if that is true, then what will the differences be when both the OS and CPU architectures are different? I suspect it will create even more headaches.
I don't see ARM winning the server space anytime soon or ever considering how established and dominant x86 is.
You're comparing a bytecode virtual machine to a processor microarchitecture. He's talking about why a particular hardware platform becomes dominant. You could say the same thing about any interpreted language, not just Java. How about python or javascript? Java didn't displace x86.
Not without an internet connection, not in an isolated testing environment, not without jumping through cloud specific hoops to setup accounts, not without installing your initial ssh keys, not without getting IT signoff for access and/or to spin up more cloud resources with the related charges, not without extra IDE configuration (if even possible, depending on the cloud) or resorting to raw gdb, ...
When I want to test C++ stuff on ARM, I connect an android device, because that's somehow less painful.
> But developers can ssh to the cloud, and develop there, right?
Then why do they insist on 32GB i9 laptops running MacOS or Linux? One must assume that there is some practical purpose, unless one is rather cynical and believes that maybe the just like shinnies.
There is nothing stopping you from developing on x86 and SSHing to a remote ARM computer for final validation. Cross compilation has been a thing for decades.
On the level of Linux it might be hard, but thousands of iOS developers do it all of the time. On the application level if you are just doing C, my experience with writing cross platform C, if it works on one platform and breaks on the other, there is probably a bug in your software that is only surfacing on one platform usually around depending on undefined behavior or relying implementation defined behavior.
But my “experience” with native cross platform programming is two decades old - x86 and whatever the old DEC VAX and Stratus VOS platforms were running.
.. develop remotely? I can, if I wish. I have an extremely high bandwidth link to servers. But there's still latency, and that makes all the difference. So in practice I always develop locally. I use Git and VNC and sshfs-mounted filesystems to access the remote, but my tools and editors are always local. I can build remotely, but not work remotely. And I still like to build locally all the same, during the actual development.
I find it hilarious that this is the developer attitude for their own work, but then they turn around and expect users to just suck it up and accept latency because cloud!
It's a difference in using a text editor remotely, compared to doing just about anything else remotely. I can log in and build remotely, and execute remotely, use remote git servers, even run GUIs remotely (testing my application through a VNC). But using a text editor remotely, with a few hundred millisecs rtt.. now, that is very different.
I disagree with Linus for a couple of reasons. The main one being that not every service in a product needs to be running ARM for it to be useful. There is nothing preventing heterogenous solutions in the cloud and if third parties vet their code on ARM then deploying your DBMS on ARM and your web server on x86 (or whatever services most of your business logic is in) is totally valid for cost or performance reasons.
Secondly, it seems likely that there will be ARM MacBooks by 2020, that kind of instant market penetration for arm in the dev space might mean the exact opposite of what he's saying; why would I deploy on x86 when all of my development is on my ARM machine already?
Apple hasn’t touched the Unix parts of MacOS in a long time. I’d assume whatever they ship will be some sort of hybrid that may not make developers happy.
Your second point is just re-enforcing what he said. If MacBooks move ARM, they will have solved developer piece. Since so many developers use Apple stuff, ARM will be native and servers would follow.
In the 90s you could see a shift from people having a SPARC workstation in their office for service development, to just using a x86 PC with Linux or Windows on. Then after while developing for Linux/x86 and deploying to Solaris/SPARC made little sense, so you just put it on Linux/x86 in the end. The thing is maybe 95% of things just work and you spend all your time sorting the other 5%.
At least for now, the ‘move to ARM’ is just wishful thinking by developers who think they can shovel phone apps onto the desktop. Unfortunately phone apps on the desktop stink so that’s not going to be a big thing.
Moving to ARM has nothing to do with moving phone apps to desktops.
Almost all iOS apps already run natively on x86 today. When developers use the iPhone simulator they are running natively compiled apps linked against an x86 version of the iOS framework. If all Apple wanted to do is allow iOS apps to run without any usability changes on Macs that would be easy (and ugly).
> Secondly, it seems likely that there will be ARM MacBooks by 2020, that kind of instant market penetration for arm in the dev space might mean the exact opposite of what he's saying; why would I deploy on x86 when all of my development is on my ARM machine already?
Well, that is not the exact opposite of what he's saying! He actually mentioned that. That is merely one of his points and it is true.
Linux said: "Without a development platform, ARM in the server space is never going to make it."
It would genius of Apple to simply own this phenomenon.
Want an iPod/iPhone like phenomenal opportunity?
Go all in on ARM chips and ship out MacBooks with next gen performance. Alongside, develop server grade ARM chips and make it easy for the army of devs weilding the shiny Macs to deploy straight to it.
Impress with performance - you get to take the cake and eat it too.
I doubt an operation guy like Tim Cook will understand such a strategy.
That's probably the strongest counter-argument. New generations will learn programming on Arm and RISC-V (whether it's something like an iPad or a Raspberry Pi).
Linus very much sounds like a grumpy old man saying "get off of my lawn!" (as he usually does).
Well, it's difficult to not get grumpy when you hear the same promises for many years. It's not like "ARM for servers" is something new. The exact same things were already promised over a decade ago, and somehow, it never really came to pass. And I think his reasons are spot on: aside from very specific workloads, it just did not make sense to buy ARM-based servers. They were usually not much cheaper, and they usually did not save much power, compared to x86-based machines. Combine that with cross-development, and you have a loser.
Exactly. Modern X86-64 chips got improved power saving, more cores to increase density at reduced power cost, much more powerful GPU for running compute.
Plus, server space buyers are conservative, they want support of a big company behind their hardware. Someone the size of Cisco, Dell or HP. Or hardware that is used by Google or Microsoft.
Combine that with anticompetitive long term agreements and you get the picture.
Somehow network routers have a variety of architectures inside and nobody has a problem - because they have a bunch of reputable companies behind each of them. (Variants of MIPS, ARM, ARM64 and x86 are in the wild.)
Yeah, but it seems unlikely that many of them are learning in languages or environments where the arch really makes any difference. If the dominant OS on RPi was RiscOS (a man can dream...) it might be a different story.
And where does it? Almost nothing I write will get compiled down to native code. Linus is forgetting the immense volume of code that's written in Java, PHP, Python, C#, Ruby and dozens of other languages that rely on runtime interpreters.
I agree I will not even think of optimizing my code to run on POWER, SPARC, or ARM and that I won't care where my software runs enough to create a market for these, but I don't care enough to keep an x86 market either.
Having said that, it would be good for those who propose new architectures to ensure there is a ready supply of entry level machines for enthusiasts and early adopters. Seeding these groups will ensure their architectures and software is more thoroughly used and tested.
Are they really? RPi is cool and all, but I doubt the market share of ARM development is that big. As I was kid I got interested in programming because I wanted to develop games, and I would guess that still most yungsters want. For that RPi is shitty choice.
It is pretty big for smartphones and tablets. And embedded devices.
Games on smartphones are perfectly viable - RPi is not good enough but oDroid or Google Pixel is.
The only problem is developing on same machine as you use. For that, you need a full fledged, quite powerful ARM laptop. Hacked Chromebook for example.
Otherwise, the emulator is way too slow.
Are all these kids learning C or assembly? Because if they are learning Javascript, Python, etc. it doesn't matter in which processor their code is running.
Exactly. That's what I don't get about this whole architecture argument. If I write a mess of Python and deploy on a local ARM SBC or drop it into a remote x86 webserver, what's the difference?
He is right. I'm still waiting for that ARM-based laptop with awesome battery life, which can run a proper OS with good speed and hence is not just a toy. Apple switching to ARM won't make much difference since I gather it will only run OSX, which will probably be pretty much iOS at that time. Yes, you will probably be able to run Linux on that thing, but almost nobody will actually do it because it makes much more sense to buy a cheaper x86-based machine instead. Yes, there are ARM-based laptops running Windows, and they are a joke. For instance, c't just tested the Lenovo Yoga C630 WOS, and it's a disaster, plain and simple.
You'll probably be able to run Windows 10 on a future Apple ARM-based laptop, though I imagine the problem will be getting Windows drivers for the GPU.
If Apple makes such hardware, it will be just a matter of time to port Linux to it. Probably easier than getting it to run on yet another weird internal architecture of a smartphone.
And you can run Linux on that Yoga. It's just Windows for ARM that is the disaster...
I love my ARM-powered Chromebook. True, it can’t teally do native development, but ARM clients aren just coming. They’re here. And wow doesn’t have amazing battery life and an unbrickable OS.
I remember the Transmeta processor, they were neat. I only ever saw 1 Transmeta PC in the wild. IIRC it was a Sony sub notebook. Of course it was running in x86 mode and running Windows. I got to mess with it a bit and for the time it was a pretty good machine.
ARM doesn't ”have a problem” with the ordering. Rather, those CPUs take advantage of the re-ordering allowed by the specified ordering constraints. The behaviour is entirely expected. The default option for those c++ atomic operations is the strongest constraint (memory_order_seq_cst) - a programmer who specifies a more relaxed constraint better have a good reason for it.
Usually the problem is that it exposes latent software bugs hidden by x86 strong guarantees on memory access ordering and cache validity.
Not that someone misused atomics, butt rather does not use them at all and "it works".
>If you develop on x86, then you're going to want to deploy on x86, because you'll be able to run what you test "at home" (and by "at home" I don't mean literally in your home, but in your work environment) ... This is true even if what you mostly do is something ostensibly cross-platform like just run perl scripts or whatever. Simply because you'll want to have as similar an environment as possible
Eh, Android's existence is a pretty big counterpoint to that. And you could just run an ARM VM on your desktop if it's that important to you.
It's of course impossible not to respect Linus' opinion and first hand experience in this space, but doesn't this whole post completely ignore the 100 ton blue whale in the room? Namely smartphones. That's an entire enormous segment of the industry and it's nearly 100% (or entirely 100%?) literally develop-on-x86-deploy-on-ARM. Smartphones also fit
>"This isn't rocket science. This isn't some made up story. This is literally what happened"
right? I mean, I can see arguing that going up into the cloud is different in some ways then going down to smartphones (although the high end ones are now going to outperform plenty of old dev machines in burst power). There are certainly differences in scaling and such. But the maturity of the tech for cross development of high level software isn't the same as it was in that era either. And if we're talking about bottom-to-top revolutions, embedded and smartphones seem to be at a lower level and much higher volume then PCs.
Finally there is clearly an upcoming disruptive fusion event coming due to wearable displays. When "mobile" and "PC" gets merged, it certainly looks like ARM is in a strongly competitive position for some big players, and having more powerful stuff up the stack will matter to them as well.
None of which is to say he won't be right at least in the short term, but it still is kind of odd to not even see it addressed at all, not even a handwave.
> but with smartphones you don't have a choice. so it's different.
Exactly. Linus' point is that Arm has no real advantage in the server space to compensate for the problems with cross-development. That's completely different for smartphones, which is why Arm won that space.
The argument isn't "same instruction set". The argument is "same development & deployment environment", by the logic of which the Apple argument fails because not many people deploy to Apple servers.
So you run a Linux VM, just as lots of Mac-using developers do today. But the instruction set of the VM has to match the instruction set of the host, unless you’re in the mood for slow emulation.
> So you run a Linux VM, just as lots of Mac-using developers do today
I hear far more make do with just homebrew.
> unless you’re in the mood for slow emulation
I run an embedded OS (made for a quad-core ARM Cortex-A53 board) on both Real Hardware and on my ThinkPad (via systemd-nspawn & qemu-arm). I found (and confirmed via benchmarks) the latter to be much faster than the former — across all three of compute, memory, and disk access.
Possibly, it does seem that way for web dev at least. There's plenty of programmers out there (the majority?) not doing web dev and never touching Macs however. In a 20 year game development career I've never had cause to use a Mac for work purposes. Perhaps the share of developers using Macs as their primary development machines exceeds their 10% market share of laptops but I doubt it's a majority.
I’m not sure if this is what you were implying, but I don’t know of any x86 processors that can compete with the Arm processors that are in use, on power consumption to performance ratio. Take e.g. Apple’s A12, which compete with their MacBooks in performance, and assuredly draw much less power.
> I don’t know of any x86 processors that can compete with the Arm processors that are in use, on power consumption to performance ratio
Not anymore, but there was a time when x86 was (barely) able to compete in that area and there were some x86-based smartphones and tablets. But it was too little too late: x86 already was a niche. Developers absolute had to support ARM, but x86 was optional, so many apps were not available for x86, and that was pretty much it for those devices.
You haven't been paying attention. In order to go faster ARM started using more power. A lot more power.
Turns out power usage was never an ARM vs. x86 thing, it was purely a "how fast do you want to go" thing. ARM started at the "very slow" end of the spectrum which made it a good fit for mobile initially since x86 didn't have anything on the "very slow" end of things. By being very slow it was very low power. But then the push to make ARM fast happened, and now ARM is every bit as power hungry as x86 at comparable performance levels.
The power cost is for performance. The actual instruction set is a rounding error.
You don't have much choice now sure, but it's not as if there weren't any efforts at x86 smartphones (like the ZenPhone). Nor is it as if there wasn't a long run up of phones leading to the modern smartphone either. And even in this how is not directly relevant to the case of x86?
I mean, we're directly doing a comparison to the RISC/MIPS/etc era yeah? Couldn't back then someone say "well but with PC you don't have a choice, so it's different"? x86 got heavy traction on the back of WinTel, then moved up to bigger iron, which didn't really fight hard in the lower end lower margin space. Does there really seem to be no deja vu with that vs ARM gaining heavy traction in iOS/Android/embedded then moving up to PCs and servers, where Intel/AMD didn't really play in the lower end lower margin space? There was a period with plenty of choice in servers, but then x86 won.
And again it's not as if someone can't come up with compelling arguments, x86 has some real moats even beyond pure performance. There is enormously more legacy software for x86 for example, and the ISA for it will be under legal protection for a long time to come which complicates running it on ARM. But it's hard to say how much that matters in much of the cloud space, particularly if we're imagining 5-10 years further down the line. x86 takeover didn't happen overnight either, and the first efforts were certainly haphazard. But momentum and sheer volume matter. It just seems like something that needs to be addressed at any rate, more deeply then you have and certainly more then Linus did.
Windows does make a huge attempt to make stuff backwards compatible, however. I run a copy of Cardfile copied from Windows NT4 on Windows 10 just fine.
Linus is mostly wrong except for HPC. Very few dev pipelines for folks result in native executables.
The vast majority of code is delivered as either source (python, ruby, etc) or bytcode, JVM, Scalia, etc.
And the Xeon class machines folks deploy to in data center envs is a world apart from their MacBooks.
These truths are true for Linus, but not for the majority of devs.
Even those creating native binaries, this is done through ci/cd pipelines. I have worked in multi arch envs, Windows NT 4 on mips/alpha/x86, iOS, Linux on arm. The issues are overblown.
He calls that out though "even if you're only running perl scripts". It's not the cross-compilation that's a factor, it's wanting the environment to be as similar as possible.
Even if your code is Java bytecode, that's still running on a different build of the JVM, on a different build of the OS (possibly a different OS). There is opportunity for different errors to crop up. They might be rare, but they'll be surprising and costly when they happen exactly because of that.
The question then is how successful the JVM is. I think you're underestimating it. Torvalds' attitude is certainly justified regarding plenty of other types of software though -- just building a C++ project on a different distro can be a pain.
Someone else [0] points out that Java (in the right context at least) is so successful in isolating the developer from the underlying platform, that it isn't a problem if the developer isn't even permitted to know what OS/hardware their code will run on.
Could they accidentally write code that depends on some quirk of the underlying platform? I think it's not that likely. Nowhere near as likely as in C/C++, where portability is a considerable uphill battle that takes skill and attention on the part of the developer.
> They might be rare, but they'll be surprising and costly when they happen exactly because of that.
Ok, but you can say the same for routine software updates. It's a question of degree.
he just said its not worth it and as a developer if i could chose that i develop on the platform that will run my code i will chose it even if its slightly more expensive. granted that on both i could be same level of productive.
we had those problems when developing in scripting language on windows a code that will run on linux because at some point we needed something that called native and would make us problems with different behavior. after some of that experience we tried to get everybody the same environment that is close to what will run in production.
--- I accidentally deleted this comment, so, I've re-written it. ---
Disclaimer: I'm a HPC system administrator in a relatively big academic supercomputer center. I also develop scientific applications to run on these clusters.
> Linus is mostly wrong except for HPC. Very few dev pipelines for folks result in native executables. The vast majority of code is delivered as either source (python, ruby, etc) or bytcode, JVM, Scalia, etc.
Scientific applications targeted for HPC environments contain the most hardcore CPU optimizations. They are compiled according to CPU architecture and the code inside is duplicated and optimized for different processor families in some cases. Python is run with PyPy with optimized C bindings, JVM is generally used in UI or some very old applications. Scala is generally used in industrial applications.
> And the Xeon class machines folks deploy to in data center envs is a world apart from their MacBooks.
No, they don't. Xeon servers generally have more memory bandwidth, and more resiliency checks (ECC, platform checks, etc.). Considering the MacBook Pro have a same-generation CPU with your Xeon server with a relatively close frequency, per core performance will be very similar. There won't be special instructions, frequency enhancing gimmicks, or different instruction latencies. If you optimize well, you can get the same server performance from your laptop. Your server will scale better, and will be much more resilient in the end, but the differences end there.
> Even those creating native binaries, this is done through ci/cd pipelines.
Cross compilation is a nice black box which can add behavioral differences to your code which you cannot test in-house. Especially if you're doing leading/cutting edge optimizations in the source code level.
Isn't turbo boost an issue when comparing/profiling? my experience with video generation/encoding run of about 30 sec was that my macbook outperformed the server xeons... if left to cool down for a few minutes between test runs. otherwise a testrun of 30 seconds would suddenly jump up to over a minute.
the xeons though always took about 40 seconds.. but were consistent in that runtime (and were able to do more of the same runs in parallel without loosing performance)
> Isn't turbo boost an issue when comparing/profiling?
No. In HPC world, profiling is not always done over "timing". Instead, tools like perf are used to see CPU saturation, instruction hit/retire/miss ratios. Same for cache hits and misses. For more detailed analysis, tools like Intel Parallel Studio or its open source equivalents are used. Timings are also used, but for scaling and "feasibility" tests to test whether the runtime is acceptable for that kind of job.
OTOH, In a healthy system room environment, server's cooling system and system room temperature should keep the server's temperature stable. This means your timings shouldn't deviate too much. If lots of cores are idle, you can expect a lot of turbo boost. For higher core utilization, you should expect no turbo boost, but no throttling. If timings start to deviate too much, Intel's powertop can help.
> my experience with video generation/encoding run of about 30 sec was that my macbook outperformed the server xeons...
If the CPUs are from the same family, and speed are comparable, your servers may have turbo boost disabled.
> otherwise a testrun of 30 seconds would suddenly jump up to over a minute.
This seems like thermal throttling due to overheating.
> the xeons though always took about 40 seconds.. but were consistent in that runtime (and were able to do more of the same runs in parallel without loosing performance)
Servers' have many options for fine tuning CPU frequency response and limits. The servers may have turbo boost disabled, or if you saturate all the cores, turbo boost is also disabled due to in-package thermal budget.
If you have any more questions, I'd do my best to answer.
I am not sure we are disagreeing on much, but the 4 core i7 in my dev MacBook is a whole lot different than the dual socket, 56 core machines we run on.
Optimizations that need to happen, don’t happen locally, they get tuned on a node in the cluster. Look at all the work Goto has done on Goto Blas.
We agree on HPC, however I also agree with Linus about non-HPC loads. Software and developers are always more expensive than hardware, but scaling beyond a certain point in hardware (number of servers, or the GPUs you need) drives the hardware and maintenance cost up, hence the difference becomes negligible, or the maintenance becomes unsustainable. This is why everyone is trying to run everything faster with the same power budget. At the end, after a certain point, everyone wants to run native code at the backend to reap the power of the hardware they help. This is why I think Linus is right about ARM. That's not I'm not supporting them, but they need to be able to run some desktops or "daily driver" computers which support development. Java's motto was write once, run everywhere, which was not enough to stop migration to x86. Behavioral uniformity is peace of mind, and is a very big peace TBH.
What I wanted to say is, unless the code you are writing consists of interdependent threads and the minimum thread count is higher than your laptop, you can do 99% of the optimization on your laptop. On the other hand, if the job is single threaded or the threads are independent, the performance you obtain in your laptop per core is very similar to the performance you get on the server.
For BLAS stuff I use Eigen, hence I don't have experience with xBLAS and libFLAME, sorry.
From a hardware perspective, a laptop and a server is not that different. Just some different controllers and resiliency features.
Even in a bytecode language, there is no guarantee that an application is write-once run-everywhere. I converted a small app that was running on Windows with Oracle JDK to run on Linux with OpenJDK and it was not plug-and-play. It was close, but there were a few errors particularly surrounding path resolution (and yes, the Windows application was already using Unix-style paths, this was actually a difference in how paths were resolved). Similarly, there are small differences between Tomcat and Jetty and so on.
This wasn't showstopping by any means, but it did take a couple of hours to tweak it until it ran properly, and this was just a small webapp not really doing anything exceptional.
Our main line-of-business app (on Java) runs on SPARC/Solaris in production, so we have on-premises test servers so we can test this... and yes, there have been quite a few instances where we identified significant performance anomalies between developer machines running x86/Windows and our Sparc/Solaris test environment, and had to go rewrite some troublesome functions.
Correct, we need to stabilize all these factors in order to ensure stable, bug free deployment. A Good Post.
Oh, you meant that just because there is one other thing that you might slip up and forget to control for, we shouldn't bother trying to control anything? No, wait, that's actually A Very Bad Opinion.
Smartphones are a good argument for both views IMHO. Native development (as in native machine code executables) on Android is still a terrible experience even though they had a decade to fix it. It's much better on Apple platforms, maybe because they actually cared about developer-experience and native code is a "first class citizen" there.
It goes beyond the different instruction set of course and most of the time this is indeed mostly irrelevant (unless you've arrived at processor-specific optimizations), but the "develop on the same platform you are running on" still has the least painful workflow IMHO.
I bet Apple's experience moving from PowerPC to X86 gave them a leg up as well, and in both cases (PowerPC/X86, MacOS/iOS) they had the power to force developers to cross-develop to maintain access to their platform. Nobody is in a position to force server-side developers to switch to ARM.
From the other perspective too, Google clearly seemed to want the flexibility to change the details of Android architecture on a "whim", seeming to settle on the Linux kernel at the last minute and expecting to support both ARM and x86 and whatever else they felt they wanted. Google's focus on the JVM/Dalvik and making Native hard in Android seems quite intentional, forcing developers to cross-develop in a different way by obfuscating as much code as possible into a virtual machine that they could 100% control abstracted from underlying architecture and even kernel.
Native development sucking on android is mostly an android problem (and to some extent a Qualcomm problem since their smartphone SOCs don’t support anything else.)
I think the ARM-based Macs are inevitable, although it might be called "iPad Pro Developer Edition".
This is Jeff Atwood's argument: https://blog.codinghorror.com/the-tablet-turning-point/ ; Apple tablet performance at Javascript is now catching up to and exceeding desktop performance. Apple have also sunk a lot of money into developing their own processor line, and they have experience in force-migrating all their customers between architectures. At some point you might not be able to buy an Intel-based Apple laptop any more. Given the immense brand loyalty among web developers, they are likely to shrug and carry on .. and start demanding ARM servers with high Javascript performance.
I just wonder if Apple can design laptop chips that perform well (per watt) at 45W TDP or desktop chips at 2-3x that and with multiple sockets. If not, then what’s the point?
I won’t move to an ARM Mac, personally. I will move to Windows or Linux on x86 for all the reasons Linus gives and also for games. Sorry, but an ARM Mac may finally push me where crappy keyboards and useless anti-typist touch bars have not quite done.
Native (NDK) development on Android is hard on purpose, as means to increase the platform security and target multiple SOCs.
NDK level programming is explicitly only allowed for scenarios where ART JIT/AOT still isn't up to the job like Vulkan/real time audio/machine learning, or to integrate C and C++ from other platforms.
In fact, with each Android release, the NDK gets further clamped down.
I would like a better NDK experience, in view of iOS and UWP capabilities, on the other hand I do understand the security point of view.
Yeah, right, just like the PS3 was intentionally hard to develop for to keep away the rubble. That worked out really great (at least Sony did a complete 180 and made the PS4 SDK a great development environment).
As long as Android allows running native code via JNI, the security concerns are void anyway. If they are really concerned about security, they would fix their development tools (just like Apple did by integrating clang ASAN and UBSAN right into the Xcode UI).
One article is about enforcing the exvlusive use of public APIs. The rest is about hardening the C/C++ code of AOSP. I dobnot see any "clamping down" here. What am I missing?
Except they allow nearly everything for regular Android apps since libc lets you access nearly every syscall.
Nothing was meaningfully "clamped down" there. You can't directly syscall some obsolete syscalls anymore, and you can't syscall random numbers, but nearly any actual real syscall is still accessible and nothing indicates that it won't be.
As long as libc can do it so can you, since you & libc are in the same security domain. Or anything else that an NDK library can do in your process, you can go poke at that syscall, too.
It'd almost always be stupid to do that instead of going through the wrappers, but you technically can
This is mostly setgid/setuid, mount point and system clock related stuff. Except for syslog and chroit, I see no syscalls that you should be using in a user process anyway.
So technically, this is clamping down Android, but it seems like a pretty reasonable restriction and far from a heavy handed approach.
What do you think can be improved in Android? Unlike iOS, Android is actually running in diverse hardware. All iOS devices are Arm, where as Android will run on x86. That alone makes it more of a hassle.
MIPS support has been officially dropped but x86 is still very alive - mostly due to the emulator these days, though, but some Android TV hardware was using it for a while, too.
The command line C/C++ toolchain is fine, at least now where this is basically reduced to clang and libc++.
The problem is basically everything else:
- The ever changing build systems. And every new "improvement" is actually worse than before (I think currently it is some weird mix of cmake and Gradle, unless they changed that yet again).
- Creating a complete APK from the native DLL outside Gradle and Android Studio is arcane magic. But both Android Studio and Gradle are extremely frustrating tools to use.
- The Java / C interop requires way to much boilerplate.
- Debugging native code is still hit and miss (it's improved with using Android Studio as a standalone debugger, but still too much work to setup).
- The Android SDK only works with an outdated JDK/JRE version, if the system has the latest Java version, it spews very obscure error messages during the install process, and nothing works afterward (if it needs a specific JDK version, why doesn't it embed the right version).
The Android NDK team should have a look at the emscripten SDK, which solves a much more exotic problem than combining C and Java. Emscripten has a compiler wrapper (emcc) which is called like the command line C compiler, but creates a complete HTML+WASM+JS "program". A lot of problems with the NDK and build system could be solved if it would provide a compiler wrapper like emcc which produces a complete APK (and not just a .so file) instead of relying on some obscure magic to do that (and all the command line tools which can do this outside gradle are "technically" deprecated).
...hrmpf, and now that I recalled all the problems with Android development I'm grumpy again, thanks ;)
Not disagreeing, but answering the question of are all phones ARM: no, there Intel too. Source: had to add Intel build support for our Android SKUs to run on said phones. Some Unity stats from about 6 months ago indicated:
ARMv7: 98.1%
Intel x86: 1.7%
I think a lot of the Intel stuff has been discontinued, not sure what is actively being developed outside of ARM right now.
This is strange. Maybe like a Windows phone? Where does it get those device metrics? < 2% makes me think it might just be that Androidx86 emulator project.
(and there were a lot of small brands that used to make them, that I don't believe get represented in that list)
Having said that, for it to reach >1%, it was more likely a combination of Intel Android tablets (which were fairly common for a while) and Chromebooks.
I have an Asus Zenfone 2, complete with its "Intel Inside" logo. Not particularly special but when I bought it met the critera of "gorilla glass + pokemon go for below $150". Nice case too.
He did address the so-called 100-ton blue whale at the end:
> End result: cross-development is mainly done for platforms that are so weak as to make it pointless to develop on them. Nobody does native development in the embedded space. But whenever the target is powerful enough to support native development, there's a huge pressure to do it that way, because the cross-development model is so relatively painful.
except that developing for ARM SBC's natively is normal these days. Even the lowly Raspberry Pi encourages you to plug-in an HDMI monitor, a USB mouse and keyboard, and boot into Raspbian, where things like Wiring-Pi further extend your cross-development reach (LOL), while you develop the code for your peripheral directly on the computer that's going to run it.
It's a bit of a Matryushka doll in that I have both Propeller chip and FPGA "Hat's" for my Pi and use both propeller IDE and the Icestorm toolchain to natively cross-develop for ACTUALLY embedded devices, as the ARM device is the main computer already and not the embedded device anymore lol
> That's an entire enormous segment of the industry and it's nearly 100% (or entirely 100%?) literally develop-on-x86-deploy-on-ARM.
I'm not sure I agree with. My coding environment is on x86, and I build on x86, but my Run/Debug cycle is on ARM. No one is really encouraged to test on the simulator even though it's available, you are almost entirely asked to test on your actual arm device and run it and see the results of your work.
Linus is making the argument that people want their release builds to run in the same environment as their daily test builds, and I don't see smartphone development as an exception to that rule.
I don't see this happening. PCs are tools for getting real work done. Mobiles are mostly communication and entertainment devices.
I like to fall back on this Steve Jobs quote, employing a car/truck metaphor for computers:
When we were an agrarian nation, all cars were trucks, because that's what you needed on the farm. But as vehicles started to be used in the urban centers, cars got more popular … PCs are going to be like trucks. They're still going to be around, they're still going to have a lot of value, but they're going to be used by one out of X people.
Communication is also work, especially as you go up the management value chain. I think maybe people should refer to the thing that PCs do and mobiles don't as "typing".
I would expand “reading” to “consumption” because mobile devices are frequently used for audio and video in addition to reading (which is probably more “browsing” than long-form reading).
It isn't just the keyboard which PCs hold as an advantage, it's the mouse as well. There are a lot of tasks that workers do on PCs with a mouse that can't be done reliably with a touchscreen.
Maybe an iPad Pro with its stylus could perform a lot of those mouse-driven tasks, but using the stylus for long periods of time is going to be exhausting and injury-prone. By using a mouse your arm can rest comfortably and allow you to work for long periods of time with minimal effort and no strain.
We've known about Fitz's Law since the dawn of the GUI and have decades of study on it. It's not any more efficient to need to "headshot" everything you need in an application 100% of the time, and in fact it is often rather the opposite that it gets in the way of actual efficiency.
Mousing through most "mobile" applications is great, whether "first class" or not.
Desktop and mobile OSes don't need to remain separate, and it's really past time that a lot of super-cramped "desktop apps" got the death they deserved for their decades old RSI problems, accessibility issues, and garbage UX.
It's friendly but it's not space efficient. For applications with a huge number of features, a touch UI can't handle them. Touch screens don't have right click, so you can't get context menus.
It's more than that, though. A touch screen UI for the iPhone makes zero sense on a 32" display. I'd much rather have a true multiwindow, multitasking operating system than that. Really, I wouldn't use a 32" iOS device at all. That's probably why Apple doesn't make them.
Sure they can, but why bother? When I use Windows, I use real Windows applications with desktop UIs. The touch UI mobile apps are a joke on a desktop monitor.
User studies from the dawn of the GUI continue to harp that user efficiency is inversely correlated to space efficiency. It doesn't matter if an application can show a million details to the individual pixel level if the user can't process a million details or even recognize individual pixels.
> Touch screens don't have right click, so you can't get context menus.
You don't need "right click" for context menus.
Touch applications have supported long-press for years as context menu. Not to mention that macOS has always been that way traditionally because Apple never liked two+ button mice.
Then there's touch applications that have explored more interesting variations of context menus such as slide gestures and something of a return to relevance of Pie Menus (which it is dumb that those never took dominance in the mouse world and probably proof again that mice are too accurate for their own good when it comes to real efficiency over easy inefficiency).
> I'd much rather have a true multiwindow, multitasking operating system
Those have never been mutually exclusive from touch friendly. It's not touch friendliness that keeps touch/mobile OSes from being "true multiwindow/multitasking", it's other factors in play such as hardware limitations and the fact that tiling window managers and "one thing at a time" are better user experiences more often than not, and iOS if anything in particular wants to be an "easy user experience" more than an OS.
(I use touch all the time on Windows in true multiwindow/multitasking scenarios. It absolutely isn't mutually exclusive.)
Very few people are primarily messaging as their job. Even outside developers, designers and other creatives, the majority of people work on some mix of spreadsheets, presentations and traditional docs on a daily basis. I guess you can do a little bit of word processing on a phone but it gets ugly pretty fast.
I’ve always thought PCs will become business workstations. Meaning you use them for office work but everything else will be “cars” as your quote put it. Meaning internet browsing, social media, view/edit photos, and the like will be done on some mobile device. Windows is alresdy the de facto business workstation and I don’t see it going away.
There’s already a whole generation or two who will likely have little to no experience with PCs.
I'm genuinely very sorry for missing this comment (9 hours ago as I write this) because I think it's a really important and interesting next area of development. Since this article is still front page though, I hope I'm not too late to have some discussion here particularly since none of the other replies have taken the analysis approach I do.
If we're trying to predict the future, I think one effective approach to try to not be trapped in the present paradigm is to try to extrapolate from foundations of physics and biology that we can count on remaining constant over the considered period. Trying to really get down to the most fundamental question of end user computing, I think it's arguable that the core is "how do we do IO between the human brain and a CPU?" With improving technology, effectively everything else ultimately falls out of the solution to creating a two-way bridge between those two systems. The primary natural information channel to the human brain is our visual system with audio as secondary and minimal use of touch, and the primary general purpose output we've found are our hands and sometimes feet, with voice now an ever more solid secondary and gestures/eye movements very niche. Short of transhumanism (direct bioelectric links say) those inputs/outputs define the limits of out information and control channels to computers, and the most defining of all is the visual input.
Up until now, the screen has defined much of the rest, and a lot of computer can be thought of "a screen, and then supporting stuff depending on the size of the screen." A really big screen is just not portable at all, so the "supporting stuff" can also be not portable which means expansive space, power, and thermal limits as well as having the screen itself able to be modularized (but even desktop AIOs can pack fairly heavy duty hardware). Human input devices can also be modularized. Get into the largest portable screen size and now the supporting gear must be attached, though it can still have its own space separate from the screen. But already the screen is defining how big that space is and we're losing modularity. That's notebooks. Going more portable then that, we immediately move to "screen with stuff on the back as thin and light as feasible" for all subsequent designs, be it tablets, smartphones, or watches. The screen directly dictates how much physical space is available and in turn how much power and how much room to dissipate heat. And that covers nearly the entire modern direct user computing market.
Wearable displays, capping out at direct retinal projection, represent a "screen" that can hit the limits of human visual acuity while also being mobile, omnipresent, and modularized. I'm really actually kind of surprised how more people don't seem to think this represents a pretty seismic change. If we literally have the exact same maximalized (no further improvements possible) visual interface device everywhere, and the supporting compute/memory/storage/networking hardware need not be integrated, how will that not result in dramatic changes? It's hard to see how "Mobile" and "PC" won't blur in that case. Yeah, entering your local LAN or sitting at your desk may seamlessly result in new access and additional power becoming available as a standalone box(es) with hundreds of watts/kilowatts becomes directly available vs the TDP that can be handled by your belt or watches or whatever form mobile support hardware takes when it no longer is constrained to "back of slab", but the interfaces don't need to necessarily change. Interfaces seem like they'll depend more on human output options then input, but that seems likely to see major changes with WDs too, because it will also no longer be stuck in integrated form factor.
WDs definitely look like they're getting into the initial steeper part of the S-curve at last. Retinal projection has...
Mainframes, have been the pioneers of using bytecode as distribution format, with the CPUs being microcoded for the specific bytecode set (e.g. Xerox PARC / Burroughs), or having JIT/AOT compilation at deployment time like IBM i and IBM z (aka OS/400, OS/300).
So while Linus opinion is to be respected, mainframes, and the increase in smartphones, smartwatches and GPS devices use of bytecode distribution formats with compilation to native code at deployment time, shows another trend.
Good point, from Linus' opinion it can still happen after ARM is king of the client market. Well, they're well on their way doing that with every client except for desktop being ARM, while Intel is having trouble with 7 nm.
I don't think that in any way contradicts his position
>And the only way that changes is if you end up saying "look, you can deploy more cheaply on an ARM box, and here's the development box you can do your work on".
Sure, as soon as these merge and you have a development platform as productive as a desktop computer that allows you to natively build for ARM, then absolutely, it could displace x86. And maybe when (if) the two platforms really merge that could be a real possibility.
There may be people somewhere doing Android/ChromeOS/Fuchsia development on ARM Chromebooks, following the Google model of using a mostly cloud-based toolchain together with a local IDE. There’s none of this happening inside Google itself, though, yet—but that’s just because Google issues devs Pixelbooks, and they’re x86 (for now.)
But, since Pixelbooks (and ChromeOS devices in general) just run web and Android software (plus a few system-level virtualization programs like Crouton) there’s nothing stopping them from spontaneously switching any given Chromebook to ARM in a model revision. So, as soon as there’s an ARM chip worth putting in a laptop, expect the Pixelbook to have it, and therefore expect instant adoption of “native development on ARM” by a decent chunk of Googlers. It could happen Real Soon Now (hint hint.)
> but doesn't this whole post completely ignore the 100 ton blue whale in the room? Namely smartphones.
This is patently false. Mobile developers do test their apps on smartphones, eventhough google and apple offer VMs. You'd be hard pressed to find a mobile app software house that doesn't have a dozen or so smartphones available to their developers to test and deploy on the real thing.
Surely this would be the same for server software: If prod was running on ARM, then you'd probably have your CI server running ARM too. But that wouldn't stop you developing on x86 if that was what was convenient.
> Surely this would be the same for server software: If prod was running on ARM, then you'd probably have your CI server running ARM too.
CI/CD is already too far ahead in the pipeline to be useful. CI is only a stage where you ensure that whatever you've developed will pass the tests that you already devised, but it's already a stage where you already tested and are convinced that nothing breaks.
The type of testing that Linus Torvalds referred to is much back in the pipeline. He is referring to the ability to ramp up a debugger and check if/when something is not working as expected. Developers do not want to deal with bugs that are only triggered somewhere in a CI/CD pipeline, and can't reproduce in their target machines.
No, I'm saying that mobile development is also a clear example that developers do want to develop for platforms that they actually can test, which was the point that Linus Torvalds made.
He's also apparently assuming that ARM-based Chromebooks will never be a useful developer environment. I wouldn't take that bet -- a lot of the newer ones will support Linux VMs out of the box well enough to support at least a half-decent development environment (via Crostini). (You can get a Pixelbook with 8GB RAM and a 512GB SSD, if you're wondering about storage space. And while Crostini still has issues with in-VM driver support for things like the Chromebook's own audio and camera, that's stuff that server software wouldn't use much anyway.)
Between that and the much-rumored ARM Macs, this could turn pretty quickly...
I don't think he's assuming any such thing. His argument is simply that ARM can't win until it has a reasonable dev box. He makes no speculation about if/when such a box is coming.
Maybe the interesting part of the smartphone ARM story is the degree to which Apple has used custom silicon to optimize speed and power for their own specific workloads and software.
Why couldn't ARM-based servers do the same thing? I understand why a generic ARM-based CPU might not win against a generic ARM-based x86 CPU at running cross-compiled code in Linux. But what if the server has a custom ARM-based chip that is a component of a toolchain that is optimized for that code, all the way down to the processor?
Imagine a cloud service where instead of selecting a Linux distro for your application servers, you select cloud server images based on what type of code you're running--which, behind the scenes, are handing off (all or part of) the workload to optimized silicon.
I don't have the technical chops to detail how this would work. But I think my understanding of Apple's chip success is correct: that they customize their silicon for the specific hardware and software they plan to sell. They can do that because they own the entire stack.
I think if any company is going to do that in the server space, it would have to be the big cloud owners. No one else would have the scale to afford the investment and realize the gains, and control of the full stack from hardware to software to networking. And sure, enough, that is who are embarking on custom chip projects:
So, maybe the result won't be simply "ARM beats x86," but rather "a forest of custom-purpose silicon designs collectively beat x86, and ARM helped grow the forest."
Ya it's kind of weird he talks about how stuffing a beige box PC in the corner was the impetus for X86 servers. But the modern day equivalent of that is either a cheap $5/month VPS, a RaspberryPi, or an OpenWRT router, any of which could compile/run ARM code.
I think fundamentally, the error he's making is comparing the current market to the late 90s/early 2000s market. Back then a RISC Unix machine cost thousands of dollars. It was cost prohibitive to give one to each dev/admin. Nowadays a RISC Linux PC is $5.
Actually, you make the best case for ARM servers of anyone else in this thread.
The starving college kid in a Helsinki dorm working on his EE degree can't afford 600-1000 dollars for another Laptop/Desktop to experiment with. A 35 dollar ARM SBC and a monitor that doubles as his TV is right in his price range...
That doesn't invalidate his point. He's just saying that is basically what needs to happen for ARM servers to start taking off. The next step is for companies to start deploying ARM workstations. That part still seems to be a good way off, MS abandoning their Windows ARM port didn't help the cause.
The starving college kid in a Helsinki dorm working on his EE degree can't afford 600-1000 dollars for another Laptop/Desktop to experiment with. A 35 dollar ARM SBC and a monitor that doubles as his TV is right in his price range...
35 dollars will buy you an oldish x86 beige box that will absolutely flat out murder a Raspberry Pi performance-wise. Cheap, fast hardware is not a problem anymore.
Intel also had KNC instruction set (AVX512-like) on Xeon Phi (these CPUs available on PCI cards). They abandoned it in favour of good old x86. One of important factors was the difficulties related to tooling, especially necessity of cross-compilation.
He's shuffling smartphones in under embedded I believe.
His thesis is that if you want a platform to take off, start shipping developer boxes of the platform. So mobile and pc will merge when and only when you can do all your development on a mobile platform.
Actually, Linus does not ignore the smartphone space at all. In fact he refers to it by pointing out that people are likely to ONLY use cross compiling if the deployment is to a embedded device (which a smartphone is) because the native development on the embedded device may not be possible.
<quote>End result: cross-development is mainly done for platforms that are so weak as to make it pointless to develop on them. Nobody does native development in the embedded space. But whenever the target is powerful enough to support native development, there's a huge pressure to do it that way, because the cross-development model is so relatively painful.</quote>
> as long as everybody does cross-development, the platform won't be all that stable.
I tend to agree that it will suffer. But you can get ARM chromebooks, a bunch of vendors offer ARM-based Windows laptops, and Apple is planning on leveraging their SoC on OS X computers. So it may not necessarily be cross-development for long.
I'm curious why you believe that. Aside from the hype and the association with the word "open", I honestly can't think of anything interesting or important about RISC-V.
For the low-end deeply embedded space, I could see RISC V becoming a significant player in the next 5 years. ARM is relatively expensive there (it's cheap compared to Intel for servers, but at the low end it's more the IBM of Microsoft of old), and there's less need for their ecosystem (most 3rd party software is open source). The Cortex M are less flexible then some competitors in their configuration, and designing good small CPU IP is doable at the low end. So all the small custom designers (Andes, BA semi, Cortus...) can rally around RISC V and have cheap and flexible design, with a good shared software ecosystem. Today it's still one or the other.
At the high-end it's very different. To be competitive one has to take advantage of the latest process nodes, and work well ahead of time with fabs and EDA vendors on the next node(s). This is highly labor intensive, and it takes deep pockets and a lot of resources. ARM is already there, and well entrenched. Getting enough money to replicate this on the RISC V side will take a loooooong while, if it ever happens. Unless a deep pocketed company decides to use RISC V and go their own way, but it seems very unlikely. Look at how even Qualcomm reduced its work on custom ARM cores for their high end, and now do tweaks on ARM designs.
But personally I'm fine with this. It's mostly at the low end / embedded that I feel there's a need for more competition.
1. OS/X is Unix[tm] and linux is a "Unix clone" so the operating system works the same and (for purposes of this debate) both run on the X86 ISA.
2. The first thing all the macbook developers do is install Homebrew or equivalent and install all the same packages that are installed in their linux deployment environment.
At that point, their OS/X development environment is effectively indistinguishable from their linux deployment environment.
> Some people think that "the cloud" means that the instruction set doesn't matter. Develop at home, deploy in the cloud.
> That's bullshit. If you develop on x86, then you're going to want to deploy on x86, because you'll be able to run what you test "at home" (and by "at home" I don't mean literally in your home, but in your work environment).
This is why having a compilation target that works the same way everywhere would be so valuable. We're some ways away from this, but I think WebAssembly offers hope here.
As for the rest of the article, it'd be best if we could have a discussion style where people don't preemptively paint people who disagree with them, or who have a different perspective, strategy, or end goal, as "idiotic" and "stupid", or posit that people have a "total disconnect to reality." This is known as poisoning the well. It does not advance the discussion. In fact it is specifically designed to limit and stop the discussion. The reality is that it simply makes people angry and polarized, amps up the stakes, and ultimately leads to a toxic culture.
Thankfully, I think HN has a better culture. Linus can do better, IMO.
> This is why having a compilation target that works the same way everywhere would be so valuable. We're some ways away from this, but I think WebAssembly offers hope here.
Why does WebAssembly offer more hope than the JVM, or interpreted languages that we already have? It will still have to interop with native libraries to get work done.
It's lower level than the JVM and more of an abstraction over hardware. So native libraries can be compiled directly into it, so everything can interop on top of Wasm.
The jvm is explicitly designed to run the Java language. It has Java's type system baked into the bytecode. It is not an abstraction over hardware. (it doesn't even have unsigned comparisons :()
I disagree. Let passionate people on all sides have their say. I think it's more toxic to stifle passionate people.
It's amazing how everyone from Steve Jobs to Bill Gates to Linus Torvalds is labeled as "toxic" and yet the "toxic" environment they created led to substantial advancements.
And poisoning the well ( or any ad hominem derivatives ) doesn't stop discussion, it generally leads to more discussions - though often times more contentious and off topic. And though I agree that it can make people angry, polarized and amp up the stakes, those aren't necessarily bad things. Most of the time, it is actually a good thing and a basis for competition.
Finally, I'd say HN has a different culture, not necessarily better. Also, what you are doing could be viewed as a form of shaming and virtue signaling. And at the end of the day, if you don't like linus's style of communication, you don't have to read or listen to it.
I don't understand the mentality of "I don't like it so you should change".
> It's amazing how everyone from Steve Jobs to Bill Gates to Linus Torvalds is labeled as "toxic"
To be clear, there is a difference between toxic people and toxic behaviors. The former, I think, doesn't exist. There are people who often engage in toxic behavior, and those who do rarely. Pointing out toxic behavior is the first step to correcting it. And correcting it is in fact the goal of community guidelines, in order to establish a more inclusive culture.
> Let passionate people on all sides have their say. I think it's more toxic to stifle passionate people.
Let's be clear about what "toxic" means, and not let it degenerate to "loud and I don't like it." Toxic means that it actively damages open discussion, drives people away, and kills off conversations. It is the same sense as a toxic substance; kills.
> And poisoning the well ( or any ad hominem derivatives ) doesn't stop discussion, it generally leads to more discussions
Ok this is manifestly untrue. Please read (https://en.wikipedia.org/wiki/Poisoning_the_well). Poisoning the well is a form of preemptive insult to discourage opponents from taking a position by making it seem toxic. The fallacy is aptly named.
> what you are doing could be viewed as a form of shaming
Yep! I am happy to shame toxic behavior when it is clear.
> and virtue signaling
Maybe. I'd be happy to do it anonymously if you would prefer.
> And at the end of the day, if you don't like linus's style of communication, you don't have to read or listen to it.
This is the very definition of suppressing conversation: sending people away who don't feel like putting up with insults. It's counterproductive and unnecessary.
> I don't understand the mentality of "I don't like it so you should change".
This isn't some he-said she-said situation. I am pointing out direct unprovoked insults designed to stifle discussion and establish a particular point of view. As I have made it abundantly clear, I find this completely unnecessary and I pointed it out because I really think we can stop doing this if we're just consistent about it. We'll have better discussions with more diverse viewpoints, not just hotheads shouting at each other.
When we are talking about toxic, I think we all understood it meant behavior. And the point of community guidelines isn't to make it the community more inclusive, it's actually to make it more exclusive. Limiting speech and thoughts are exclusive behaviors, not inclusive ones. But I'm all for HN or any other platform having guidelines.
I studied philosophy in college so I don't need an explanation of what poisoning the well is. "Poisoning the well" itself is poisoning the well and I don't want to get into the intricacies of ad hominems and logical fallacies. Many times, people misunderstand logical fallacies and use logical fallacies themselves to stifle debate.
Also, Linus wasn't having an argument or a debate. He was giving his opinion. He is allowed to say someone's argument is stupid : "how stupid your argument is.". He didn't call people stupid, he called the argument stupid.
Finally, ad hominems may or may not stifle discussion from the passionless or people who don't care about the topic, but it never stifles discussion from passionate people or people who care about a topic. Every major debate - going back to religious debates or debates about science or debates about slavery or debates about civil rights or anything else was "passionate". Can you imagine these debates being shut down because that's not what "polite company discusses"?
And why would it matter whether you virtue signal anonymously or not? You are already anonymous as HN is thankfully an anonymous forum. One thing HN is fairly good about ( as far as I know ) is anonymity.
I don't believe in ad hominems or attacking people. But if people want to use harsh language to express ideas they are passionate about, I say go for it. The same goes for you. You seem passionate about the subject and I support your right to express it in whatever manner you choose. What I find ironic is that under the aegis of "inclusivity and encouraging discussion", you are advocating for exclusion and stifling Linux Torvalds' speech. But as they say, the road to hell is paved with good intentions. Certainly, you can see that you are doing precisely what you claim Torvalds is doing - stifling speech ( or at least advocating for it ).
Well, we are going to disagree about this, so I won't drag this on forever. However I would like to be clear about a couple things.
> And the point of community guidelines isn't to make it the community more inclusive, it's actually to make it more exclusive.
Again, mixing up behaviors and people. The whole point of community guidelines is to serve the community--to include and support a wide range of people, not a wide range behaviors. Certain behaviors just flat out drive people away--that is the very definition of exclusiveness. Being "inclusive" of these toxic behaviors leads to an exclusive culture. The worst, most exclusive cultures are the ones without guidelines, full of bad behavior. Inclusiveness requires curation of behavioral guidelines. Let's not invert the sense of words when convenient for argumentation (e.g. calling community guidelines and behavioral standards "exclusiveness" because they discourage one type of bad behavior but encourage hundreds of other good ones).
> What I find ironic is that under the aegis of "inclusivity and encouraging discussion", you are advocating for exclusion and stifling Linux Torvalds' speech.
This seems to be the crux of the issue. First, it's an exaggeration to say that advocating against using insults and inflammatory language is "stifling" (see above). I actually want Linus to speak his mind--just do so without the anger channel. It's really fucking annoying to some people. Even calling ideas stupid is really fucking annoying to the people who have those ideas. But the worst part is, for every Linus there is, there are dozens, maybe hundreds of people who are going to read something like that and just silently leave. That's a sign of a bad culture. That's toxic right there. And those people who leave are the meek ones who normally wouldn't speak up because they don't want to get the firehose and spotlight pointed right at them. They don't want their ideas called stupid or idiotic or be told they aren't dealing with reality. Those kind of people that actually can be very bright and have very different (and valuable!) perspectives. The kind of people who just disappear and you never notice. And I've met plenty of people like this--if you ever people-managed, you find out hey, this or that person is leaving, and it's because they actually really didn't like being around this group. It's a loss. Most people just don't notice, but their community just got a little worse each time that happens. So you gotta find soft ways to stop it.
At any rate. Generally your comments can be construed as a defense of people that really don't need any defense. That makes it even worse when the community explicitly stands up and defends loud, obnoxious, unnecessary behavior and lionizes these "hotheads". (To be clear, I am not suggesting you are explicitly doing that, it just has that ring to it). Trust me, hotheads need no defense. They need no coddling or encouragement to keep mouthing off. Many hotheads will stick around and annihilate a community, perhaps unconsciously, because it works. They win. So don't defend them. Defending bad behavior is a death spiral, as it sends exactly the wrong message about inclusion, and that's double bad.
It's semantics to say community guidelines serve to support a wide range of people and not behaviors. It has the same effect. It will drive away people who do not fit your definition of "good" behavior. It's no different than homophobic policies that said we don't discriminate against gays, we discriminate against "bad behavior". And certain behaviors can drive away people, but censorship definitely does.
And I have to disagree with you about the worst communities. The worst communities are those with too much guidelines. Of course some guidelines are necessary, but mostly those involving harrassment, not speech. The US is based on the idea of less guidelines. North Korea, China, Russia, etc are based on "lots of guidelines". And the death spiral can go boths ways. Just as much to totalitarianism as it can go to anarcy.
Also, it's not an exaggeration that "insults and inflammatory language" is stifling. It's the definition of it. Anything can be considered insulting to anyone. That's why we have principled understanding of free speech. The basis of free speech is that you have the right to offend. Otherwise, you claiming that the earth is round is offensive and inflammatory to a flat earther and grounds for censorship.
You seem to think that just because I think someone should be allowed to say "an argument is stupid" is me advocating for anarchy or harrassment. I'm not. Also, "insults" aren't that insulting to everyone. Language that you find offensive isn't offensive to me. And I don't consider Linux's language to be offensive. But you do. But that's the point isn't it. Everyone has a diverse upbringing and diverse opinions.
Also I'd stay away from the term "bad behavior" because that's the same terminology the chinese government uses to crack down on its own citizens and oppress them. It's rather paternalistic and authoritarian which reminds people of the worse form of nanny states.
And last thing, why do you care how linux speaks. He is his own individual. Does he come to you and tell you how you should speak? I just find it the high of arrogance that you ( a relative nobody just like me ) has the gall to tell someone like Linux how he should speak or behave. If you don't like it, just don't read what he says. That's what I find frustrating. Why do you feel like you get to tell others how to live their lives?
At the end of the day, the people at HN can do what they want because it's their property. Regular users like you and I won't change anything. Just like we aren't going to change Linux or the platform he uses to express his opinions. I wish I could have changed your mind but I think I failed so I'll just end it here too. I just find it strange that anyone on hacker news would be demanding that linus torvalds or anyone for that matter be censored.
Let passionate people be passionate, but there is no reason to accept immature and toxic behavior. I won't answer the rest, because I believe your opinion is stupid :)
> And the only way that changes is if you end up saying "look, you can deploy more cheaply on an ARM box, and here's the development box you can do your work on".
Linus is overestimating the amount of native code being produced.
I agree with Linus so far, as that the old RISC vendors got killed, because there were only a few, if any, offerings for consumers. Less so because of the code migration issues, but rather, because the volume of processor production was to low to compete with Intel back then.
However, there is an elephant in the room today: smartphones. ARM processors are suddenly a huge market, allowing for higher R&D expenses. And basically everyone already owns an ARM-powered device, most developers are actually developing for ARM today when they build apps.
So, and there I agree with Linus again, what is a bit missing is ARM-based desktop hardware. The best thing ARM could do to push their cloud processors would be to make affordable motherboards with their processors available to hobbyists and enthusiasts. But ARM is coming to the desktop anyway, be it through the ARM-based Windows laptops or that Apple builds an ARM-based Mac. And then the x86-architecture will come under severe pressure.
It'd be great if Sun had a Niagara box priced like a PC when that chip was first launched. I bet our software would be running much better on multicore machines today. Maybe languages such as Rust would have been created sooner.
I remember joking that writing code for the Xeon Phi would be useful because that was probably what a Core i15 would look like. Now we have Xeon Platinums with similar core/thread counts, but only on the very high end while 8-thread machines are mainstream with 12 being seemingly the next step.
On ARM we have something interesting with the asymmetric cores, something Intel has only hinted they plan to pursue. Some tasks can go to slower cores that sip power while others may be better suited to beefy cores that can do speculative execution on deep pipelines and that could heat a small house.
Lots of users mucked around with arm boards years ago untill most realised this wasn't something Arm was interested in with no drivers and those that existed not optimized for performance. It was all a hack with open source developers being kicked like footballs from ARM to SOC vendors and back. Interest waned.
A NUC can be had for about $120 that sips power and has full hardware support for storage, pcie, graphics and is seamlessly compatible with the entire software ecosystem.
ARM is more comfortable with vendors ie soc, routers, nas vendors than supporting an open platform with access to optimized drivers and off the shelf parts. Thus the entire mobile ecosystem is closed and tightly controlled. Even early devboard makers like Odroid have moved to an Intel platform for their latest N1 dev board.
I've come to the conclusion that neither ARM nor the actual SoC vendors are interested in desktop or server hardware. The majority have canceled their server projects or sold them off.
This is why if Apple ever did a legitimate server offering with virtualization they would kill it. How many devs, develop on Mac and deploy to linux? And also now use VMs for containers. Imagine if MacOS supported containers natively. They leave so much money on the table.
Very unlikely. "My way or the highway" is ingrained in their corporate DNA. Can't think of an attitude less suited for server side work where optimization to custom workloads makes massive cost difference
Are you arguing for native macOS containers (like Windows containers but for the Xnu kernel rather than NT kernel?) or for macOS to somehow support Linux containers (and system calls) "natively," more like BSD's Linux system call emulation and Windows' so-called "Windows Subsystem for Linux?"
For this to happen we would have to use our phones as workstations - just connect monitor and input devices. That's current mission of Rob Landley with his Toybox project ¹. Years ahead of us, but probably will happen. Makes projects like Librem 5, Pinephone and Pinebook crucial in the long run.
Vast majority of "cloud" user develop and deploy code written on languages that have "no idea" what architecture the CPU is running on. Eg, I code on Python/Django. Why would I care even a little bit about what set of instructions the CPU of my EC2 instance has? I don't. Because Python/Django will run exactly the same way on x86 and on ARM.
Sure. But that's not my point. My point is that the entire argument that Linus has about users willing to test and deploy code on the same arch is flawed. I'd understand and agree with that argument if we we're talking about developing and deploying C (which is what Linus is used to), but that's just not how "the cloud" is used.
544 comments
[ 2.8 ms ] story [ 425 ms ] threadHowever, I think that Windows on ARM will soon become a real thing, this could bring the developers, it will also help the ARM devices spread among Linux users.
Regarding what Linus wrote, I do not buy it. There is so much stuff can run without cross-compilation: js and other scripts, java, c#. Also look at things like Android and iOS, you are already happily developing for ARM, you can develop for servers with the same approach.
My ARM64 development machine is a Pinebook, ARM32 a Cubietruck. Both have only 2GB of RAM and could really do with more. At least the Cubietruck has SATA so mine has a SSD.
But, most developers don’t need to do native development.
But we are a minority.
The only devs that need to care about the native part are the ones writing the glue between runtime and hardware.
Otherwise you completely lost me there.
Windows an ARM has been a real thing for years, and it is horrible. Nobody in his right mind would use this for development.
On top of that, x86 emulation on it is now stable, including full Win32 emulation, and reports are coming in of even doing things like running Steam and old PC games on ARM devices.
What they should do is make RISC-V useful for computing at the edge - applying computation to areas where it's previously been infeasible (eg. smartwatches, wearables, RFID, drones, vehicles, etc). Developers go where the end users are. If a new end-user market opens up that suddenly needs a lot of software, developers will buy the same ISA that their customers are using. And then there will be strong pressure to run the other software that developers write (eg. servers, as Linus notes) on the same ISA to prevent cross-development.
Allowing to debug, experiment, without relying on centralized hosting providers -- would be a huge boon to Risc-V.
Early adaptors will be developers, than their family/friends circle. Then there will be Risc-V-First movement (mirroring mobile-first movement), and there it will start...
> So RISC-V CPU designers should aim for the developer market then? First win the hearts and minds of developers, then everything else will come.
[1] https://en.wikipedia.org/wiki/Apple_A12X
Sure it will take more than a few tenth of a percent of mac developers but it won't need total domination like x86 either. But just imagine if Apple really just switches its MacBook (not even the Air or Pro ones) to ARM64 that would already be millions of users. A lot of devs will at least try to compile their app for that platform for the first time. Quite some developers will be curious and get one just to test their software on it. I am pretty sure this is going to help the adoption of ARM64 way more than a slightly improved CPU or another experimental support by a cloud provider.
Personally I don't care too much about ARM64's success (although more competition would certainly be great), I am more rooting for RISC-V and I hope they follow a more developer-first strategy.
And if Apple switches pro line to arm, they’ll probably lose all non iOS/macOS developers. So, good luck to them then there.
But developers can ssh to the cloud, and develop there, right?
Regarding the VM, today I guess it would be a bit ugly through Qemu but tooling is always solved if there's a need.
They can usually run at least some part of the stack locally. Maybe not the full thing, at least part of it.
> Regarding the VM, today I guess it would be a bit ugly through Qemu but tooling is always solved if there's a need.
Tooling doesn't magically fix perf. Have you actually tried that specific setup? Searching online I get results like https://raspberrypi.stackexchange.com/a/12144 which aren't impressive, and I don't count as "reasonably performing".
Those results also jive with my experience - the meager demands of mobile apps are outrageously slow inside an ARM emulator running on x86 every time I've tried it, although I'll admit I haven't tried it on Qemu specifically. I can only imagine the horror of trying to run a full ARM server stack on x86 via emulator - perf is bad enough when it's native. For mobile, the first thing I do is fix the x86 builds (so I can use an x86 device emulator), buy a real ARM device out of my own pocket, and/or educate and/or fire my employer for their outrageously wasteful use of my time if they're serious about me and my coworkers using mobile ARM emulators on x86 for any serious length of time (that kind of waste of expensive resources like developer time can't possibly be a sustainable business decision.)
I don't feel like that's true. I don't have data to say otherwise, but my impression for the majority of non-tech businesses I encounter is that they are very much still Windows shops, and still on-prem.
To your last point, if that is true, then what will the differences be when both the OS and CPU architectures are different? I suspect it will create even more headaches.
I don't see ARM winning the server space anytime soon or ever considering how established and dominant x86 is.
When I want to test C++ stuff on ARM, I connect an android device, because that's somehow less painful.
Then why do they insist on 32GB i9 laptops running MacOS or Linux? One must assume that there is some practical purpose, unless one is rather cynical and believes that maybe the just like shinnies.
But my “experience” with native cross platform programming is two decades old - x86 and whatever the old DEC VAX and Stratus VOS platforms were running.
Secondly, it seems likely that there will be ARM MacBooks by 2020, that kind of instant market penetration for arm in the dev space might mean the exact opposite of what he's saying; why would I deploy on x86 when all of my development is on my ARM machine already?
Developers on the Apple eco-system care very little for those UNIX parts.
In the 90s you could see a shift from people having a SPARC workstation in their office for service development, to just using a x86 PC with Linux or Windows on. Then after while developing for Linux/x86 and deploying to Solaris/SPARC made little sense, so you just put it on Linux/x86 in the end. The thing is maybe 95% of things just work and you spend all your time sorting the other 5%.
Almost all iOS apps already run natively on x86 today. When developers use the iPhone simulator they are running natively compiled apps linked against an x86 version of the iOS framework. If all Apple wanted to do is allow iOS apps to run without any usability changes on Macs that would be easy (and ugly).
There are already x86 based Android devices.
I think you overestimate the significance of some Hipster Developers. And I type that on a Macbook Pro as well.
Well, that is not the exact opposite of what he's saying! He actually mentioned that. That is merely one of his points and it is true.
Linux said: "Without a development platform, ARM in the server space is never going to make it."
Want an iPod/iPhone like phenomenal opportunity?
Go all in on ARM chips and ship out MacBooks with next gen performance. Alongside, develop server grade ARM chips and make it easy for the army of devs weilding the shiny Macs to deploy straight to it. Impress with performance - you get to take the cake and eat it too.
I doubt an operation guy like Tim Cook will understand such a strategy.
It's totally happening for reals this time. Just look at .. like .. Raspberry Pi...
Linus very much sounds like a grumpy old man saying "get off of my lawn!" (as he usually does).
Plus, server space buyers are conservative, they want support of a big company behind their hardware. Someone the size of Cisco, Dell or HP. Or hardware that is used by Google or Microsoft.
Combine that with anticompetitive long term agreements and you get the picture.
Somehow network routers have a variety of architectures inside and nobody has a problem - because they have a bunch of reputable companies behind each of them. (Variants of MIPS, ARM, ARM64 and x86 are in the wild.)
I agree I will not even think of optimizing my code to run on POWER, SPARC, or ARM and that I won't care where my software runs enough to create a market for these, but I don't care enough to keep an x86 market either.
Having said that, it would be good for those who propose new architectures to ensure there is a ready supply of entry level machines for enthusiasts and early adopters. Seeding these groups will ensure their architectures and software is more thoroughly used and tested.
Games on smartphones are perfectly viable - RPi is not good enough but oDroid or Google Pixel is.
The only problem is developing on same machine as you use. For that, you need a full fledged, quite powerful ARM laptop. Hacked Chromebook for example. Otherwise, the emulator is way too slow.
https://venturebeat.com/2018/11/01/ipad-pro-a12x-benchmarks-...
You'll probably be able to run Windows 10 on a future Apple ARM-based laptop, though I imagine the problem will be getting Windows drivers for the GPU.
And you can run Linux on that Yoga. It's just Windows for ARM that is the disaster...
I'm guessing it'll be as easy to run Linux on an arm MacBook as it is to run Linux on an iPad.
https://en.wikipedia.org/wiki/Transmeta
https://preshing.com/20121019/this-is-why-they-call-it-a-wea...
https://news.ycombinator.com/item?id=4673458
Eh, Android's existence is a pretty big counterpoint to that. And you could just run an ARM VM on your desktop if it's that important to you.
>"This isn't rocket science. This isn't some made up story. This is literally what happened"
right? I mean, I can see arguing that going up into the cloud is different in some ways then going down to smartphones (although the high end ones are now going to outperform plenty of old dev machines in burst power). There are certainly differences in scaling and such. But the maturity of the tech for cross development of high level software isn't the same as it was in that era either. And if we're talking about bottom-to-top revolutions, embedded and smartphones seem to be at a lower level and much higher volume then PCs.
Finally there is clearly an upcoming disruptive fusion event coming due to wearable displays. When "mobile" and "PC" gets merged, it certainly looks like ARM is in a strongly competitive position for some big players, and having more powerful stuff up the stack will matter to them as well.
None of which is to say he won't be right at least in the short term, but it still is kind of odd to not even see it addressed at all, not even a handwave.
Exactly. Linus' point is that Arm has no real advantage in the server space to compensate for the problems with cross-development. That's completely different for smartphones, which is why Arm won that space.
(See my argument elsewhere in this thread)
I hear far more make do with just homebrew.
> unless you’re in the mood for slow emulation
I run an embedded OS (made for a quad-core ARM Cortex-A53 board) on both Real Hardware and on my ThinkPad (via systemd-nspawn & qemu-arm). I found (and confirmed via benchmarks) the latter to be much faster than the former — across all three of compute, memory, and disk access.
Not anymore, but there was a time when x86 was (barely) able to compete in that area and there were some x86-based smartphones and tablets. But it was too little too late: x86 already was a niche. Developers absolute had to support ARM, but x86 was optional, so many apps were not available for x86, and that was pretty much it for those devices.
The Macbook uses a 14nm 4.5W m3 with 1.5 billion transistors.
The iPad uses a 7nm 12W A12X with 10 billion transistors.
Turns out power usage was never an ARM vs. x86 thing, it was purely a "how fast do you want to go" thing. ARM started at the "very slow" end of the spectrum which made it a good fit for mobile initially since x86 didn't have anything on the "very slow" end of things. By being very slow it was very low power. But then the push to make ARM fast happened, and now ARM is every bit as power hungry as x86 at comparable performance levels.
The power cost is for performance. The actual instruction set is a rounding error.
You don't have much choice now sure, but it's not as if there weren't any efforts at x86 smartphones (like the ZenPhone). Nor is it as if there wasn't a long run up of phones leading to the modern smartphone either. And even in this how is not directly relevant to the case of x86?
I mean, we're directly doing a comparison to the RISC/MIPS/etc era yeah? Couldn't back then someone say "well but with PC you don't have a choice, so it's different"? x86 got heavy traction on the back of WinTel, then moved up to bigger iron, which didn't really fight hard in the lower end lower margin space. Does there really seem to be no deja vu with that vs ARM gaining heavy traction in iOS/Android/embedded then moving up to PCs and servers, where Intel/AMD didn't really play in the lower end lower margin space? There was a period with plenty of choice in servers, but then x86 won.
And again it's not as if someone can't come up with compelling arguments, x86 has some real moats even beyond pure performance. There is enormously more legacy software for x86 for example, and the ISA for it will be under legal protection for a long time to come which complicates running it on ARM. But it's hard to say how much that matters in much of the cloud space, particularly if we're imagining 5-10 years further down the line. x86 takeover didn't happen overnight either, and the first efforts were certainly haphazard. But momentum and sheer volume matter. It just seems like something that needs to be addressed at any rate, more deeply then you have and certainly more then Linus did.
Try running a Windows 95 era application on Windows 10. You can even have problems with Windows XP era stuff.
And server space in general does not do legacy without keeping everything intact. The only real issue is lack of ARM developer PCs.
The vast majority of code is delivered as either source (python, ruby, etc) or bytcode, JVM, Scalia, etc.
And the Xeon class machines folks deploy to in data center envs is a world apart from their MacBooks.
These truths are true for Linus, but not for the majority of devs.
Even those creating native binaries, this is done through ci/cd pipelines. I have worked in multi arch envs, Windows NT 4 on mips/alpha/x86, iOS, Linux on arm. The issues are overblown.
Even if your code is Java bytecode, that's still running on a different build of the JVM, on a different build of the OS (possibly a different OS). There is opportunity for different errors to crop up. They might be rare, but they'll be surprising and costly when they happen exactly because of that.
Someone else [0] points out that Java (in the right context at least) is so successful in isolating the developer from the underlying platform, that it isn't a problem if the developer isn't even permitted to know what OS/hardware their code will run on.
Could they accidentally write code that depends on some quirk of the underlying platform? I think it's not that likely. Nowhere near as likely as in C/C++, where portability is a considerable uphill battle that takes skill and attention on the part of the developer.
> They might be rare, but they'll be surprising and costly when they happen exactly because of that.
Ok, but you can say the same for routine software updates. It's a question of degree.
[0] https://news.ycombinator.com/item?id=19229224
we had those problems when developing in scripting language on windows a code that will run on linux because at some point we needed something that called native and would make us problems with different behavior. after some of that experience we tried to get everybody the same environment that is close to what will run in production.
Disclaimer: I'm a HPC system administrator in a relatively big academic supercomputer center. I also develop scientific applications to run on these clusters.
> Linus is mostly wrong except for HPC. Very few dev pipelines for folks result in native executables. The vast majority of code is delivered as either source (python, ruby, etc) or bytcode, JVM, Scalia, etc.
Scientific applications targeted for HPC environments contain the most hardcore CPU optimizations. They are compiled according to CPU architecture and the code inside is duplicated and optimized for different processor families in some cases. Python is run with PyPy with optimized C bindings, JVM is generally used in UI or some very old applications. Scala is generally used in industrial applications.
> And the Xeon class machines folks deploy to in data center envs is a world apart from their MacBooks.
No, they don't. Xeon servers generally have more memory bandwidth, and more resiliency checks (ECC, platform checks, etc.). Considering the MacBook Pro have a same-generation CPU with your Xeon server with a relatively close frequency, per core performance will be very similar. There won't be special instructions, frequency enhancing gimmicks, or different instruction latencies. If you optimize well, you can get the same server performance from your laptop. Your server will scale better, and will be much more resilient in the end, but the differences end there.
> Even those creating native binaries, this is done through ci/cd pipelines.
Cross compilation is a nice black box which can add behavioral differences to your code which you cannot test in-house. Especially if you're doing leading/cutting edge optimizations in the source code level.
the xeons though always took about 40 seconds.. but were consistent in that runtime (and were able to do more of the same runs in parallel without loosing performance)
always attributed that to the turboboost..
No. In HPC world, profiling is not always done over "timing". Instead, tools like perf are used to see CPU saturation, instruction hit/retire/miss ratios. Same for cache hits and misses. For more detailed analysis, tools like Intel Parallel Studio or its open source equivalents are used. Timings are also used, but for scaling and "feasibility" tests to test whether the runtime is acceptable for that kind of job.
OTOH, In a healthy system room environment, server's cooling system and system room temperature should keep the server's temperature stable. This means your timings shouldn't deviate too much. If lots of cores are idle, you can expect a lot of turbo boost. For higher core utilization, you should expect no turbo boost, but no throttling. If timings start to deviate too much, Intel's powertop can help.
> my experience with video generation/encoding run of about 30 sec was that my macbook outperformed the server xeons...
If the CPUs are from the same family, and speed are comparable, your servers may have turbo boost disabled.
> otherwise a testrun of 30 seconds would suddenly jump up to over a minute.
This seems like thermal throttling due to overheating.
> the xeons though always took about 40 seconds.. but were consistent in that runtime (and were able to do more of the same runs in parallel without loosing performance)
Servers' have many options for fine tuning CPU frequency response and limits. The servers may have turbo boost disabled, or if you saturate all the cores, turbo boost is also disabled due to in-package thermal budget.
If you have any more questions, I'd do my best to answer.
Optimizations that need to happen, don’t happen locally, they get tuned on a node in the cluster. Look at all the work Goto has done on Goto Blas.
What I wanted to say is, unless the code you are writing consists of interdependent threads and the minimum thread count is higher than your laptop, you can do 99% of the optimization on your laptop. On the other hand, if the job is single threaded or the threads are independent, the performance you obtain in your laptop per core is very similar to the performance you get on the server.
For BLAS stuff I use Eigen, hence I don't have experience with xBLAS and libFLAME, sorry.
From a hardware perspective, a laptop and a server is not that different. Just some different controllers and resiliency features.
This wasn't showstopping by any means, but it did take a couple of hours to tweak it until it ran properly, and this was just a small webapp not really doing anything exceptional.
Our main line-of-business app (on Java) runs on SPARC/Solaris in production, so we have on-premises test servers so we can test this... and yes, there have been quite a few instances where we identified significant performance anomalies between developer machines running x86/Windows and our Sparc/Solaris test environment, and had to go rewrite some troublesome functions.
So Linus position is a bit of straw man.
Oh, you meant that just because there is one other thing that you might slip up and forget to control for, we shouldn't bother trying to control anything? No, wait, that's actually A Very Bad Opinion.
It goes beyond the different instruction set of course and most of the time this is indeed mostly irrelevant (unless you've arrived at processor-specific optimizations), but the "develop on the same platform you are running on" still has the least painful workflow IMHO.
I wouldn't mind an ARM-based Mac though ;)
This is Jeff Atwood's argument: https://blog.codinghorror.com/the-tablet-turning-point/ ; Apple tablet performance at Javascript is now catching up to and exceeding desktop performance. Apple have also sunk a lot of money into developing their own processor line, and they have experience in force-migrating all their customers between architectures. At some point you might not be able to buy an Intel-based Apple laptop any more. Given the immense brand loyalty among web developers, they are likely to shrug and carry on .. and start demanding ARM servers with high Javascript performance.
Interestingly there's also https://stackoverflow.com/questions/50966676/why-do-arm-chip... . See also on HN front page https://www.axios.com/apple-macbook-arm-chips-ea93c38a-d40a-... "Apple's move to ARM-based Macs creates uncertainty"
(BTW the link is now slashdotted, I am using https://web.archive.org/web/20190222120214/https://www.realw... )
I won’t move to an ARM Mac, personally. I will move to Windows or Linux on x86 for all the reasons Linus gives and also for games. Sorry, but an ARM Mac may finally push me where crappy keyboards and useless anti-typist touch bars have not quite done.
NDK level programming is explicitly only allowed for scenarios where ART JIT/AOT still isn't up to the job like Vulkan/real time audio/machine learning, or to integrate C and C++ from other platforms.
In fact, with each Android release, the NDK gets further clamped down.
I would like a better NDK experience, in view of iOS and UWP capabilities, on the other hand I do understand the security point of view.
https://www.tomshardware.co.uk/sony-playstation-ps3-develope...
As long as Android allows running native code via JNI, the security concerns are void anyway. If they are really concerned about security, they would fix their development tools (just like Apple did by integrating clang ASAN and UBSAN right into the Xcode UI).
https://android-developers.googleblog.com/2016/06/improving-...
https://android-developers.googleblog.com/2017/04/fortify-in...
https://android-developers.googleblog.com/2017/08/hardening-...
https://android-developers.googleblog.com/2018/10/control-fl...
Also Google is working with ARM to adopt the new memory tagging architecture from ARMv83+ in Android.
https://llvm.org/devmtg/2018-10/slides/Serebryany-Stepanov-T...
Since this work only started on Android 7, it is clamping down the free reign that existed before.
Nothing was meaningfully "clamped down" there. You can't directly syscall some obsolete syscalls anymore, and you can't syscall random numbers, but nearly any actual real syscall is still accessible and nothing indicates that it won't be.
As long as libc can do it so can you, since you & libc are in the same security domain. Or anything else that an NDK library can do in your process, you can go poke at that syscall, too.
It'd almost always be stupid to do that instead of going through the wrappers, but you technically can
You might be confused and thinking of glibc, which is a particular libc implementation.
https://github.com/aosp-mirror/platform_bionic/blob/master/l...
This is mostly setgid/setuid, mount point and system clock related stuff. Except for syslog and chroit, I see no syscalls that you should be using in a user process anyway.
So technically, this is clamping down Android, but it seems like a pretty reasonable restriction and far from a heavy handed approach.
The problem is basically everything else:
- The ever changing build systems. And every new "improvement" is actually worse than before (I think currently it is some weird mix of cmake and Gradle, unless they changed that yet again).
- Creating a complete APK from the native DLL outside Gradle and Android Studio is arcane magic. But both Android Studio and Gradle are extremely frustrating tools to use.
- The Java / C interop requires way to much boilerplate.
- Debugging native code is still hit and miss (it's improved with using Android Studio as a standalone debugger, but still too much work to setup).
- The Android SDK only works with an outdated JDK/JRE version, if the system has the latest Java version, it spews very obscure error messages during the install process, and nothing works afterward (if it needs a specific JDK version, why doesn't it embed the right version).
The Android NDK team should have a look at the emscripten SDK, which solves a much more exotic problem than combining C and Java. Emscripten has a compiler wrapper (emcc) which is called like the command line C compiler, but creates a complete HTML+WASM+JS "program". A lot of problems with the NDK and build system could be solved if it would provide a compiler wrapper like emcc which produces a complete APK (and not just a .so file) instead of relying on some obscure magic to do that (and all the command line tools which can do this outside gradle are "technically" deprecated).
...hrmpf, and now that I recalled all the problems with Android development I'm grumpy again, thanks ;)
Tablet list: https://www.intel.com/content/www/us/en/products/devices-sys...
(and there were a lot of small brands that used to make them, that I don't believe get represented in that list)
Having said that, for it to reach >1%, it was more likely a combination of Intel Android tablets (which were fairly common for a while) and Chromebooks.
> End result: cross-development is mainly done for platforms that are so weak as to make it pointless to develop on them. Nobody does native development in the embedded space. But whenever the target is powerful enough to support native development, there's a huge pressure to do it that way, because the cross-development model is so relatively painful.
I'm not sure I agree with. My coding environment is on x86, and I build on x86, but my Run/Debug cycle is on ARM. No one is really encouraged to test on the simulator even though it's available, you are almost entirely asked to test on your actual arm device and run it and see the results of your work.
Linus is making the argument that people want their release builds to run in the same environment as their daily test builds, and I don't see smartphone development as an exception to that rule.
I don't see this happening. PCs are tools for getting real work done. Mobiles are mostly communication and entertainment devices.
I like to fall back on this Steve Jobs quote, employing a car/truck metaphor for computers:
When we were an agrarian nation, all cars were trucks, because that's what you needed on the farm. But as vehicles started to be used in the urban centers, cars got more popular … PCs are going to be like trucks. They're still going to be around, they're still going to have a lot of value, but they're going to be used by one out of X people.
Communication is also work, especially as you go up the management value chain. I think maybe people should refer to the thing that PCs do and mobiles don't as "typing".
In general, smartphone software is built to discourage creative work and focus on either reading or communicating.
Maybe an iPad Pro with its stylus could perform a lot of those mouse-driven tasks, but using the stylus for long periods of time is going to be exhausting and injury-prone. By using a mouse your arm can rest comfortably and allow you to work for long periods of time with minimal effort and no strain.
Desktop and mobile OSes should remain separate. You don't go around hauling fully loaded semi trailers with a car.
We've known about Fitz's Law since the dawn of the GUI and have decades of study on it. It's not any more efficient to need to "headshot" everything you need in an application 100% of the time, and in fact it is often rather the opposite that it gets in the way of actual efficiency.
Mousing through most "mobile" applications is great, whether "first class" or not.
Desktop and mobile OSes don't need to remain separate, and it's really past time that a lot of super-cramped "desktop apps" got the death they deserved for their decades old RSI problems, accessibility issues, and garbage UX.
It's friendly but it's not space efficient. For applications with a huge number of features, a touch UI can't handle them. Touch screens don't have right click, so you can't get context menus.
It's more than that, though. A touch screen UI for the iPhone makes zero sense on a 32" display. I'd much rather have a true multiwindow, multitasking operating system than that. Really, I wouldn't use a 32" iOS device at all. That's probably why Apple doesn't make them.
User studies from the dawn of the GUI continue to harp that user efficiency is inversely correlated to space efficiency. It doesn't matter if an application can show a million details to the individual pixel level if the user can't process a million details or even recognize individual pixels.
> Touch screens don't have right click, so you can't get context menus.
You don't need "right click" for context menus.
Touch applications have supported long-press for years as context menu. Not to mention that macOS has always been that way traditionally because Apple never liked two+ button mice.
Then there's touch applications that have explored more interesting variations of context menus such as slide gestures and something of a return to relevance of Pie Menus (which it is dumb that those never took dominance in the mouse world and probably proof again that mice are too accurate for their own good when it comes to real efficiency over easy inefficiency).
> I'd much rather have a true multiwindow, multitasking operating system
Those have never been mutually exclusive from touch friendly. It's not touch friendliness that keeps touch/mobile OSes from being "true multiwindow/multitasking", it's other factors in play such as hardware limitations and the fact that tiling window managers and "one thing at a time" are better user experiences more often than not, and iOS if anything in particular wants to be an "easy user experience" more than an OS.
(I use touch all the time on Windows in true multiwindow/multitasking scenarios. It absolutely isn't mutually exclusive.)
There’s already a whole generation or two who will likely have little to no experience with PCs.
With 2-1 and tablet docking stations, the desktop case will be fully covered.
Surface, Samsung DeX, ...
If we're trying to predict the future, I think one effective approach to try to not be trapped in the present paradigm is to try to extrapolate from foundations of physics and biology that we can count on remaining constant over the considered period. Trying to really get down to the most fundamental question of end user computing, I think it's arguable that the core is "how do we do IO between the human brain and a CPU?" With improving technology, effectively everything else ultimately falls out of the solution to creating a two-way bridge between those two systems. The primary natural information channel to the human brain is our visual system with audio as secondary and minimal use of touch, and the primary general purpose output we've found are our hands and sometimes feet, with voice now an ever more solid secondary and gestures/eye movements very niche. Short of transhumanism (direct bioelectric links say) those inputs/outputs define the limits of out information and control channels to computers, and the most defining of all is the visual input.
Up until now, the screen has defined much of the rest, and a lot of computer can be thought of "a screen, and then supporting stuff depending on the size of the screen." A really big screen is just not portable at all, so the "supporting stuff" can also be not portable which means expansive space, power, and thermal limits as well as having the screen itself able to be modularized (but even desktop AIOs can pack fairly heavy duty hardware). Human input devices can also be modularized. Get into the largest portable screen size and now the supporting gear must be attached, though it can still have its own space separate from the screen. But already the screen is defining how big that space is and we're losing modularity. That's notebooks. Going more portable then that, we immediately move to "screen with stuff on the back as thin and light as feasible" for all subsequent designs, be it tablets, smartphones, or watches. The screen directly dictates how much physical space is available and in turn how much power and how much room to dissipate heat. And that covers nearly the entire modern direct user computing market.
Wearable displays, capping out at direct retinal projection, represent a "screen" that can hit the limits of human visual acuity while also being mobile, omnipresent, and modularized. I'm really actually kind of surprised how more people don't seem to think this represents a pretty seismic change. If we literally have the exact same maximalized (no further improvements possible) visual interface device everywhere, and the supporting compute/memory/storage/networking hardware need not be integrated, how will that not result in dramatic changes? It's hard to see how "Mobile" and "PC" won't blur in that case. Yeah, entering your local LAN or sitting at your desk may seamlessly result in new access and additional power becoming available as a standalone box(es) with hundreds of watts/kilowatts becomes directly available vs the TDP that can be handled by your belt or watches or whatever form mobile support hardware takes when it no longer is constrained to "back of slab", but the interfaces don't need to necessarily change. Interfaces seem like they'll depend more on human output options then input, but that seems likely to see major changes with WDs too, because it will also no longer be stuck in integrated form factor.
WDs definitely look like they're getting into the initial steeper part of the S-curve at last. Retinal projection has...
So while Linus opinion is to be respected, mainframes, and the increase in smartphones, smartwatches and GPS devices use of bytecode distribution formats with compilation to native code at deployment time, shows another trend.
>And the only way that changes is if you end up saying "look, you can deploy more cheaply on an ARM box, and here's the development box you can do your work on".
Sure, as soon as these merge and you have a development platform as productive as a desktop computer that allows you to natively build for ARM, then absolutely, it could displace x86. And maybe when (if) the two platforms really merge that could be a real possibility.
There may be people somewhere doing Android/ChromeOS/Fuchsia development on ARM Chromebooks, following the Google model of using a mostly cloud-based toolchain together with a local IDE. There’s none of this happening inside Google itself, though, yet—but that’s just because Google issues devs Pixelbooks, and they’re x86 (for now.)
But, since Pixelbooks (and ChromeOS devices in general) just run web and Android software (plus a few system-level virtualization programs like Crouton) there’s nothing stopping them from spontaneously switching any given Chromebook to ARM in a model revision. So, as soon as there’s an ARM chip worth putting in a laptop, expect the Pixelbook to have it, and therefore expect instant adoption of “native development on ARM” by a decent chunk of Googlers. It could happen Real Soon Now (hint hint.)
This is patently false. Mobile developers do test their apps on smartphones, eventhough google and apple offer VMs. You'd be hard pressed to find a mobile app software house that doesn't have a dozen or so smartphones available to their developers to test and deploy on the real thing.
CI/CD is already too far ahead in the pipeline to be useful. CI is only a stage where you ensure that whatever you've developed will pass the tests that you already devised, but it's already a stage where you already tested and are convinced that nothing breaks.
The type of testing that Linus Torvalds referred to is much back in the pipeline. He is referring to the ability to ramp up a debugger and check if/when something is not working as expected. Developers do not want to deal with bugs that are only triggered somewhere in a CI/CD pipeline, and can't reproduce in their target machines.
Between that and the much-rumored ARM Macs, this could turn pretty quickly...
I have an Acer R13 w/ MediaTek ARM SoC. It's alright, better than the comparables with Intel N-series CPUs, but it ain't no i5.
I don't think ARM can rule with Java ( that already supports it) and Swift/c ( limited hardware)
I don't think ARM can rule with Java ( that already supports it) and Swift/c ( limited hardware).
Why couldn't ARM-based servers do the same thing? I understand why a generic ARM-based CPU might not win against a generic ARM-based x86 CPU at running cross-compiled code in Linux. But what if the server has a custom ARM-based chip that is a component of a toolchain that is optimized for that code, all the way down to the processor?
Imagine a cloud service where instead of selecting a Linux distro for your application servers, you select cloud server images based on what type of code you're running--which, behind the scenes, are handing off (all or part of) the workload to optimized silicon.
I don't have the technical chops to detail how this would work. But I think my understanding of Apple's chip success is correct: that they customize their silicon for the specific hardware and software they plan to sell. They can do that because they own the entire stack.
I think if any company is going to do that in the server space, it would have to be the big cloud owners. No one else would have the scale to afford the investment and realize the gains, and control of the full stack from hardware to software to networking. And sure, enough, that is who are embarking on custom chip projects:
https://www.thestreet.com/opinion/why-tech-giants-are-design...
So, maybe the result won't be simply "ARM beats x86," but rather "a forest of custom-purpose silicon designs collectively beat x86, and ARM helped grow the forest."
I think fundamentally, the error he's making is comparing the current market to the late 90s/early 2000s market. Back then a RISC Unix machine cost thousands of dollars. It was cost prohibitive to give one to each dev/admin. Nowadays a RISC Linux PC is $5.
The starving college kid in a Helsinki dorm working on his EE degree can't afford 600-1000 dollars for another Laptop/Desktop to experiment with. A 35 dollar ARM SBC and a monitor that doubles as his TV is right in his price range...
That doesn't invalidate his point. He's just saying that is basically what needs to happen for ARM servers to start taking off. The next step is for companies to start deploying ARM workstations. That part still seems to be a good way off, MS abandoning their Windows ARM port didn't help the cause.
35 dollars will buy you an oldish x86 beige box that will absolutely flat out murder a Raspberry Pi performance-wise. Cheap, fast hardware is not a problem anymore.
Doesn't look like this is the case now
https://blogs.windows.com/buildingapps/2018/11/15/official-s...
And speaking of x64...
> It's why x86 won. Do you really think the world has changed radically?
No, x86 is loosing to x64. And at some point another instruction set will supplant x64.
Intel tried "another instruction set" (Itanium) and nearly lost the market to AMD (AMD64)
His thesis is that if you want a platform to take off, start shipping developer boxes of the platform. So mobile and pc will merge when and only when you can do all your development on a mobile platform.
<quote>End result: cross-development is mainly done for platforms that are so weak as to make it pointless to develop on them. Nobody does native development in the embedded space. But whenever the target is powerful enough to support native development, there's a huge pressure to do it that way, because the cross-development model is so relatively painful.</quote>
I tend to agree that it will suffer. But you can get ARM chromebooks, a bunch of vendors offer ARM-based Windows laptops, and Apple is planning on leveraging their SoC on OS X computers. So it may not necessarily be cross-development for long.
Personally I think ARM could be leapfrogged by RISC-V, though it will take longer than people predict.
To be fair, I was using anything when telnet was not considered suicidal.
https://www.nextplatform.com/2019/02/05/the-era-of-general-p...
https://www.sigarch.org/simd-instructions-considered-harmful...
For the low-end deeply embedded space, I could see RISC V becoming a significant player in the next 5 years. ARM is relatively expensive there (it's cheap compared to Intel for servers, but at the low end it's more the IBM of Microsoft of old), and there's less need for their ecosystem (most 3rd party software is open source). The Cortex M are less flexible then some competitors in their configuration, and designing good small CPU IP is doable at the low end. So all the small custom designers (Andes, BA semi, Cortus...) can rally around RISC V and have cheap and flexible design, with a good shared software ecosystem. Today it's still one or the other.
At the high-end it's very different. To be competitive one has to take advantage of the latest process nodes, and work well ahead of time with fabs and EDA vendors on the next node(s). This is highly labor intensive, and it takes deep pockets and a lot of resources. ARM is already there, and well entrenched. Getting enough money to replicate this on the RISC V side will take a loooooong while, if it ever happens. Unless a deep pocketed company decides to use RISC V and go their own way, but it seems very unlikely. Look at how even Qualcomm reduced its work on custom ARM cores for their high end, and now do tweaks on ARM designs.
But personally I'm fine with this. It's mostly at the low end / embedded that I feel there's a need for more competition.
But in microcontrollers ?
To be meaningful there, they will have to convince one of the big western guys to bet on them.
But why would any of them care , enough to hurt their future relationship with ARM ,a significant risk ?
1. OS/X is Unix[tm] and linux is a "Unix clone" so the operating system works the same and (for purposes of this debate) both run on the X86 ISA.
2. The first thing all the macbook developers do is install Homebrew or equivalent and install all the same packages that are installed in their linux deployment environment.
At that point, their OS/X development environment is effectively indistinguishable from their linux deployment environment.
The first thing we install is docker and run everything containerized.
Homebrew is for tools that we actually want to run locally, like ffmpeg or python, or node...
> That's bullshit. If you develop on x86, then you're going to want to deploy on x86, because you'll be able to run what you test "at home" (and by "at home" I don't mean literally in your home, but in your work environment).
This is why having a compilation target that works the same way everywhere would be so valuable. We're some ways away from this, but I think WebAssembly offers hope here.
As for the rest of the article, it'd be best if we could have a discussion style where people don't preemptively paint people who disagree with them, or who have a different perspective, strategy, or end goal, as "idiotic" and "stupid", or posit that people have a "total disconnect to reality." This is known as poisoning the well. It does not advance the discussion. In fact it is specifically designed to limit and stop the discussion. The reality is that it simply makes people angry and polarized, amps up the stakes, and ultimately leads to a toxic culture.
Thankfully, I think HN has a better culture. Linus can do better, IMO.
Why does WebAssembly offer more hope than the JVM, or interpreted languages that we already have? It will still have to interop with native libraries to get work done.
Same can be said for jvm.
It's amazing how everyone from Steve Jobs to Bill Gates to Linus Torvalds is labeled as "toxic" and yet the "toxic" environment they created led to substantial advancements.
And poisoning the well ( or any ad hominem derivatives ) doesn't stop discussion, it generally leads to more discussions - though often times more contentious and off topic. And though I agree that it can make people angry, polarized and amp up the stakes, those aren't necessarily bad things. Most of the time, it is actually a good thing and a basis for competition.
Finally, I'd say HN has a different culture, not necessarily better. Also, what you are doing could be viewed as a form of shaming and virtue signaling. And at the end of the day, if you don't like linus's style of communication, you don't have to read or listen to it.
I don't understand the mentality of "I don't like it so you should change".
To be clear, there is a difference between toxic people and toxic behaviors. The former, I think, doesn't exist. There are people who often engage in toxic behavior, and those who do rarely. Pointing out toxic behavior is the first step to correcting it. And correcting it is in fact the goal of community guidelines, in order to establish a more inclusive culture.
> Let passionate people on all sides have their say. I think it's more toxic to stifle passionate people.
Let's be clear about what "toxic" means, and not let it degenerate to "loud and I don't like it." Toxic means that it actively damages open discussion, drives people away, and kills off conversations. It is the same sense as a toxic substance; kills.
> And poisoning the well ( or any ad hominem derivatives ) doesn't stop discussion, it generally leads to more discussions
Ok this is manifestly untrue. Please read (https://en.wikipedia.org/wiki/Poisoning_the_well). Poisoning the well is a form of preemptive insult to discourage opponents from taking a position by making it seem toxic. The fallacy is aptly named.
> what you are doing could be viewed as a form of shaming
Yep! I am happy to shame toxic behavior when it is clear.
> and virtue signaling
Maybe. I'd be happy to do it anonymously if you would prefer.
> And at the end of the day, if you don't like linus's style of communication, you don't have to read or listen to it.
This is the very definition of suppressing conversation: sending people away who don't feel like putting up with insults. It's counterproductive and unnecessary.
> I don't understand the mentality of "I don't like it so you should change".
This isn't some he-said she-said situation. I am pointing out direct unprovoked insults designed to stifle discussion and establish a particular point of view. As I have made it abundantly clear, I find this completely unnecessary and I pointed it out because I really think we can stop doing this if we're just consistent about it. We'll have better discussions with more diverse viewpoints, not just hotheads shouting at each other.
I studied philosophy in college so I don't need an explanation of what poisoning the well is. "Poisoning the well" itself is poisoning the well and I don't want to get into the intricacies of ad hominems and logical fallacies. Many times, people misunderstand logical fallacies and use logical fallacies themselves to stifle debate.
Also, Linus wasn't having an argument or a debate. He was giving his opinion. He is allowed to say someone's argument is stupid : "how stupid your argument is.". He didn't call people stupid, he called the argument stupid.
Finally, ad hominems may or may not stifle discussion from the passionless or people who don't care about the topic, but it never stifles discussion from passionate people or people who care about a topic. Every major debate - going back to religious debates or debates about science or debates about slavery or debates about civil rights or anything else was "passionate". Can you imagine these debates being shut down because that's not what "polite company discusses"?
And why would it matter whether you virtue signal anonymously or not? You are already anonymous as HN is thankfully an anonymous forum. One thing HN is fairly good about ( as far as I know ) is anonymity.
I don't believe in ad hominems or attacking people. But if people want to use harsh language to express ideas they are passionate about, I say go for it. The same goes for you. You seem passionate about the subject and I support your right to express it in whatever manner you choose. What I find ironic is that under the aegis of "inclusivity and encouraging discussion", you are advocating for exclusion and stifling Linux Torvalds' speech. But as they say, the road to hell is paved with good intentions. Certainly, you can see that you are doing precisely what you claim Torvalds is doing - stifling speech ( or at least advocating for it ).
> And the point of community guidelines isn't to make it the community more inclusive, it's actually to make it more exclusive.
Again, mixing up behaviors and people. The whole point of community guidelines is to serve the community--to include and support a wide range of people, not a wide range behaviors. Certain behaviors just flat out drive people away--that is the very definition of exclusiveness. Being "inclusive" of these toxic behaviors leads to an exclusive culture. The worst, most exclusive cultures are the ones without guidelines, full of bad behavior. Inclusiveness requires curation of behavioral guidelines. Let's not invert the sense of words when convenient for argumentation (e.g. calling community guidelines and behavioral standards "exclusiveness" because they discourage one type of bad behavior but encourage hundreds of other good ones).
> What I find ironic is that under the aegis of "inclusivity and encouraging discussion", you are advocating for exclusion and stifling Linux Torvalds' speech.
This seems to be the crux of the issue. First, it's an exaggeration to say that advocating against using insults and inflammatory language is "stifling" (see above). I actually want Linus to speak his mind--just do so without the anger channel. It's really fucking annoying to some people. Even calling ideas stupid is really fucking annoying to the people who have those ideas. But the worst part is, for every Linus there is, there are dozens, maybe hundreds of people who are going to read something like that and just silently leave. That's a sign of a bad culture. That's toxic right there. And those people who leave are the meek ones who normally wouldn't speak up because they don't want to get the firehose and spotlight pointed right at them. They don't want their ideas called stupid or idiotic or be told they aren't dealing with reality. Those kind of people that actually can be very bright and have very different (and valuable!) perspectives. The kind of people who just disappear and you never notice. And I've met plenty of people like this--if you ever people-managed, you find out hey, this or that person is leaving, and it's because they actually really didn't like being around this group. It's a loss. Most people just don't notice, but their community just got a little worse each time that happens. So you gotta find soft ways to stop it.
At any rate. Generally your comments can be construed as a defense of people that really don't need any defense. That makes it even worse when the community explicitly stands up and defends loud, obnoxious, unnecessary behavior and lionizes these "hotheads". (To be clear, I am not suggesting you are explicitly doing that, it just has that ring to it). Trust me, hotheads need no defense. They need no coddling or encouragement to keep mouthing off. Many hotheads will stick around and annihilate a community, perhaps unconsciously, because it works. They win. So don't defend them. Defending bad behavior is a death spiral, as it sends exactly the wrong message about inclusion, and that's double bad.
And I have to disagree with you about the worst communities. The worst communities are those with too much guidelines. Of course some guidelines are necessary, but mostly those involving harrassment, not speech. The US is based on the idea of less guidelines. North Korea, China, Russia, etc are based on "lots of guidelines". And the death spiral can go boths ways. Just as much to totalitarianism as it can go to anarcy.
Also, it's not an exaggeration that "insults and inflammatory language" is stifling. It's the definition of it. Anything can be considered insulting to anyone. That's why we have principled understanding of free speech. The basis of free speech is that you have the right to offend. Otherwise, you claiming that the earth is round is offensive and inflammatory to a flat earther and grounds for censorship.
You seem to think that just because I think someone should be allowed to say "an argument is stupid" is me advocating for anarchy or harrassment. I'm not. Also, "insults" aren't that insulting to everyone. Language that you find offensive isn't offensive to me. And I don't consider Linux's language to be offensive. But you do. But that's the point isn't it. Everyone has a diverse upbringing and diverse opinions.
Also I'd stay away from the term "bad behavior" because that's the same terminology the chinese government uses to crack down on its own citizens and oppress them. It's rather paternalistic and authoritarian which reminds people of the worse form of nanny states.
And last thing, why do you care how linux speaks. He is his own individual. Does he come to you and tell you how you should speak? I just find it the high of arrogance that you ( a relative nobody just like me ) has the gall to tell someone like Linux how he should speak or behave. If you don't like it, just don't read what he says. That's what I find frustrating. Why do you feel like you get to tell others how to live their lives?
At the end of the day, the people at HN can do what they want because it's their property. Regular users like you and I won't change anything. Just like we aren't going to change Linux or the platform he uses to express his opinions. I wish I could have changed your mind but I think I failed so I'll just end it here too. I just find it strange that anyone on hacker news would be demanding that linus torvalds or anyone for that matter be censored.
So things like Spanner or AWS Aurora.
Everything changes when you have huge cloud providers that have skin in the game to lower cost.
Why you see things like TPUs already. We have barely even got started with the big cloud providers creating their own chips to drive down cost.
I do hope RISC-V continues to come along. It does have the momentum right now to get there.
Linus is overestimating the amount of native code being produced.
However, there is an elephant in the room today: smartphones. ARM processors are suddenly a huge market, allowing for higher R&D expenses. And basically everyone already owns an ARM-powered device, most developers are actually developing for ARM today when they build apps.
So, and there I agree with Linus again, what is a bit missing is ARM-based desktop hardware. The best thing ARM could do to push their cloud processors would be to make affordable motherboards with their processors available to hobbyists and enthusiasts. But ARM is coming to the desktop anyway, be it through the ARM-based Windows laptops or that Apple builds an ARM-based Mac. And then the x86-architecture will come under severe pressure.
I remember joking that writing code for the Xeon Phi would be useful because that was probably what a Core i15 would look like. Now we have Xeon Platinums with similar core/thread counts, but only on the very high end while 8-thread machines are mainstream with 12 being seemingly the next step.
On ARM we have something interesting with the asymmetric cores, something Intel has only hinted they plan to pursue. Some tasks can go to slower cores that sip power while others may be better suited to beefy cores that can do speculative execution on deep pipelines and that could heat a small house.
A NUC can be had for about $120 that sips power and has full hardware support for storage, pcie, graphics and is seamlessly compatible with the entire software ecosystem.
ARM is more comfortable with vendors ie soc, routers, nas vendors than supporting an open platform with access to optimized drivers and off the shelf parts. Thus the entire mobile ecosystem is closed and tightly controlled. Even early devboard makers like Odroid have moved to an Intel platform for their latest N1 dev board.
https://www.datacenterknowledge.com/amazon/aws-launches-clou...
https://www.datacenterknowledge.com/archives/2017/03/13/arm-...
right now these are niche servers (much like the first x86 servers years ago)
¹ http://landley.net/toybox/about.html - see the Why section
He is talking about cross-development issues in ARM ecosystem. He has valid points and good suggestions.