SoylentNews is people
SoylentNews
Is it time For open processors? Jonathan Corbet over at lwn.net seems to think so. He lists several ongoing initiatives such as OpenPOWER, OpenSPARC and OpenRISC, but feels that most of the momentum is in the RISC-V architecture right now.
Given the complexity of modern CPUs and the fierceness of the market in which they are sold, it might be surprising to think that they could be developed in an open manner. But there are serious initiatives working in this area; the idea of an open CPU design is not pure fantasy.
[...] Much of the momentum these days, instead, appears to be associated with the RISC-V architecture. This project is primarily focused on the instruction-set architecture (ISA), rather than on specific implementations, but free hardware designs do exist. Western Digital recently announced that it will be using RISC-V processors in its storage products, a decision that could lead to the shipment of RISC-V by the billion. There is a development kit available for those who would like to play with this processor and a number of designs for cores are available.
Unlike OpenRISC, RISC-V is intended to be applicable to a wide range of use cases. The simple RISC architecture should be relatively easy to make fast, it is hoped. Meanwhile, for low-end applications, there is a compressed instruction-stream format intended to reduce both memory and energy needs. The ISA is designed with the ability for specific implementations to add extensions, making experimentation easier and facilitating the addition of hardware acceleration techniques.
[...] RISC-V seems to have quite a bit of commercial support behind it — the RISC-V Foundation has a long list of members. It seems likely that this architecture will continue to progress for some time.
(Score: 3, Insightful) by DannyB on Tuesday January 23 2018, @11:00PM (10 children)
The first level of compatibility is to provide compilers for your new chip.
Then there is the fact that an OS kernel must be ported -- you can't just magically compile it even having a compiler for your chip.
Once you have the kernel, if user space software can be simply recompiled and run on your new processor -- then you've really got something!
The lower I set my standards the more accomplishments I have.
(Score: 2) by fyngyrz on Tuesday January 23 2018, @11:13PM (9 children)
Well, what you have are compilers.
You still haven't solved the problem of all the apps I have that are no longer being supported, devs and/or companies long gone, etc.
Remember when Apple went from PPC to Intel? They built a wholly transparent PPC emulation right into the OS, and thereby leveraged the current users from Processor A to Processor B, because all those PPC apps "just worked."
Of course, then they roundly butt-screwed all those app users a few years later sans lube or reach-around by dropping the emulation, but they got away with it because it was otherwise too late — people had already moved. It was slimy as hell of them to do, but it worked.
In any case, compilers don't solve the past-compatability problem. They enable future app generation. Which will have a great deal of trouble taking off, because no one will move until that phase is well under way, unless they can just jump right in with their current app and document collection.
(Score: 0) by Anonymous Coward on Tuesday January 23 2018, @11:32PM (4 children)
The alternative is to wait until the hammer comes down on "hacker tools." Probably one will be able to install RHEL and Ubuntu, but forget being able to compile one's own kernel. Forget about even having access to a full compiler without paying some hefty fees to the likes of Red Hat or Microsoft. Sure, hello world will probably still compile with the "community edition" of Visual C++ or Clang.
All this out of misogynerd narrative and OMG Russia. I think the other pieces don't directly affect this part, but I wouldn't be surprised if OMG trolls or OMG dank alt-right memes plays some part. It's the only way they can make sure that throwing away net neutrality gives ISPs a stranglehold on information, only allowing access to approved propaganda outlets. Well, there will probably still be the option of coughing up big bucks to be able to connect to unapproved subnets.
But who the hell has big bucks other than Inner Party members? I hear they can even switch off their telescreens!
But OTOH given the funding concerns stated upthread for open hardware, maybe that's checkmate. A boot stamping on a human face forever.
(Score: 2) by fyngyrz on Tuesday January 23 2018, @11:49PM (3 children)
I read what you wrote, yet I see no alternative.
Either my apps work, or you have nothing at all to offer me.
Look, I'm a developer. I have Windows, linux and OS X machines running here, and I have to keep them all running for various reasons. But I only use one OS for 99% of what I do. Because apps. I'm completely serious: you have nothing to offer me with an alternative / incompatible OS, and that's without even bringing a new processor into the mix.
Grandma will be even more unwilling to consider abandoning the things she knows how to use, as will office slaves Obadiah, Myrtle, and... Bob... who have all their working hours into their custom vertical applications. Then there are the gamers. Your New Hotness won't run their copy of Star Sluts XIII at 240 FPS across four monitors? Piss off, busy wearing out my... joystick... over here.
(Score: 0) by Anonymous Coward on Wednesday January 24 2018, @12:46AM
I definitely hear what you're saying.
It's depressing.
(Score: 4, Informative) by requerdanos on Wednesday January 24 2018, @01:19AM
I can guess from this that you would be likely to choose "only Windows" if you could have only one of these operating systems. Because, you know, apps.
But that's a thing in the culture and the habits and the institutions of the greater Windows environment, which is by far the dominant one.
There are people--fewer in number--who would choose a unixlike OS, and a free one at that, if given the same only-one-OS choice.
And those people have habits and a culture and institutions that mean that for them, a new architecture, a new processor, means *shrug* port and recompile everything, because the source is available for pretty much anything they would want to run. For those difficult-to-port apps, a slightly more inconvenient process of forming a porting team and solving the problems (or waiting for those who do that, to do that).
The nice thing is that those open-unixy-compile-things people are the initial pilgrims on the shores of new architectures, and are the ones that will build infrastructure for the larger "I need my apps to just work" crowd.
It will take a long, long time for mainstream culture to come around to preferring free software, which confers the benefits I've mentioned and others. Fortunately that's not the culture it needs to catch on with first.
She, if she's an average unsophisticated user, will run what you give her, and settle into whichever culture you place her. She isn't in that pilgrim vanguard, no, but then neither are you, and you're a developer!
I am not a developer unless you charitably count complex scripts and websites, but I do have several ARM boards doing real work and I'd welcome the chance to start recompiling things on a free and open processor.
(Score: 0) by Anonymous Coward on Wednesday January 24 2018, @07:32PM
mass consumer adoption is not a requirement for this to be a worthwhile initiative. most people don't use gnu/linux either. yet i somehow use it every day. if we could get open hardware to where people had the option, that would be good enough for me.
(Score: 4, Insightful) by Arik on Tuesday January 23 2018, @11:51PM (1 child)
(Those programs aren't really software since you don't have usable source.)
If laughter is the best medicine, who are the best doctors?
(Score: 0) by Anonymous Coward on Wednesday January 24 2018, @03:33PM
I remember when Oracle became available on linux. A reporter found the guy who did the work and asked him if he had any problems with porting the software to that OS. He said: "What port? All I did was run make."
(Score: 2) by TheRaven on Wednesday January 24 2018, @10:25AM
This depends a lot on the ecosystem. Most Mac apps are proprietary and may depend on libraries that are not source-available, licensed from third parties. Getting everyone to recompile their code was a pain.
A lot of Windows apps, in contrast, are shipped as .NET bytecodes, so you can change architecture by porting the CLR JIT. Unfortunately, a lot of the popular ones are still shipped as x86 binaries, so you'd need an emulator.
Most Android apps are distributed as Dalvik bytecode, though a lot include native libraries. The libraries communicate with the rest of the system via a fairly well-defined interface (including talking to system libraries), so it's possible to emulate only this code and run the rest natively.
Most *NIX apps are distributed as source code that's been tested on at least a couple of architectures, so once you have the relevant toolchain working you just need to port them. Once we have a working toolchain for AArch64, for example, it was pretty easy for us to get about 90% of the packages that are available for FreeBSD/x86-64 for FreeBSD/AArch64.
Most iOS apps are now provided to Apple as LLVM IR and distributed via the app store. It would be entirely feasible for them to add a new LLVM back end and ship almost all existing apps for it.
sudo mod me up
(Score: 3, Interesting) by DannyB on Wednesday January 24 2018, @02:18PM
What you have at that point is something like Raspberry Pi. It's a different chip. In order to get it to work someone had to build compiler back ends that target that chip. Then the kernel had to be ported to that chip. But there are tens of thousands of packages now available for Linux on Pi. The only way that even seems plausible is that it took something between zero and very little effort to port each package to the new chip -- and I suspect in most cases, simply a recompile. The apps, in general, don't address hardware. They use the C library (and others) and possibly kernel calls, which are presumably portable across architectures. I strongly suspect most of the kernel calls are only performed through standard libraries.
The beauty of that is that once you port a compiler and then the kernel using that compiler, you get the gigantic ecosystem for very little additional cost. (Please correct if this is an untrue characterization of the situation. I would be interested to know.)
The lower I set my standards the more accomplishments I have.