Intel was trying to get into smartphones and failed. They're still in the tablet space though, where ARM still dominates, so the comparison is still valid.
There are plenty of companies with higher revenues than Microsoft (eg most oil companies, Wal*Mart, etc.). That doesn't mean higher profits though. Amazon sells so much stuff, it was inevitable their revenues would increase. But their profit margins are pretty small.
Odds are you will see a Windows version of the same machine. I just hope you can put Linux on this one or the Windows version... Oh and that the touchpad does not suck.
I already runs Linux. It just so happens that ChromeOS sits on top of it.
Actually, DOOM was 320x240. 320x200 was Duke Nukem 3D. The reason to use 320x240 is because the pixels were square. However, the screen was split into banks of four because 320x240 pixels is too large to fit in a 64 KiB segment (ie pixels 0,4,8,⦠are in bank 0, pixels 1, 5,9,⦠are in bank 1, etc.) which makes accessing the framebuffer more complicated and slower. 320x200 has slightly rectangular pixels, but the framebuffer is linear and fits in 64KiB, which is the largest segment size that can be accesses in real mode DOS.
The strangest thing: Raspberry Pi uses a Broadcom SoC for all 3 versions, and everything is open source. When I heard they were going to use Broadcom for their device and have open source drivers for everything, needless to say, I was skeptical. And yet they delivered, even with the GPU.
Just for clarification, there are official methods to bootloader unlock some phones (eg Google Nexus, HTC, Motorola, Sony, etc.), but not root. These methods vary by carrier. Generally carrier branded phones may be bootloader unlockable (AT&T HTC One M8/M9/A9) or not (Verizon HTC On M8/M9). Have to do research to figure this one out.
Now with regard to root, root and bootloader unlock often go hand in hand, but they're not the same thing. You can have root on your system without having bootloader unlock on the device (via root exploit, eg any carrier branded Samsung Galaxy S5/6/7). You can have bootloader unlock without having root on your system (ie don't flash SuperSU or don't flash a ROM containing root privileges).
My laptop's trackpad doesn't work with 4.4.x. Can't find the reason why. It does work with 4.1.x and 4.3.x. So I guess I'm going back to the 4.1.x line.
If losing billions is considered "doing just fine", then sure they're doing just fine. I mean, when was the last time they had a profitable year? Not to mention their revenues keep falling. Yes they're doing just fine.
Jessie would revert to software rendering, which makes working in Blender nearly impossible. Had to upgrade from Jessie to Stretch/testing for this to work though, which upgrades the entire graphics stack from the kernel up to X.
This vulnerability affects Linux kernel 3.18 and above. Android 4.1 comes with Linux kernel 3.0.31. My HTC One M8 running Marshmellow (Cyanogenmod 13) is still on kernel 3.4.0
I've been running Debian 8.2 without any problems on a wide range of computers, from desktops to my latest Skylake-based laptop. I haven't had any software issues at all. I'm curious what kind of problems you're having? And it's not like Mac OS X doesn't use something similar to systemd (they do, called launchd).
I've tested version 13 of ICC using Povray on several of my AMD and Intel systems. I can tell you that the dispatch code works as you would expect: AVX (but not AVX2) code path does work on the FX8350, does not work on Phenom II x6 1090T so switched to SSE2 path. Of course, compiling without dispatch will cause seg faults on processors that don't support AVX or AVX2. But that doesn't necessarily mean ICC is the fastest compiler for AMD. For Povray at least that would be GCC.
Depends on program actually and what version of ICC. What you're describing was old ICC behavior before they were sued. My own tests compiling Povray with ICC 13 I've found that the ICC dispatch code does work properly on my FX 8350. In other words, compile with AVX dispatch support and the program will choose the AVX code path, which gives the same performance as compiling with only AVX support (the dispatched program also runs on my PhenomII 1090T, but the AVX exclusive program doesn't). But that doesn't necessarily mean the ICC code is always faster. Sometimes GCC code is faster because GCC can explicitly order instructions for Bulldozer, but it doesn't do autodispatch. That has to be coded separatley by the programmer.
It's Linux friendly because the GPU drivers are open source and don't suck, unlike the AMD GPU drivers. Although if you don't do any 3D related work, any of the open source drivers for all the GPUs are good enough.
Look at the CRay results. It's a small renderer that can fit in processor cache. Look how the i5 6500, with 4 threads and lower clock, still beats an FX 8370, which has much higher clocks and 8 threads.
When to install Cyanogen, for me, is right after I open up the box. I've never run the OEM skins for more than a few days on any of my Android devices (HTC Aria, Samsung Galaxy S II, HTC One M8, Barnes and Noble Nook HD+).
Our eyes can't even resolve that kind of resolution at that size. Not to mention more energy needed, which sucks down even more power. How about a 2k screen and a bigger battery instead? People would be happier with that instead of 4k screen.
Slashdot Mirror
Intel was trying to get into smartphones and failed. They're still in the tablet space though, where ARM still dominates, so the comparison is still valid.
There are plenty of companies with higher revenues than Microsoft (eg most oil companies, Wal*Mart, etc.). That doesn't mean higher profits though. Amazon sells so much stuff, it was inevitable their revenues would increase. But their profit margins are pretty small.
Raspberry Pi 3 has 64-bit ARM and runs Debian.
Odds are you will see a Windows version of the same machine. I just hope you can put Linux on this one or the Windows version... Oh and that the touchpad does not suck.
I already runs Linux. It just so happens that ChromeOS sits on top of it.
The newspaper has an article that explains a little of how they analysed their data (Postgres, cloud, Perl).
I think I found the problem!
Installed Ubuntu on my Surface Pro 2.
Actually, DOOM was 320x240. 320x200 was Duke Nukem 3D. The reason to use 320x240 is because the pixels were square. However, the screen was split into banks of four because 320x240 pixels is too large to fit in a 64 KiB segment (ie pixels 0,4,8,⦠are in bank 0, pixels 1, 5,9,⦠are in bank 1, etc.) which makes accessing the framebuffer more complicated and slower. 320x200 has slightly rectangular pixels, but the framebuffer is linear and fits in 64KiB, which is the largest segment size that can be accesses in real mode DOS.
The strangest thing: Raspberry Pi uses a Broadcom SoC for all 3 versions, and everything is open source. When I heard they were going to use Broadcom for their device and have open source drivers for everything, needless to say, I was skeptical. And yet they delivered, even with the GPU.
You should post in Chinese then. 140 characters is plenty in a logographic writing system.
Just for clarification, there are official methods to bootloader unlock some phones (eg Google Nexus, HTC, Motorola, Sony, etc.), but not root. These methods vary by carrier. Generally carrier branded phones may be bootloader unlockable (AT&T HTC One M8/M9/A9) or not (Verizon HTC On M8/M9). Have to do research to figure this one out.
Now with regard to root, root and bootloader unlock often go hand in hand, but they're not the same thing. You can have root on your system without having bootloader unlock on the device (via root exploit, eg any carrier branded Samsung Galaxy S5/6/7). You can have bootloader unlock without having root on your system (ie don't flash SuperSU or don't flash a ROM containing root privileges).
My laptop's trackpad doesn't work with 4.4.x. Can't find the reason why. It does work with 4.1.x and 4.3.x. So I guess I'm going back to the 4.1.x line.
Which is odd since Core 2, without an on-die memory controller, had higher IPC than K8. I never really understood how that was possible.
If losing billions is considered "doing just fine", then sure they're doing just fine. I mean, when was the last time they had a profitable year? Not to mention their revenues keep falling. Yes they're doing just fine.
Jessie would revert to software rendering, which makes working in Blender nearly impossible. Had to upgrade from Jessie to Stretch/testing for this to work though, which upgrades the entire graphics stack from the kernel up to X.
This vulnerability affects Linux kernel 3.18 and above. Android 4.1 comes with Linux kernel 3.0.31. My HTC One M8 running Marshmellow (Cyanogenmod 13) is still on kernel 3.4.0
I've been running Debian 8.2 without any problems on a wide range of computers, from desktops to my latest Skylake-based laptop. I haven't had any software issues at all. I'm curious what kind of problems you're having? And it's not like Mac OS X doesn't use something similar to systemd (they do, called launchd).
I've tested version 13 of ICC using Povray on several of my AMD and Intel systems. I can tell you that the dispatch code works as you would expect: AVX (but not AVX2) code path does work on the FX8350, does not work on Phenom II x6 1090T so switched to SSE2 path. Of course, compiling without dispatch will cause seg faults on processors that don't support AVX or AVX2. But that doesn't necessarily mean ICC is the fastest compiler for AMD. For Povray at least that would be GCC.
That's too bad since most Android phones are 32-bit right now.
Depends on program actually and what version of ICC. What you're describing was old ICC behavior before they were sued. My own tests compiling Povray with ICC 13 I've found that the ICC dispatch code does work properly on my FX 8350. In other words, compile with AVX dispatch support and the program will choose the AVX code path, which gives the same performance as compiling with only AVX support (the dispatched program also runs on my PhenomII 1090T, but the AVX exclusive program doesn't). But that doesn't necessarily mean the ICC code is always faster. Sometimes GCC code is faster because GCC can explicitly order instructions for Bulldozer, but it doesn't do autodispatch. That has to be coded separatley by the programmer.
It's Linux friendly because the GPU drivers are open source and don't suck, unlike the AMD GPU drivers. Although if you don't do any 3D related work, any of the open source drivers for all the GPUs are good enough.
Look at the CRay results. It's a small renderer that can fit in processor cache. Look how the i5 6500, with 4 threads and lower clock, still beats an FX 8370, which has much higher clocks and 8 threads.
Almost all cellphones have an ARM-based CPU. Only a handful have an x86 CPU.
If not, then I'm not interested.
When to install Cyanogen, for me, is right after I open up the box. I've never run the OEM skins for more than a few days on any of my Android devices (HTC Aria, Samsung Galaxy S II, HTC One M8, Barnes and Noble Nook HD+).
Our eyes can't even resolve that kind of resolution at that size. Not to mention more energy needed, which sucks down even more power. How about a 2k screen and a bigger battery instead? People would be happier with that instead of 4k screen.