An anonymous reader writes: Following last week's announcement of the Jetson TX1 development board, NVIDIA is now allowing independent reports of performance for their $599 USD 64-bit ARM development board. Linux results published by Phoronix show very strong performance for the Jetson TX1 when looking at the Cortex-A57 speed relative to the Tegra K1 and older Tegra SoCs along with other ARM hardware like Calxeda and Raspberry Pi. The Jetson TX1 was generally multiple times faster than ARM hardware a few years old. The graphics performance was twice as fast as the year-old Jetson TK1 thanks to the Maxwell GPU. Compared to x86 hardware, in CPU-bound tasks the performance is comparable to an AMD Sempron/Phenom except when utilizing GPGPU computing where it's then faster than Intel Skylake and Xeon processors. The Jetson TX1 had a peak power consumption of 16 Watts and an average power use of under 10 Watts.
Slashdot Deals: Cyber Monday Sale! Courses ranging from coding to project management - all eLearning deals 25% off with coupon code "CYBERMONDAY25". ×
An anonymous reader writes: Dhewm3, one of the leading implementations of the Doom 3 engine built off the open-source id Tech 4 engine, has released a new version of the GPL-licensed engine that takes Doom 3 far beyond where it was left off by id Software. The newest code has full SDL support, OpenAL + OpenAL EFX for audio, 64-bit x86/ARM support, better support for widescreen resolutions, and CMake build system support on Linux/Windows/OSX/FreeBSD. This new open-source code can be downloaded from Dhewm3 on GitHub but continues to depend upon the retail Doom 3 game assets.
An anonymous reader writes: For the better part of three years there has been talk about running Wine on Android to bring Windows x86 programs to Android phones/tablets, and it's going to become a reality. CodeWeavers is planning to release CrossOver For Android before the end of the year. This will allow native Windows binaries to run on Android, but will be limited to Android-x86 due to struggles in emulating x86 Windows code on ARM. The tech preview will be free and once published the open-source patches will be published for Wine.
MojoKid writes: The ASUS ZenPad S 8.0 is a well-designed Android tablet based on an Intel X86 platform that boasts better specs than the iPad mini 3 in many areas and is also less expensive. As configured, the ZenPad S 8.0 Z580CA has an MSRP of $299, which is $99 less than the 16GB iPad mini 3, and $199 less than 64GB model. However, it's based on a quad-core Intel Atom Z3580 processor, 4GB of RAM, 64GB of internal storage, and modern amenities like 802.11ac Wi-Fi, a USB Type-C port and a 2048X1536 IPS display. A 2GB RAM and 32GB variant can be found for $199 as well. In the benchmarks, the ZenPad S 8.0 handles pretty well, offering middle-of-the-pack performance in both standard CPU tests as well as gaming, in addition to running the latest version of Android Lollipop.
An anonymous reader writes: The Linux 4.2 kernel is now available. This kernel is one of the biggest kernel releases in recent times and introduces rewrites of some of the kernel's Intel Assembly x86 code, new ARM board support, Jitter RNG improvements, queue spinlocks, the new AMDGPU kernel driver, NCQ TRIM handling, F2FS per-file encryption, and many other changes to benefit most Linux users.
jfruh writes: Security researcher Christopher Domas has demonstrated a method of installing a rootkit in a PC's firmware that exploits a feature built into every x86 chip manufactured since 1997. The rootkit infects the processor's System Management Mode, and could be used to wipe the UEFI or even to re-infect the OS after a clean install. Protection features like Secure Boot wouldnt help, because they too rely on the SMM to be secure.
An anonymous reader writes: In past years the AMD Catalyst Linux driver has yielded better performance if naming the executable "doom3.x86" or "compiz" (among other choices), but these days this application profile concept is made more absurd with more games coming to Linux but AMD not maintaining well their Linux application profile database. The latest example is by getting ~40% better performance by renaming Counter-Strike: Global Offensive on Linux. If renaming the "csgo_linux" binary to "hl2_linux" for Half-Life 2 within Steam, the frame-rates suddenly increase across the board, this is with the latest Catalyst 15.7 Linux driver while CS:GO has been on Linux for nearly one year. Should driver developers re-evaluate their optimization practices for Linux?
itwbennett writes: Steve Casselman at Seeking Alpha was among the first to suggest that Xilinx should buy AMD because, among other reasons, it 'would let Xilinx get in on the x86 + FPGA fabric tsunami.' The trouble with this, however, is that 'AMD's server position is minuscule.... While x86 has 73% of the server market, Intel owns virtually all of it,' writes Andy Patrizio. At the same time, 'once Intel is in possession of the Altera product line, it will be able to cheaply produce the chip and drop the price, drastically undercutting Xilinx,' says Patrizio. And, he adds, buying AMD wouldn't give Xilinx the same sort of advantage 'since AMD is fabless.'
An anonymous reader writes: In trying to offer a unique look at how Intel x86 CPU performance has evolved since their start, Phoronix celebrated their 11th birthday by comparing modern CPUs to old Socket 478 CPUs with the NetBurst Celeron and Pentium 4C on an Intel 875P+ICH5R motherboard. These old NetBurst processors were compared to modern Core and Atom processors from Haswell, Broadwell, Bay Trail and other generations. There were also some AMD CPUs and the NVIDIA Tegra K1 ARM processor. Surprisingly, in a few Linux tests the NetBurst CPUs performed better than AMD E-Series APUs and an Atom Bay Trail. However, for most workloads, the 45+ other CPUs tested ended up being multiple times faster; for the systems where the power consumption was monitored, the power efficiency was obviously multiple times better.
DeviceGuru writes: Russia-based Eltechs announced its ExaGear Desktop virtual machine last August, enabling Linux/ARMv7 SBCs and mini-PCs to run x86 software. That meant that users of the quad-core, Cortex-A7-based Raspberry Pi 2 Model B, could use it as well, although the software was not yet optimized for it. Now Eltechs has extended extended ExaGear to support earlier ARMv6 versions of the Raspberry Pi. The company also optimized the emulator for the Pi 2 allowing, for example, Pi 2 users to use automatically forwarding startup scripts.
angry tapir writes: MenuetOS, a GUI-toting, x86-based operating system written entirely in assembly language that's super-fast and can fit on a floppy disk, has hit version 1.0 — after almost a decade and a half of development. (And yes, it can run Doom). The developers say it's stable on all hardware with which they've tested it. In this article, they talk about what MenuetOS can do, and what they plan for the future. "For version 2.0 we'll mostly keep improving different application classes, which are already present in 1.00. For example, more options for configuring the GUI and improving the HTTP client. The kernel is already working well, so now we have more time to focus on driver and application side."
crookedvulture writes: AMD laid out its plans for processors based on its all-new Zen microarchitecture today, promising 40% higher performance-per-clock from from the x86 CPU core. Zen will use simultaneous multithreading to execute two threads per core, and it will be built using "3D" FinFETs. The first chips are due to hit high-end desktops and servers next year. In 2017, Zen will combine with integrated graphics in smaller APUs designed for desktops and notebooks. AMD also plans to produce a high-performance server APU with a "transformational memory architecture" likely similar to the on-package DRAM being developed for the company's discrete graphics processors. This chip could give AMD a credible challenger in the HPC and supercomputing markets—and it could also make its way into laptops and desktops.
jones_supa writes: A massive x86 assembly code spring cleaning has been done in a pull request that is to end up in Linux 4.1. The developers have tried testing the code on many different x86 boxes, but there's risk of regression when exposing the code to many more systems in the days and weeks ahead. That being said, the list of improvements is excellent. There are over 100 separate cleanups, restructuring changes, speedups and fixes in the x86 system call, IRQ, trap and other entry code, part of a heroic effort to deobfuscate a decade old spaghetti assembly code and its C code dependencies.
jones_supa writes Some of us remember the story of why Linux kernel responds "False" when ACPI BIOS asks if the operating system is Linux. We have found yet another case where mimicking the Windows behavior instead of writing to the spec is the right choice if you just want your machine to work properly. The ACPI spec defines the _REV object as evaluating to the revision of the ACPI specification that the OS implements. Linux returns 5 for this, because Linux actually tries to implement ACPI 5.0, but Windows returns 2 (ACPI 2.0), possibly due to legacy reasons. Linux kernel expert Matthew Garrett discovered that still a fair amount of brokenness appears when 5 is returned as the revision, including a Dell machine which left the sound hardware in a misconfigured state. He is proposing a kernel patch which simply reports _REV as 2 on all x86 hardware.
New submitter netelder sends this excerpt from the Project Zero blog: 'Rowhammer' is a problem with some recent DRAM devices in which repeatedly accessing a row of memory can cause bit flips in adjacent rows. We tested a selection of laptops and found that a subset of them exhibited the problem. We built two working privilege escalation exploits that use this effect. One exploit uses rowhammer-induced bit flips to gain kernel privileges on x86-64 Linux when run as an unprivileged userland process. When run on a machine vulnerable to the rowhammer problem, the process was able to induce bit flips in page table entries (PTEs). It was able to use this to gain write access to its own page table, and hence gain read-write access (PDF) to all of physical memory.
Qbertino writes: I've been trying to pick up a classic, object-oriented, compiled language since the early 90s, but have never gotten around to it. C++ was always on my radar, but I'm a little torn to-and-fro with Objective-C. Objective-C is the obvious choice if you also want to make money developing for Mac OS X, but for the stuff I want to do, both languages would suffice on all platforms. I do want to start out on x86 Linux, though, and also use it as my main development platform. Yes, I know quite a few other languages, but I want to get into a widespread compiled language that has good ties into FOSS. Both Objective-C and C++ fit that bill. What do you recommend? How do these two programming languages compare with each other, and how easy is cross-platform development in either? (Primarily GUI-free, "headless" applications.)
New submitter cyranix writes "You may never have to reboot your Linux machine ever again, even for kernel patching," and excerpts from the long (and nicely human-readable) description of newly merged kernel code that does what Ksplice has for quite a while (namely, offer live updating for Linux systems, no downtime required), but without Oracle's control. It provides a basic infrastructure for function "live patching" (i.e. code redirection), including API for kernel modules containing the actual patches, and API/ABI for userspace to be able to operate on the patches (look up what patches are applied, enable/disable them, etc). It's relatively simple and minimalistic, as it's making use of existing kernel infrastructure (namely ftrace) as much as possible. It's also self-contained, in a sense that it doesn't hook itself in any other kernel subsystem (it doesn't even touch any other code). It's now implemented for x86 only as a reference architecture, but support for powerpc, s390 and arm is already in the works (adding arch-specific support basically boils down to teaching ftrace about regs-saving).
jones_supa writes There has been quite a debate around the Linux version of The Witcher 2: Assassins of Kings and the fact that it wasn't really a port. A special kind of wrapper was used to make the Windows version of the game run on Linux systems, similar to Wine. The performance on Linux systems took a hit and users felt betrayed because they thought that they would get a native port. However, after the game stopped launching properly at some point, the reason was actually found to be a Linux regression. Linus quickly took care of the issue on an unofficial Witcher 2 issue tracker on GitHub: "It looks like LDT_empty is buggy on 64-bit kernels. I suspect that the behavior was inconsistent before the tightening change and that it's now broken as a result. I'll write a patch. Serves me right for not digging all the way down the mess of macros." This one goes to the bin "don't break userspace". Linus also reminds of QA: "And maybe this is an excuse for somebody in the x86 maintainer team to try a few games on steam. They *are* likely good tests of odd behavior.."
jones_supa writes A patch was proposed to the Linux Kernel Mailing List to drop support for the old EISA bus. However a user chimed in: "Well, I'd like to keep my x86 box up and alive, to support EISA FDDI equipment I maintain if nothing else — which in particular means the current head version of Linux, not some ancient branch." Linus Torvalds was friendly about the case: "So if we actually have a user, and it works, then no, we're not removing EISA support. It's not like it hurts us or is in some way fundamentally broken, like the old i386 code was (i386 kernel page fault semantics really were broken, and the lack of some instructions made it more painful to maintain than needed — not like EISA at all, which is just a pure add-on on the side)." In addition to Intel 80386, recent years have also seen MCA bus support being removed from the kernel. Linux generally strives to keep support even for crusty hardware if there provably is still user(s) of the particular gear.