Live data from Hacker News

Freedom and security issues on x86 platforms

mail.fsfeurope.org

161–170 of 282 posts

Re: Freedom and security issues on x86 platforms

#161

Earlier quoted context omitted.

> I'll take 6watts consumption in a router in exchange for quad-core, IOMMU-enabled, fault-tolerant, open CPU. The router vendor surely looks at the cost of the CPU - ARM and MIPS cores are probably much cheaper.

Remember, I mentioned the SOC vendors as well. They currently license MIPS and ARM. Many choose MIPS due to cheap license. ARM's license, royalties, and restrictions are ridiculously expensive. SPARC has a cost advantage over it. So, once again, it's neither energy nor costs that are reasons they chose MIPS and ARM over SPARC. Keep guessing.

I'm not so sure: Because currently ARM processors are currently sold in a large volume (if not for a technical reason then by momentum) they can be made a cheaper by economy of scale. This does not mean that this has to stay in the future, but currently this seems to be the case.

Re: Freedom and security issues on x86 platforms

#162
post #136

Earlier quoted context omitted.

Red Hat has supported POWER for a long time. Debian does. Even Mint had a PPC release. The big BSD's do. Amiga's are still on PPC haha. I think it's not a question of FOSS support by OS developers. It's the users and app that don't commit to x86 alternatives.

One issue with PPC and POWER is that they're generally big-endian and everything assumes little-endian these days thanks to x86. Even JavaScript is little-endian now.

According to the specs linked in the OP that POWER8 supports little-endian mode too.

Re: Freedom and security issues on x86 platforms

#163

Earlier quoted context omitted.

There are even more implementations than the ones you mentioned. http://temlib.org/site/?page_id=14 and then http://apple-core.info/outcomes.html , schematic overview http://www.date-conference.com/files/file/date11/ubooth/157.... , necessary toolchain http://sp.utia.cz/index.php?ids=results&id=applecore . Apart from that, i'm thinking something like OpenFirmware should be mandatory for every Vendor, because without…

Those are pretty neat. Didn't know about the Apple many-core. Far as OpenFirmware, I think it should be mandatory along the lines of something like First Sale doctrine. If we bought a device, we should be able to control its use by law. We can't do that with software due to copyright. That implies an open, mandatory firmware available that lets us load our own software in.

I knew you'd like that. The temlib is impressive because of its completeness, though it seems like hobbyist thing, maybe useful for retrocomputing and software archaelogy ;) But this comment http://temlib.org/site/?p=567#comment-210 makes me realize that the design doesn't even fully utilize the almost EOLd Spartan-6 (a low end one, even in its heyday). Now imagine what could be done in something new? Combined with the Utleon3 implementation of the Microgrid concept from http://svp-home.org On something like this f.e. http://www.achronix.com/products.html ? AFAIUI this would smell like Soft Machines VISC, only better, because FREE!

PS: two more pdfs for you to digest wrt Soft Machines VISC http://dist.svp-home.org/doc/foundations-and-achievements-of...

http://dist.svp-home.org/doc/operating-systems-for-many-core...

Re: Freedom and security issues on x86 platforms

#164
post #89

Earlier quoted context omitted.

As far as I know, Oracle has not made any SPARC intellectual property available since the acquisition of Sun. The T1 and T2 lines were emphatically Sun-era products.

So if API's are copyright-able. And SPARC T1/T2 are GPL CopyLeft. Shouldn't Oracle have to open source T3/T4/T5/M7 processors also? (No I don't have the money required to sue Oracle and keep this suit open for the 2 decades settlement will take).

If all of the copyright holders agreed, I think they they could relicense under any licence. This would be especially straightforward for any revision for which Oracle is the sole copyright holder.

Re: Freedom and security issues on x86 platforms

#165
post #89

Earlier quoted context omitted.

As far as I know, Oracle has not made any SPARC intellectual property available since the acquisition of Sun. The T1 and T2 lines were emphatically Sun-era products.

So if API's are copyright-able. And SPARC T1/T2 are GPL CopyLeft. Shouldn't Oracle have to open source T3/T4/T5/M7 processors also? (No I don't have the money required to sue Oracle and keep this suit open for the 2 decades settlement will take).

No, that's not how open-source licensing usually works.

Assuming Oracle own all the IP rights (having purchased them from Sun), they aren't bound by the terms of the GPL. The GPL grants certain permissions to others if they comply with its terms, but the person who offers the license doesn't lose any rights they already have. They have no obligation to keep successive generations of derivative products open source.

Re: Freedom and security issues on x86 platforms

#166
post #136

Earlier quoted context omitted.

One issue with PPC and POWER is that they're generally big-endian and everything assumes little-endian these days thanks to x86. Even JavaScript is little-endian now.

According to the specs linked in the OP that POWER8 supports little-endian mode too.

And most PPC distributions are building for little-endian mode as well. OpenSUSE Leap is only available for ppc64le, Fedora only builds for ppc64le now as well.

Re: Freedom and security issues on x86 platforms

#167
post #155

Unbelievable. Yet again, we have a post on finding x86 alternative that's most FOSS friendly. Yet again, the author is unaware of or ignores the only architecture that's open, has GPL cores, and an ecosystem. That's SPARC. Oracle's T1 and T2 cores are open-source to study. More appropriately, Cobham-Gaisler's Leon3 HW is dual-licensed under GPL and commercial. The Leon4 is 4-cores. SPARC ISA is open. Open Firmware ex…

"Oracle's T1 and T2 cores are open-source to study." If you had to pick a Oracle (Sun?) T2 based system to purchase off of ebay, with the interest in using it as a "more free, more open" system, what would you buy ? What OS would you run on it ?

I wouldn't. I'd use Gaisler's immediately because it's fully open and already FPGA qualified. I'd then buy a good FPGA board. Then I'd run it on there. It would probably run like a multi-core version of my old Pentium II. Yet, I programmed, hacked, gamed, and so on with it. Later, I'd put it on an eASIC Nextreme or actual ASIC if money came in for better performance, power, and unit pricing.

Re: Freedom and security issues on x86 platforms

#168
post #61

And it's getting worse, SGX[1] allows 3rd party encrypted binary blobs to run on your CPU without being inspectable. It's sold as way to protect your secrets from malware. But it more likely will be used to run DRM code on the user's computer while treating the user as a hostile entity. [1] https://software.intel.com/en-us/sgx

SGX is a major point and one I thought the linked post would deal with from its title.

For a user-owner point of view, I agree with your assessment of SGX. I imagine that, once it becomes used for things like media DRM and games copy protection, users will start turning it off in their BIOS, or managing the signing key whitelist manually. And I wouldn't blame them.

But from a user-not-owner point of view (ie, cloud computing), SGX offers the user more security, and a degree of protection against some cloud computing risks.

Re: Freedom and security issues on x86 platforms

#169

Earlier quoted context omitted.

Aside from the stale Mac Pro, which current Macs do you think are indicative of Apple giving up on performance?

The new macbook 12" is thinner and lighter than the older MBA, but without significant performance improvements.

The macbooks were never supposed to be a "power" machine. The whole purpose was a very portable, long batter life laptop. And it dose that very very well.

I would not call that giving up on performance...they just designed something for a purpose and it fits that purpose well.

Re: Freedom and security issues on x86 platforms

#170
post #60

ARM architectures also suffer from this. You'll be hard pressed to find a board that doesn't require a propriety board support package somewhere in the stack. Ironically, it is usually the bootloader that is/requires a blob or it is the DTB. I remember being in middle school and reading Stallman's articles on the dangers of a TPM-oriented push by manufacturers. As cliche as it is, Stallman was right. The push for pla…

My dtb is generated from a dts at kernel compile time... Chromebook land is fun.

Lucky. I have to hunt around for DTBs based on modified Rockchip and Freescale SoCs to update my devices.

I am unwilling to distribute said binaries to make it easier for people with the same hardware as I to update their 3 year old software. That, too, is a shame.

Post reply on HN