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.
DeviceGuru writes CompuLab has unveiled a tiny 'Fitlet' mini-PC that runs Linux or Windows on a dual- or quad-core 64-bit AMD x86 SoC (with integrated Radeon R3 or R2 GPU), clocked at up to 1.6GHz, and offering extensive I/O, along with modular internal expansion options. The rugged, reconfigurable 4.25 x 3.25 x 0.95 in. system will also form the basis of a pre-configured 'MintBox Mini' model, available in Q2 in partnership with the Linux Mint project. To put things in perspective, CompuLab says the Fitlet is three times smaller than the Celeron Intel NUC.
An anonymous reader writes Linux 3.18 was recently released, thus making Linux 3.19 the version under development as the year comes to a close. Linux 3.19 as the first big kernel update of 2015 is bringing in the new year with many new features: among them are AMDKFD HSA kernel driver, Intel "Skylake" graphics support, Radeon and NVIDIA driver improvements, RAID5/6 improvements for Btrfs, LZ4 compression for SquashFS, better multi-touch support, new input drivers, x86 laptop improvements, etc.
MojoKid writes: For the past few years, Intel has promised that its various low-power Atom-based processors would usher in a wave of low-cost Android and Windows mobile products that could compete with ARM-based solutions. And for years, we've seen no more than a trickle of hardware, often with limited availability. Now, that's finally beginning to change. Intel's Bay Trail and Merrifield SoCs are starting to show up more in full-featured, sub-$200 devices from major brands. One of the most interesting questions for would-be x86 buyers in the Android tablet space is whether to go with a Merrifield or Bay Trail Atom-based device. Merrifield is a dual-core chip without Hyper-Threading. Bay Trail is a quad-core variant and a graphics engine derived from Intel's Ivy Bridge Core series CPUs. That GPU is the other significant difference between the two SoCs. With Bay Trail, Intel is still employing their own graphics solution, while Merrifield pairs a dual-core CPU with a PowerVR G6400 graphics core. So, what's the experience of using a tablet running Android on x86 like these days? Pretty much like using an ARM-based Android tablet currently, and surprisingly good for any tablet in the $199 or less bracket. In fact, some of the low cost Intel/Android solutions out there currently from the likes of Acer, Dell, Asus, and Lenovo, all compete performance-wise pretty well versus the current generation of mainstream ARM-based Android tablets.
MojoKid writes Buried in the details of Microsoft's technical preview for Windows 10 is a bit of a footnote concerning the operating system's requirements. Windows 10 will have exactly the same requirements as Windows 8.1, which had the same requirements as Windows 8, which stuck to Windows 7 specs, which was the same as Windows Vista. At this point, it's something we take for granted with future Windows release. As the years roll by, you can't help wondering what we're actually giving up in exchange for holding the minimum system spec at a single-core 1GHz, 32-bit chip with just 1GB of RAM. The average smartphone is more powerful than this these days. For decades, the standard argument has been that Microsoft had to continue supporting ancient operating systems and old configurations, ignoring the fact that the company did its most cutting-edge work when it was willing to kill off its previous products in fairly short order. what would Windows look like if Microsoft at least mandated a dual-core product? What if DX10 — a feature set that virtually every video card today supports, according to Valve's Steam Hardware Survey, became the minimum standard, at least on the x86 side of the equation? How much better might the final product be if Microsoft put less effort into validating ancient hardware and kicked those specs upwards, just a notch or two? If Microsoft did raise the specs a notch or two with each release, I think there'd be some justified complaints about failing to leave well enough alone, at least on the low end.
An anonymous reader writes Lenovo has announced that it will be closing the acquisition deal of IBM's x86 server business on October 1. The closing purchase price is lower than the $2.3 billion announced in January because of a change in the valuation of inventory and deferred revenue liability, Lenovo said. Roughly $1.8 billion will be paid in cash and the remainder in stock. Lenovo says it had "big plans" for the enterprise market. "We will compete vigorously across every sector, using our manufacturing scale, and operational excellence to repeat the success we have had with PCs," the company added.
An anonymous reader writes MINIX 3 is a small POSIX-compliant operating system aimed at high reliability (embedded) applications. A major new version of MINIX 3 (3.3.0) is now available for download at www.minix3.org. In addition to the x86, the ARM Cortex A8 is now supported, with ports to the BeagleBoard and BeagleBones available. Finally, the entire userland has been redone in 3.3.0 to make it NetBSD compatible, with thousands of NetBSD packages available out of the box. MINIX 3 is based on a tiny (13 KLoC) microkernel with the operating system running as a set of protected user-mode processes. Each device driver is also a separate process. If a driver fails, it is automatically and transparently restarted without rebooting and without applications even noticing, making the system self-healing. The full announcement, with links to the release notes and notes on installation, can be found at the Minix Google Groups page.