Non-x86 Alternatives

Let's have a thread about computers that don't use the Intel x86 architecture or amd64 extensions. This thread is open to all non-x86 architectures and computers that use them. Including, but not limited to:
>SPARC
>MIPS
>Alpha
>PA-RISC
>m86k
>ARM
>Itanium
>PowerPC/POWER
>RISC-V

Why have this thread? Well, x86 chips from both AMD and Intel have become bloated at the hardware level. This isn't a RISC vs CISC shitflinging contest, but I think that anyone who knows a bit about ISAs would agree that x86 has become a very bad example of CISC. These chips are massively insecure and they're generating a lot of heat and drawing a lot of power (i9 nuclear power plant water cooler). These chips are also expensive and not delivering very good performance increases, they're closed source, and they contain hardware backdoors like the IME or PSP. AMD and Intel have the desktop market by the nuts and it's retarded. A Raspberry Pi or MIPS dev board might not replace your x86 workstation, but it's a good starting point to build upon and strengthen alternative platforms that we can possibly one day migrate to full time.

Share your experiences with non-x86 machines and what you use them for. Give a short review of your hardware and tell us all about the good and the bad parts of it.

I personally use 4x RasPi 3 B+ as a home server with 8TB of HDDs bridged over USB. I have a 5th one running NetBSD and CDE as a mini desktop. I have a few Sun SPARC shitboxes with Solaris and Linux and two SGI MIPS machines, one 300MHz O2 with 256MB RAM and one 700MHz quad CPU Tezro with 4GB RAM, both with IRIX 6.5.22. I have assorted PPC Macs, mostly G4 minis and iBooks with OS 9, Tiger, or Linux.

Attached: 212.jpg (1418x644, 85K)

Other urls found in this thread:

blog.invisiblethings.org/papers/2015/x86_harmful.pdf
j-core.org/
libreboot.org/docs/hardware/c201.html
mips.com/products/architectures/nanomips/
twitter.com/ppcinstructions
pkgmaster.devuan.org/bannedpackages.txt
twitter.com/NSFWRedditGif

I mostly stick to PowerPC, hopefully I can get a Talos II workstation some day. Until then I use a 1.67GHz Powerbook G4 every day. It runs well with Mac OS 10.5 and 2GB of DDR2 RAM. There's still plenty of software and the keyboard and palm rests are great. Obviously it isn't a smooth experience in terms of web browsing, but Leopard Webkit is a decently fast browser. Macports supports as far back as Tiger, so as long as you update bash you have access to a lot of software from there, too.
I've experimented with Debian 8 on a 1GHz iBook G4, but the results weren't great. Running awesome, the only wm that seemed to work at all, was horribly slow, and running a graphical web browser was out of the question. I tried OpenBSD, but it was a similar experience.
I have an iMac G5 sitting around. What should I do with it?

When thinking about future, picking anything else than RISC-V now would be a mistake.
The other RISC architectures will soon be of only historical value. And other than RISC, x86 will resist for a while but will eventually face deprecation.

>NON-x86 alternatives
x86

x86 a shit. A shit!!

But why?

Why would you ask something so asinine?

x86 is a liability.

Nice argument faggot. x86 works fine, sure all the backwards compatibility up to an 80386 is a pain, but other than that

>I have an iMac G5 sitting around. What should I do with it?
Can you install Tiger and run OS 9 in Classic mode or whatever that app was called? Might be a fun toy for rainy days. You can also try Debian on that machine, which will probably run really well.

As far as window managers, I wouldn't know. I didn't run many X apps on my Linux PPC machines yet, mostly just played with VTWM on them. You could always try out dwm or maybe fluxbox, since they're small and portable. If you want a lightweight and semi-modern web browser, try out NetSurf. I use that on my RasPi and really low end x86 machines as well. I don't see why it wouldn't work nicely on PPC. SpaceFM is a lightweight file manager, same with Xfe. There's also a lot of X11 apps you can try out like xosview and such for system resource monitoring.

RISC-V is nice and I like how it carries over some of the best features from other RISC platforms like MIPS and SPARC, but it's basically stuck between vaporware and overpriced dev boards right now. I'd buy it if I could get the equivalent of a Raspberry Pi 3. Needs onboard WLAN or at least Ethernet, some USB ports, GPIO, 1GB RAM, and some sort of graphics system good enough I can hook it to a monitor and use a basic window manager. It also needs to cost less than $100.

I explained it in the OP. Please read the whole thing.

Attached: 1527161698849.png (614x614, 31K)

PowerPC also works fine. I have x86 machines from that era, too, but this isn't the thread for them. So beat it.

The absolute state of x86.
blog.invisiblethings.org/papers/2015/x86_harmful.pdf

>overpriced dev boards
They are indeed overpriced. But they're the real thing: RV64GC. Prices will go down as options appear.
>vaporware
The microcontroller stuff's dirt cheap and they're making them like pancakes. Why do you think RV64GC won't follow suit? I expect some Rocket-based chips to pop up in 2019.

I'd rather not use Tiger. I have Leopard, and with that I am not forced to build the GCC for hours at a time with MacPorts. It took upwards of eight hours on my 700MHz G4 eMac, which is running Tiger and OS 9.
I was just running things from the main Debian repositories. I didn't bother trying to compile anything at the time. But it's still installed, so I'll give it a go soon. Thanks for the recommendations.

>Trust virtually non-existent towards x86 processors
No shit, but as soon as different architectures become mainstraim they'll be backdoored instantly, if not any sooner

>I explained it in the OP. Please read the whole thing.
I agree with it being bloated beyond belief, but for the trust part see

You're forgetting that these are mostly open architectures, so there will not only be far more choice of manufacturers, but it will be far easier to mitigate backdoors through software, in the case that they overwhelm the market.

Open architectures are nice, but the problem is the hardware. Finding an embedded backdoor will require reverse engineering etc and embedded backdoors are most likely not mitigable by software if developed in a sane manner.

>"x86 works fine"
>power hungry
>hotter than the core of the sun
>legacy compatibility with 16-bit shitware
>muh hyberbreading
>muh out of order exec
>muh predictive/branch exec
>muh management engine
>muh platform security processor
>muh trusted exec environment
>muh trusted platform module
Nothing but hardware bloat and security risks. There's also the UEFI problem. The average x86 users is running like 3-4 operating systems underneath Windows/Linux/OSX or whatever.

Look, I have no issue adopting RISC-V as my main desktop hardware if someone makes a nice little desktop for a few hundred dollars. But a dev board or micro controller doesn't cut it. I'm excited that there's a lot of support for this new hardware platform, but it's going to be a year or two before we see something really good.

These things don't need to become "mainstream". A Raspberry Pi is $40 and sold to tens of thousands of hipsters. Still, there's no backdoors in it like you have on x86 platforms. The reason why x86 was so heavily backdoored is that it's not just for spying on normies, but also states who are tied into the Windows ecosystem. This is why Windows is also backdoored. I worry less about a non-free driver that could be reverse engineered with some time and effort than I do about a blackbox co-processor with its own OS complete with networking stacks running at ring -3 below my fucking BIOS.

Attached: 1491992701378.jpg (957x621, 55K)

Everything But MIPS, PowerPC, RISCV, and ARM are dead :(

They aren't dead if you can find them on ebay for a reasonable price and install fairly modern software.

Attached: 1509618560050.jpg (250x223, 7K)

I already said that the legacy compatibility is absolute garbage and I in that regard, as well as UEFI.
OOE is actually a really decent invention next to superscalar processors, but implementing it is a bitch. The main problem stems from intel wanting to be "the best" and cutting corners left and right

>But a dev board or micro controller doesn't cut it.
Sure, but this should start somewhere.
Do you remember the arm SBC ecosystem before Raspberry Pi? I barely do. The prices were insane. It takes but one cheap board to break the market.

Try buying a U540 and installing Debian on it before shilling it too hard, buddy
I shilled guix for a week before trying it on aarch64
Three hours later it ended compiling in failure just trying to install hello

>Three hours later it ended compiling in failure just trying to install hello
Happens. At least the efforts at fedora and debian to bootstrap RISC-V are looking good. I've never seen an arch be bootstrapped this fast. Or so much effort put into it. Everybody wants RISC-V to be ready ASAP and it shows.

I'm looking into RISC-V a lot however I do appreciate arm and mips too. I think RISC-V should reach consumer level in 10 years although it might not be ryzen or i7 performance

>A Raspberry Pi is $40 and sold to tens of thousands of hipsters. Still, there's no backdoors in it
You sure about that? The Broadcom blob required to even boot the thing is a bit worrying if you ask me fampai.

>OOE is actually a really decent invention
>but implementing it is a bitch
Then it's not decent at all. Things that are theoretically amazing can and will turn out to be shit when applied in real life. This is why I think OOE and other extensions that follow this sort of pattern are failures. I'd love to be proven a brainlet, but I think that it'll always be bad because no one is big-brained enough to do it right.

I agree with most of what you're saying. The problem is that just like the guy above that I replied to, we have to deal in reality. RISC-V is getting there but isn't ready yet. So instead of focusing on something that's in its baby stages, why don't we look into more mature alternatives that will hold us over until RISC-V is ready? I don't see what's unreasonable about suggesting a used PPC Mac in the here and now for people who want a good x86 alternative.

I feel the same, but it's not nearly as bad has having a second CPU on your chipset that controls everything else. Reverse engineering those blobs would be easier than trying to disable the IME or PSP completely. Firmware like that can be picked apart and modified in time, unlike recent IME revisions after the switch to the 486 based core which has some of the bootloader code for the IME permanently burned into the silicon, forcing it to load into memory at power on no matter what. It used to be stored in the system BIOS EEPROM, where the IME older ARC cores would just run what they found by accessing the partition table and then running the bring up module. Things are getting worse, and a RasPi blob is nothing in comparison.

Attached: 1509739153123.jpg (753x1160, 95K)

>Then it's not decent at all.
>Heart surgery is a bitch to do right
>Heart surgery is not decent at all
>Everything has to be easy to be done right or it's not decent

Say that after you dump over $1000 into hardware and three months of weekends trying to get it to work

Yes, building a CPU is just like surgery. But I'll accept this false premise for the sake of argument and push back on it. A hospital with the best doctors and surgeons that gets millions of dollars from the patient's insurance company or from state healthcare funds can and will do heart surgery, and they'll do it well. But a company like Intel with all the fucking money on planet Earth has been doing OOE and other extensions wrong for decades, and when it's found out, they basically say "fuck you" and toss out a couple patches for year or two old platforms. And that's it! It's like a surgeon opening your chest and then sewing tubes to the wrong spots, and then throwing $35 worth of McChickens at the grieving family who lost their grandmother.

If there's this large of a financial incentive to do something right and Intel jews are still fucking it up, then who else could do it? Seems like all these technologies meant to boost speed are sloppy hackjobs which aren't stable in their underlying designs.

The heart surgery was just an example meant to highlight the level of retardation in the statement your post implied. ("Whatever is not easy to accomplish and can be a bitch to get right can't be decent")
I neither like nor endorse Intel or the way they handled the OOE fiasco, but that does not change the fundamentals of the technology.

You forgot SuperH

It's also possible to turn lead into gold, but it's so costly that you would never produce large enough quantities of gold to make that profitable or even come close to breaking even. So what's the point?

Are you retarded or just grasping on straws trying to win an online debate?
Either you can't see what I'm saying or you're just ignoring it. I don't see how the feasibility of turning lead into gold is related to OOE.

I disagree with you and I think you're wrong. I'm going to agree to disagree with you because this is pointless. How about we go back to the main topic? Let's talk about x86 alternatives and what they're useful for.

Attached: 1532187182438.jpg (1356x854, 78K)

Do you ever do anything computationally expensive? I can't imagine doing 3D rendering or encoding video on a G4 again, especially not with current codecs.

>predictive/branch exec
Are you against any predictive execution at all, user? You lose a lot of performance if you forego it completely.

I might try encoding a video on there, but I don't generally use that kind of software. I mostly stick to web browsers, terminal emulators, and IDEs.

How alive is MIPS outside of routers?

>Do you ever do anything computationally expensive?
Not him but I've tried using GIMP on a 1GHz G4 with 1GB RAM under Debian using Fluxbox. It wasn't a fun time and took an eternity to load and to even export a small PNG image. I wouldn't recommend doing anything intensive. These machines are great for people who pretty much live in the terminal and in text editors. You could try compiling something like FreeDOS and OpenGEM to use on these things but it probably wouldn't be fun, and I don't know how tied to x86 that software is.

>Are you against any predictive execution at all, user?
It depends. For the most part, yes.
>You lose a lot of performance if you forego it completely
It's not that bad unless you want to use JavaScript and other heavy modern web garbage.

JavaScript is JITed to pretty efficient native code.

The problem with JS is not so much the language (even though the syntax is uglier than homemade sin). The big problem is that most of the numales who use it in everything don't know how to use it properly or in moderation. This is how we end up with 2GB of garbage libraries in addition to 400 lines of spaghetti to print hello world. At least C is somewhat retard proof in that there's a higher barrier to entry in the form of a 90+ IQ.

Speaking of the web being terrible, I think I'll have to renew my pass this weekend. Took me like 8 buses and 20 cars to bring you this shitpost.

>>Itanium

RISC is good

debian doesn't run well even on modern hw senpai

Works fine on all of my machines. I use Devuan, which is a derivative that has systemd removed by default and has systemd and systemd dependent packages blacklisted in the otherwise fairly vanilla Debian repos. It's fast and very stable. It's really not difficult to configure a minimal install of Debian however you'd like. Also, apt ins't as bad as anyone says. I've never had it break or malfunction me, and I've been using Linux for like 4 or 5 years now. Went 100% Linux on the desktop about 2 years ago.

Devuan also has Raspberry Pi images under the embedded section on their ftp sites. Works pretty well.

Relegate the interesting stuff to the compiler. Pretty good indeed.

bump

There's nothing really wrong with it, it just wasn't the revolution Intel touted it to be. After the initial lackluster release it just became another enterprise chip not unlike POWER or SPARC with decent floating-point performance, somewhat lackluster integer performance compared to x86 and a hefty price tag.

Of course some terrible bloated crap like GIMP is going to be slow. I have no real problem running contemporary PS versions on my G4/G5 systems.

Can you get the same raw computing performance as a modern x86 chip out of any non-x86 chip on the same or lower thermal package?

I'm interested on coming ARM Snapdragon 850 based laptops with (claimed) insane 20+ hours lasting battery. But I guess it's better to wait next generation before buying one.

I too am strongly considering getting a Talos II, but I do have to say that Power doesn't exactly strike me as the nicest ISA, what with all the condition-code branching, special loop instructions, separate link register (which requires special transfer instructions) and MQ register. Of all the RISCs, it seems like the least elegant one.

Not currently. In theory, definitely. There just needs to be a market for it.

>I do appreciate arm and mips too
Don't None of those even come close to RISC-V in niceness. Alpha is pretty comparable to RISC-V in niceness, but is dead, buried and almost completely rotted away, unfortunately. Haven't tried PA-RISC, might be nice, but suffers from the same problem.

Power9 + Linux on Power

expensive but worth it

>There's nothing really wrong with it
There really is, though. It's extremely heavily optimized for in-order execution, and noone really thinks that in-order execution is a good idea anymore.

>I use Devuan
What is the point? Honest question. Is there any advantage to just apt-get purge systemd?

Repositories are more friendly about keeping systemd out.

Like what? I can't say I've noticed anything requiring systemd that I've installed. I guess some packages do require the client libraries, but that seems like a pretty small thing as long as they aren't actually being used.

I think there are some chinese laptops that use it. I only for sure know of the Lemote Yeelong.

dumb frogposter

Have you actually tried to change your init system? It's not at all trivial.

There is an open source implementation that can run on a FPGA
j-core.org/

libreboot.org/docs/hardware/c201.html
There's this Asus Chromebook you can libreboot. Also has free EC firmware unlike any x86 stuff.
downsides:
>soldered on wlan card that needs non-free blobs to work
>mali gpu that needs non-free blobs to work (for now)
>general hardware feel stuff, like no trackpoint, and a possibly disappointing keyboard

Is anything better than this right now?

it would take something absolutely monumental to displace x86 at this stage
like mass unpatchable, wormable exploitation of a hardware vulnerability (think spectre + wannacry)

the reason being it'd take recompiling everything from the past 2 decades

it's why mp3 hasn't died yet. (oddly enough, avi and mpeg-1 did die, displaced by mp4/h.264, so it's not hopeless)

Attached: 1443214308.or.99021.jpg (1280x1024, 172K)

I don't care if the normies switch over right away. To me, the current x86 situation is similar to how Flash was several years ago. Everyone else can choose to keep using it or not, but I want out as soon as possible. If I get a good non-x86 machine that I'm happy with, that's enough for me to start telling people that it's viable to leave x86 behind.

I use ARM simply because I don't want to support Amerikkka

I wasn't disagreeing. I too am looking for a safe alternative, and your analogy to flash (and java plugin) are on point. except in some cases it's not even mitigatable (intel won't patch some CPU lines)

Attached: scsi2sd-winnt.png (1024x768, 17K)

Yes, I run sysvinit on all my Debian systems. I found it no trouble at all to change. What would make it less than trivial?

>the reason being it'd take recompiling everything from the past 2 decades
x86 actually tends to be pretty easy to emulate on most RISCs since they've got a lot more registers, and if software is more than a decade old, emulation is probably faster than the hardware it originally ran on anyway.

You got me, I guess. I'm probably not knowledgable enough on this to explain it, whether or not I'd be right. I read an article that compared manually switching out the init system on Debian (I think) to replacing the majority of a bike. I don't recall where I saw it or I might just link it. Personally I see init systems as one of the main criteria for choosing a distro, as I think of them as messy and difficult to change out. Previously I had thought little of derivatives, as they're not really necessary and you can just install whatever packages and environment you want. I feel like init systems are an exception to this, but I guess I don't have much to go on besides gut feeling.

I will say I would've chosen one of the modern alternatives rather than going back to sysvinit. I don't know if that makes a difference in the difficulty or not.

I mean, I don't necessarily object to using Devuan if only to make a statement that I don't want to use systemd. If enough people do, then maybe the Debian committee takes note and does something, which would be nice. Then again, I already have Debian everywhere else and uniformity is nice.
In practice, I don't even have to "change" init systems, since I usually debootstrap new installations manually from a live USB anyway and therefore can install sysvinit the first thing I do without having to go the way over systemd. But even on systems where I've used the installer, I haven't found there to be anything more to it than just installing sysvinit and purging systemd, quite simply.

>I will say I would've chosen one of the modern alternatives rather than going back to sysvinit.
I just haven't found any faults with sysvinit. I hardly even get why anyone would even object to it in the first place.

OpenRISC
LowRISC
RISC-V
Power9
LEON - (superSPARC based lgpl/gpl dual license)
S1 Core (ultraSPARC based GPL license)
NanoMIPS is a new ISA

mips.com/products/architectures/nanomips/

We are going strong boys!

>Power doesn't exactly strike me as the nicest ISA
twitter.com/ppcinstructions

Well, for one, they actively block systemd libraries and packages: pkgmaster.devuan.org/bannedpackages.txt
The other difference is that they do offer different init systems than just sysvinit. I think you should just poke around their website if you really want to know what they're all about.

Would be more funny if it didn't ring so true.

Huh, cool. I figured they would stop shipping init scripts now that systemd is the only supported init system, but I guess that hasn't happened yet.

>I think you should just poke around their website if you really want to know what they're all about.
I have, but yet haven't really found anything but "don't use systemd", which is a good point but seems to be perfectly possible on Debian as well. Which is why I wanted to hear from someone who actually uses it in practice about the reason for doing so.
>The other difference is that they do offer different init systems than just sysvinit.
So does Debian, though. Perhaps not all the alternatives that Devuan has, but it includes at least Runit and OpenRC.

>now that systemd is the only supported init system
That's not true, though. It's just the default init system, not the only. Debian does support others, including sysvinit and openrc.

RISC CPUs and boards are nice, but I'd love to see a fully open, human assembly programmer-friendly CISC board. Imagine a RasPi-thing with GPIO and everything, but with a 68000-compatible CPU and running NetBSD. It would be a fine educational product, at least.

Attached: motorola-68000.jpg (1427x813, 888K)

>Ctrl+F "ForwardCom"
>no results
You sadden me.

but everything that isnt x86 is slow and shit

I'm waiting for them to release SH4. Apparently, despite the dead mailing list they're working on it.

maybe if someone could convince Microsoft to jump ship

iirc they made Windows NT cross-platform compatible because they wanted it to run on workstation-class and server hardware (in the days when the 486 was a feeble desktop CPU)
when Intel starting taking large chunks out of the server market with its cheap, mass-produced processors, Microsoft pulled the plug on the other architectures

they tried to get in ARM with Windows RT, but that didn't go well

if anyone (once) had a bigger voice than Intel it's Microsoft

Attached: Oe-Ie5-unix.jpg (353x282, 22K)

Don't think "displace", think "fragment". I don't want a RISC-V monoculture, although it would be better than an AMD64 monoculture. Even if most desktops and half of the servers stay AMD64 for decades to come, there can be openness, experimentation and competition in the remaining part of these markets. In phones, tablets, routers and Wi-Fi-enabled MCUs alternative architectures (neither ARMv8 nor AMD64) stand an even better chance.

What would even be good about that? ARM assembly isn't difficult at all.

iirc they also once wrote Windows Media Player for Solaris 6.3, although I don't think it could play anything other than wmv or asf.

Attached: IE5_for_UNIX.gif (489x431, 42K)

>they tried to get in ARM with Windows RT, but that didn't go well
They're actively working to fix that, and Intel are obviously scared.

kek

>I don't want a RISC-V monoculture
I used to think this too, but I've come to realize that all these different ISA really just do the same thing in the end anyway. It would be one thing with a heterogeneous culture of radically different designs, like the iAPX 432, or the Burroughs B5000, or some kind of dataflow architecture, but all these so-called "different" ISA are pretty much the exact same thing (coupling an ALU to a directly-addressed memory unit through a PMMU), they just express the exact same operations in slightly different ways. As long as that is so, we might as well have a standard for it, and RISC-V is a really good standard for that.

NT's portability is an ICBM pointed at Intel in case it does something funny. Microsoft is never giving it up and will occasionally create hype around it regardless of whether they think it's financially viable to switch architectures.

I mean, apart from relatively minor details, all these ISAs are almost completely isomorphic to each other.