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.
jones_supa writes Google has revealed that it's launching the finished 64-bit version of Chrome 39 for OS X this November, which already brought benefits in speed, security and stability on Windows. However at this point the 32-bit build for Mac will cease to exist. Just to make it clear, this decision does not apply to Windows and Linux builds, at least for now. As a side effect, 32-bit NPAPI plugins will not work on Chrome on Mac version 39 onwards. The affected hardware are only the very first x86-based Macs with Intel Core Duo processors. An interesting question remains, whether the open source version of Chrome, which is of course Chromium, could still be compiled for x86-32 on OS X.
An anonymous reader sends this news from El Reg: The U.K.'s National Health Service has ripped the Oracle backbone from a national patient database system and inserted NoSQL running on an open-source stack. Spine2 has gone live following successful redevelopment including redeployment on new, x86 hardware. The project to replace Spine1 had been running for three years with Spine2 now undergoing a 45-day monitoring period. Spine is the NHS’s main secure patient database and messaging platform, spanning a vast estate of blades and SANs. It logs the non-clinical information on 80 million people in Britain – holding data on everything from prescriptions and payments to allergies. Spine is also a messaging hub, serving electronic communications between 20,000 applications that include the Electronic Prescription Service and Summary Care Record. It processes more than 500 complex messages a second.
szczys writes: Intel is upping their bid for a place at the efficient-yet-powerful device table. They've launched their Edison board, which features an x86 based SoC running at 100 MHz. The footprint measures 35.5mm x 25.0mm and offers a 70-pin connector to break out 40 pins for add-on hardware. Also at the Intel Developer Forum today, the company demonstrated a PC running on Skylake, a new CPU microarchitecture based on the 14nm process used for Broadwell. Intel is pushing to break into both wearable devices and household devices, as it sees both as huge opportunities for growth.
storkus writes: The release of Haswell-E and a price drop on Devil's Canyon has made me itch for a PC upgrade. However, looking around I discovered a pair of horror stories on Phoronix about the difficulties of using Linux on a multitude of motherboards. My question: if MSI, Gigabyte, Asus (and by extension Asrock) are out, who's left and are they any good? I'd like to build a (probably dual-boot, but don't know for sure) gaming and 'other' high-end machine with one of the above chips, so we're talking Z97 or X99; however, these stories seem to point to the problems being Windows-isms in the BIOS/UEFI structures rather than actual hardware incompatibility, combined with a lousy attitude (despite the Steam Linux distro being under development).
fsterman writes The power advantages brought by the RISC instruction sets used in Power and ARM chips is often pitted against the X86's efficiencies of scale. It's difficult to assess how much the difference between instruction sets matter because teasing out the theoretical efficiency of an ISA from the proficiency of a chip's design team, technical expertise of its manufacturer, and support for architecture-specific optimizations in compilers is nearly impossible . However, new research examining the performance of a variety of ARM, MIPS, and X86 processors gives weight to Intel's conclusion: the benefits of a given ISA to the power envelope of a chip are minute.
darthcamaro (735685) writes "Now that IBM has sold off its x86 server business to Lenovo, it's full steam ahead for IBM's Power business. While Intel is ramping up its next generation of server silicon for a September launch, IBM has its next lineup of Power 8 servers set to be announced in October. "There is a larger than 4U, 2 socket system coming out," Doug Balog, General Manager of Power Systems within IBM's System and Technology Group said. Can IBM Power 8 actually take on x86? Or has that ship already sailed?" At last weekend's Linux Con in Chicago, IBM talked up the availability of the Power systems, and that they are working with several Linux vendors, including recently-added Ubuntu; watch for a video interview with Balog on how he's helping spend the billion dollars that IBM pledged last year on open source development.
DeviceGuru writes Eltechs announced a virtual machine that runs 32-bit x86 Linux applications on ARMv7 hardware. The ExaGear VM implements a virtual x86 Linux container on ARMv7 computers and is claimed to be 4.5 times faster than QEMU, according to Eltechs. The VM is based on binary translation technology and requires ARMv7, which means it should run on mini-PCs and SBCs based on Cortex-A8, A7, A9, and A15 processors — but sadly, it won't run on the ARM11 (ARMv6) SoC found on the Raspberry Pi. It also does not support applications that require kernel modules. It currently requires Ubuntu (v12.04 or higher), but will soon support another, unnamed Linux distro, according to Eltechs, which is now accepting half price pre-orders without payment obligation.