[sliverstorm]

If you have the design, and you have access to FPGAs, I'd say that's got you pretty close already.

Edit: We were talking about CPUs, not complete systems. And yes, the performance would be poor, but RMS has already strongly established that in his book performance is a distant runner-up to free.

[detaro]

Assuming you have an open FPGA toolchain (which AFAIK exists for like a year or so), open FPGA designs supported by that toolchain (AFAIK doesn't exist yet). Even if you don't insist of the FPGAs design being open (which is a rather arbitrary border then), you'll have a hard time getting something with performance people actually want to use in the supported chips. It's a nice dream, but not practical right now.

[jimktrains2]

By pretty close you mean no where near a usable system then you'd be correct. If you're not a hardware person, as I'm not, I don't think I could go from blank fpga and parts to a working laptop with a keyboard, trackpoint, and lcd screen in any reasonable amount of time, nor with any certainty that it would work and not be error-prone.

[sklogic]

Order Oberon Station, copy-paste a couple of lines of instructions to flash a bitfile, and enjoy a nearly fully open environment.

A bit more tricky with or1200, but this way you'll get a fully functional Linux workstation.

[duskwuff]

On the other hand, it's very difficult to build a design for an FPGA using only free software. (Until very recently, it was outright impossible; now, it's merely very difficult, and requires that you use certain very specific FPGAs.)

[BrainInAJar]

>By pretty close you mean no where near a usable system then you'd be correct. If you're not a hardware person, as I'm not, I don't think I could go from blank fpga and parts to a working laptop with a keyboard, trackpoint, and lcd screen in any reasonable amount of time, nor with any certainty that it would work and not be error-prone.

The exact same argument can be made about the operating system.

[lmm]

I can and have patched bugs in my operating system.

I have no clue where I'd even start to patch a bug in my hardware.

[jacquesm]

If you're lucky it's off-chip and your soldering iron and a very sharp knife will come in handy.

The problem with 'patching' hardware these days (oh, I'm that old) is that most of the time you'll find your problem is located inside a chip, and it isn't the traces are in planes that you can't access (if you're lucky they might run in a spot where you can dremel through and then cut and solder two small wires to the buried trace). Via's don't help either (especially not in layers that start and end under BGAs).

Patching hardware was never easy, but with todays degree of integration of components and SOCs it is harder than ever and frequently downright impossible.

Lots of things have gotten easier since the hole-through era, but hardware fixes aren't one of those.

[lmm]

I guess the counterpoint is that there are things you can now fix in microcode that would have previously required messing with the hardware?

[jacquesm]

That depends. Microcode tends to be used in CPUs rather than regular ASICs and not all CPUs have re-writable microcode (though quite a few of them do). So unless you're talking about a CPU the answer is probably 'no'.

You probably have a bigger chance that there is an FPGA on board that you can re-load.

[BrainInAJar]

I've "patched" my CPU (using a pencil to close some leads on an old AMD cpu to enable overclocking) and I've "patched" a motherboard (replacing a blown capacitor). But that was analogous to patching bugs in your closed source software with a hex editor.

[umanwizard]

Eh, IDK about that. It's pretty well-understood how to make a simple but usable OS kernel. I think most competent programmers would be able to do it (or at least know where to start) given enough free time.

[na85]

>RMS has already strongly established that in his book performance is a distant runner-up to free.

To him, maybe. Not all of us have the luxury of getting paid to be a techno-luddite, using antiquated workflows and having the spare time available to re/write drivers when necessary.

If I made the same performance/freedom trade-offs I'd be completely unable to do my job.

[Spivak]

The fact that you consider performance and freedom to be a trade off means that you've already given up even the slightest hope of freedom. You as a developer and a user should want the freedoms afforded to you by the GPL or any copyleft license for that matter. In the ideal world your high performance software would be released under the GPL you would have the best of both worlds. The war won't be won by rewriting every single tool and releasing it under the GPL, it will be won by pressuring existing companies to license their software under the GPL.

The people who want non-copyleft licenses to succeed are those who which to make a profit from the control and ignorance they can impose on their users by closing their source and platform or those who are willing to trade their user's freedoms to appease them.

Businesses have a huge amount of leverage on the OSS software ecosystem and so it's really no surprise that the licensing choices are to benefit the businesses funding the development rather than the users. It's to be expected but no less sad. There's a small group of passionate people who have basically dedicated their lives to making the world a better place by writing software that's truly free and respects its users, they built an entire community and movement around the idea, and actually stand by their beliefs -- yet people dismiss them because the company worth hundreds of billions of dollars has a better UX.

[na85]

>The fact that you consider performance and freedom to be a trade off means that you've already given up even the slightest hope of freedom.

True, mostly thanks to shitty companies like Apple, Microsoft, Autodesk, etc.

>You as a developer and a user should want the freedoms afforded to you by the GPL or any copyleft license for that matter.

I do.

>In the ideal world your high performance software would be released under the GPL you would have the best of both worlds.

We don't live in an ideal world and never will.

>The war won't be won by rewriting every single tool and releasing it under the GPL, it will be won by pressuring existing companies to license their software under the GPL.

This doesn't work, especially in software for engineering where there are often sole, hegemonic powers and established monopolies and where the cost to enter the market as a new competitor is non-trivial. We're not talking a desktop manager or a text editor here, we're talking millions of dollars of R&D for things like CFD suites. Open alternatives exist (like, say, OpenFOAM) but they often lack accreditation/certification/rigorous testing and when you're dealing with people's lives the choice is often proscribed entirely.

>The people who want non-copyleft licenses to succeed are those who which to make a profit from the control and ignorance they can impose on their users by closing their source and platform or those who are willing to trade their user's freedoms to appease them.

There's a financial incentive to creating walled gardens and proprietary software that you can charge for.

>yet people dismiss them because the company worth hundreds of billions of dollars has a better UX.

When the choice is between "being able to function at my job, at all" and "use free software", well, the choice is clear.

[s73v3r]

Better UX is definitely part of making the world a better place. Maybe the free software people should invest in UX as well.