There is a big difference between the floppy drive and the headphone jack. The floppy drive died out because a bunch of new, better in every way alternatives came out that made it no longer useful. The headphone jack is still quite useful.
If Apple wants to push technology forward and make a better headphone jack then why not do something that would actually improve audio quality like making the new connector support balanced headphone drive and get rid of the common ground? Combined with a quality pair of headphones that would really push audio fidelity forward.
Of course like everyone else here I expect this is probably just a money grab intended to sell a bunch of dongles and collect a ton of licensing fees on lighting connector headphones with zero actual improvement included.
...contains 621 million transistors... Imagine how many mind-boggling things will become possible if this much processing power ultimately finds its way into new consumer technologies.
Let see... 1,000 very small compute cores... sounds a awful lot like your typical GP-GPU these days. Only reason the power consumption is so small is because it has < 1 billion transistors. Compare that to the 17 billion transistor nVidia pascal monster. Even the non-Iris graphics Skylake desktop CPU has ~1.7 billion, and over half of those are spent on the GPU.
Chances are even paltry Intel HD Graphics running an OpenCL program will have more FLOPS than this thing. Don't be fooled by the flashy headline, the laws of physics still apply.
I suspect that the $1 trillion number the BSA came up with is a generous estimation that gives excessive weight to all the secondary sectors that the software industry supports. Just because construction firms purchase a bunch of trucks doesn't mean that construction jobs get counted as part of "the auto industry's impact on GDP." The only thing that counts towards GDP is the revenue generated by the sales of those trucks (worker wages DO NOT count as part of GDP unless they are government workers), same principle should apply to the software industry.
Just a bunch of rhetoric to talk up Congress about why its so important that they pass a bunch of new IP laws to protect the US economy.
Your right, there is something amiss this time. This is the first time consoles are architecturally identical to a standard PC system. It is also the first time that none of the consoles attempted to push technology forward in any way (the chips in both consoles are nothing to write home about performance wise, even at the time of the console's launch.) At the same time, small form factor PCs like NUCs were getting popular. Combined with Steam, PC manufactures started building gaming systems that *directly* competed with consoles in the living room. All things considered, consoles are exposed to the PC refresh cycle much more than ever before. Neither Sony or MSFT were concerned since the game software developers just target the lowest common denominator anyway.
The big miscalculation that both manufactures made is two emerging disruptive technologies have shown up. First... VR. Second, neither manufacturer predicted how aggressively TV manufactures would rapidly push the price of 4K displays down. Both of these offer compelling experiences that current gen pedestrian hardware design choices are incapable of driving. So the current gen consoles are going to end up having a short life. Otherwise the market is going to shift to the PC and leave them in the dust.
The problem is that the coal industry is leaving taxpayers with pension obligations and mine cleanup obligations.
In this case Peabody is essentially asking the court to take shares away from its current stockholders so that Peabody can then give those shares to their debtors as repayment for their debt. So in this case anyway, the current investors are the ones being f'd, not the US taxpayer.
So what the hell does "Ubuntu will primarily run on a foundation of native Windows libraries" mean?
Back in the WinXP days when Windows Services for UNIX (formerly known as Interix before Microsoft bought it) was free there where was a community driven effort to use Xming to run KDE and GNOME on Windows Services for UNIX 3.6 by recompiling all the user-space libraries to Interix and using a fork of the BSD package manager to install all the dependencies. After Microsoft starting charging money for Services for UNIX by requiring you to buy the "Ultimate" Windows Vista SKU interest dropped off rapidly. Question is will this be another bait and switch tactic to try to get you to buy the higher end Windows SKU when the next version comes out? It has happened once before.
From a technical standpoint, I honestly don't know how they are doing this, but my guess is that Microsoft has decided to dig up and revitalize Interix. It provided an implementation of POSIX as a WinNT kernel subsystem, similar to Win32 (ignoring that Win32 is given special treatment by the NT kernel.) Most of the work would be to make Interix compatible with ELF binaries and the Linux INT 0x80 syscall interface, make a version of ld that is compatible with Linux ELF binaries, throw in an X server implemented on either Win32 GDI or maybe one of the newer APIs like Direct2D, add a chroot jail and then let Ubuntu provide all the userspace libraries and applications.
PCIe 3.0 runs at 8 GT/s, which has very high signal integrity requirements, at that speed even a 1mm stray solder ball starts acting like an antenna. If you want to route that signal over cheap wire (which is a requirement) you are going to have signal integrity issues at trace lengths >12" from the PCIe port on the chip-set, meaning your cheap cable is probably 3-4" in length at best. A 3' cable is going to cost $100 if you do it this way. Note that a typical 50cm U.2 cable costs $50 because of the shielding and wire thickness needed for moving PCIe 3.0 over cable. This is why U.2 was originally an enterprise/server product and wasn't intended for consumer systems.
So, just using PCIe signaling as is doesn't pan out for the consumer market, customers won't buy it without cheap 6' cables. So you need to change the signal so that it can traverse a cheap cable better... this requires a bridge chip to convert from the PCIe signaling to external cable signaling... Intel set out to do EXACTLY what you are asking for (external PCIe) and Thunderbolt was the result.
There are two reasons why BIOS changes are needed for Thunderbolt. First, the Windows pci.sys bus driver doesn't do a very good job at assigning I/O resources to hot plugged PCIe devices when you hot plug a complex topology of 3-4 nested levels of virtual PCI/PCI bridges at once. Supposedly this is better in Win10 but still not perfect. Second, there are some subtle differences in the PCI enumeration algorithm for Thunderbolt versus regular PCI. So Non-Mac Thunderbolt systems have the BIOS do resource assignment for hot plugged Thunderbolt devices... even while the OS is running using SMM (OSX supports Thunderbolt natively and doesn't need the BIOS hacks.)
Honestly, even though we all (Linus included) shit on UEFI, ACPI, x86 and the PC in general... I think we all have to agree that despite the PC ecosystem has literally thousands of different OEMs that fact that somehow every PC in existence is able to boot stock unmodified operating system images is pretty amazing.
All of those PC specifications like PCIe, USB, x86, ACPI and UEFI certainly have their faults but honestly having industry standard specs that enable universal kernel binaries to boot on every platform is worth it compared to maintaining thousands of different kernel binaries for every single board the way the ARM ecosystem does it.
It took me a matter of minutes to find that people have been adding GPUs to Macs on a Thunderbolt port for years.
You are right, it is possible to use an external enclosure connected via Thunderbolt to add a GPU to a Mac. But those enclosures are expensive, and Thunderbolt isn't exactly designed with this task in mind. The performance you get out of this solution won't be as good as a regular old PC, and you going to spend 3X the cash for worse performance.
Consider that current Macs have Thunderbolt 2, which will give you 20 Gbit/sec of max bandwidth. Compare this to the 8 Gbit/sec per lane on PCIe 3.0 X 16 lanes = 128 GBit/sec bandwidth on a PCIe 3.0 X16 connection, Thunderbolt 2 only gives you 15% of the bandwidth. Surprisingly, Apple is late to the party shipping Thunderbolt 3 (Gigabyte and MSI have been offering it with their Skylake systems for a few months now) but when they do release a Thunderbolt 3 Mac, this will go up to 40 Gbit/sec, which is still only 31% of a PCIe 3.0 X16 link. Note that the PCIe external enclosures will also need to be updated to Thunderbolt 3, which has not happened yet.
Another thing to keep in mind is that on a lot of Macs Apple connects the Thunderbolt controller to the PCH PCIe, not the CPU PCIe, so you also have to count in the X4 DMI link between the PCH and the CPU will add latency and potentially be a bottleneck since all your disk and network access also goes over that X4 link. However, the high end Macs like the 15" Macbook Pro and the Mac Pro do have Thunderbolt connected to CPU PCIe.
Another thing to remember is that the 3D performance on the video drivers for OSX are usually not as optimized as the Windows drivers, there are many stories online about how installing Windows on your Mac boosts gaming performance. Honestly, the Occulus Rift guy is right here... he could have worded it more diplomatically though.
Looks like the fact that Valve largely controls PC gaming and is doing everything they can to push it away from Microsoft's platform has earned them Microsoft's perceived #1 gaming competitor. Make no mistake, Microsoft knows that gaming is one of the few remaining compelling reasons for consumers to use their platform. Most (but not all) desktop application use cases can be accomplished with a web browser these days. Microsoft knows that if they don't create a reason for game devs to use DirectX 12 then there is a risk that game devs will prefer Vulkan due to the multi-platform targeting (Windows, SteamOS, Android) which will erode the position of Windows as the best PC gaming platform.
Basically this is Microsoft saying that they don't care very much about Sony anymore, they perceive Valve as a greater threat and they are willing to give up the hardware sales that XBox exclusive titles would normally drive to instead incentivize continued purchase of Windows licenses for gaming PCs. It would not surprise me if Microsoft starts licensing the XBox brand the same way Steam Machines are licensed. We could see an "Alienware Xbox" sometime soon.
If this actually works it could be one of the most important advances in human medicine for decades. Hopefully it actually works and isn't the typical vaporware HIV cure.
I thought to myself... how can Microsoft force this? All of their corporate customers have volume licenses with downgrade rights. Intel and AMD can still release drivers for Windows 7 if they wanted to. Then it occurred to me... driver signing.
Microsoft has seriously shaken up how driver signing works starting with Windows 10. The only way to sign any new driver in a way that Windows 10 will accept is to upload it to Microsoft over the web and have them cross-sign it along with your original signature. It used to be that as long as you had a certificate which came from a root CA that was cross-signed by Microsoft then you could sign it yourself and Windows would accept it as valid.
Now Windows 10 checks the time stamp on the driver and if the time stamp is earlier than July 29th, 20015 (the date Windows 10 was released) then Windows 10 will accept the old cross-signed root CA. If its after that date then only drivers that are directly signed my Microsoft are accepted as valid by the OS.
So how does this affect Windows 7? Well believe it or not, Windows 7 will accept certificates with either SHA1 or SHA2 (aka SHA256) for USER MODE signature check (aka.exe and.dll files.) For kernel mode drivers, Windows 7 will only accept SHA1 certificates! So all it takes is for Microsoft to stop providing SHA1 hashes via their driver signing website and then you instantly lock out any new kernel mode binary from being able to load on both Windows 7 and Windows 10. That doesn't prevent someone that still has an old SHA1 code signing certificate from using it to sign Windows 7 only drivers. But most of those certificates are expiring in the next year or two, if they haven't expired already. Intel/AMD/etc could probably release drivers for maybe 1 more silicon generation before their old certificates expire and they lose the ability to release Windows 7 drivers without submitting them to Microsoft for approval.
Basically Microsoft is using code signing to create planned obsolescence for Windows 7.
i'm designing Libre Hardware, right now. i've been on this task for the past five years, since the embarrassing time when i encouraged 20 software libre developers to join me in buying one of the very first ARM netbooks to come out (back in 2010) that turned out to be GPL-violating.
So you have a GPL ARM netbook somewhere? Can you please provide me the URL to download the RTL for that ARM chip you have in that netbook? Also, please send me the URL to download the silicon layout files? Which foundry did you contract with to build that chip? TSMC?
All commercial contract silicon foundries with any semi-recent process node (32nm or lower) require you to sign an NDA before they provide you with the transistor models for their manufacturing process. If your ARM chip design is under a GPL license, how do you deal with the fact that it is impossible to distribute your layout file without also distributing the layout for your foundry's transistor design which is under NDA?
Even if your CPU design is fully synthesizable and you only distribute the RTL (which by the way will make your design a bit slower than if you had VLSI engineers custom design some of the critical paths in the CPU layout)... wouldn't running the synthesis tool be the same as running the compiler on software source code, so wouldn't the layout files that result from the synthesis be considered a derived work which also must be GPL licensed? Also, last time I checked there isn't any open source synthesis tools and both Synopsis and Cadence charge 6-figures to license their closed source synthesis tools. Are you addressing the lack of open source design tools? Do you have a cluster somewhere with some of that software available?
In other words... I'm 100% sure that your ARM silicon design is not GPL, in fact I'm 100% sure that it's not open source because ARM Limited Inc. only provides ARM licenses under NDA. You bought that ARM chip from some company with a closed source silicon design. The only thing you are focused on is designing an open source PCB to put a closed source CPU on top of. You make the incorrect assumption that just because you can send your PCB to any PCB manufacturer and get the same result back, the same thing can be applied to chips. PCBs are easy, chips are hard. The OP is right. There is a fundamental difference when you are talking about manufacturing something that requires billions of dollars worth of capital expense in order to create the factory necessary to build the device. Nobody spends billions to create the capability to manufacture modern silicon and then gives away their factory's transistor design in today's world. Until open source foundry exists and open source silicon design exists... your obsession over firmware binary blobs is penny wise and dollar dumb.
If you want to actually change something, you should be pitching open source foundry... honestly I think its a rather hard sell:) The much more feasible thing for you to do would be to start developing open source silicon design software. Just like how GCC was a prerequisite to an open source UNIX, open source silicon design tools are a prerequisite to open source hardware.
I don't know about everyone else, but IMHO the web browser is THE WORST platform to code for in existence. It amazes and depresses me how little has changed about client side web programming since IE4. Instead we have created these huge frameworks to try to hide the suck under an enormous pile of middleware. But still we are doing this fundamentally broken thing of shoehorning a language intended to describe formatted text documents (HTML) to instead describe a GUI for an application. This reminds me of IE4 and its web page dialogs.
If we truly are serious about having the web be an application platform then a new markup intended to describe cross platform application GUIs and a standard bytecode for the web is needed. Asm.js and enscripten or PNaCl both could be our new standard bytecode, both have pros and cons that I won't rehash. Honestly I'm not a huge fan of either one. But no one is trying to address the fact that HTML's layout system is designed for documents... Not for GUIs. We really need something like XUL or XAML made in to a web standard. I don't care about the politics of what language/tool we choose as long as its a good one thats open for all. I'm sick of the holy wars over tools and languages. That said JavaScript is garbage just like HTML and CSS for actual development and needs to be replaced with a sane language.
Honestly the thing that would make continuum really worth while would be if Microsoft got rid of the phone OS entirely and ported the telephony stack to the full Windows 10 OS and just install full Windows 10 on everything, including phones. Then when you enter desktop mode when you dock for phone you will be able to run Win32 apps in addition to the universal apps. With that, you will truly have a real, full computer in your pocket.
Of course this does mean that Microsoft would have to limit their phone OS to X86 CPUs, otherwise the feature would not be worthwhile. Honestly... I don't think that is as big of a deal as it sounds. Intel's smartphone chips have changed a lot in the last 2 years. If you haven't taken a look at the Zenfone 2 yet, its a great phone. You don't notice anything different between it and other high end Android phones other than the fact that is has an Intel logo on the back and it has the same features as a $600 phone for $300. Since nobody builds phones with Windows installed anymore except Microsoft, restricting the phone OS to X86 only isn't going to affect some existing OEM customer base:)
10 years ago, Intel was hinting at a massively parallel future (80 core processor rumored in development at the time)
I think the 80 core processor Intel was developing at the time eventually turned in to the Knights Corner aka Xeon Phi chip. Originally Intel developed this tech for the Larrabee project, which was intended to be a discrete GPU built out of a huge number of X86 cores. The thought was if you threw enough X86 cores at the problem, even software rendering on all those cores would be fast. As projects like llvmpipe and OpenSWR have shown, given a huge number of X86 cores this isn't as crazy of an idea as it initially sounds... but still a little crazy:) Ultimately Intel cancelled that project and decided to use that tech for super computing instead of graphics. A result of this is Intel retained the "Gen" design for their graphics core, which is a more traditional GPU design.
If it's not GPL'ed, it's not open source. And we all know what abhorrence MS harbors for GPL...
The Open Source Initiative has certified the MIT license as a valid open source license. Look I'm not a huge MS fan either, but they are using a real OSS license here. Just because MIT isn't copyleft doesn't mean its not OSS.
Speaking as someone who writes firmware for a living, Rust will never be a replacement for C in its current state. C has one property that sets it apart from every other language that is higher level than assembly. It is possible to write a C program that does not need *ANY* C run-time library support. Our firmware runs on the bare metal without any OS whatsoever, so running Rust in firmware requires building all the services that the Rust run-time requires (heap, threads, etc.) and porting the Rust run-time to it.
So unless we want to write heap, threads, etc. in assembly... C is our only option for bootstrapping Rust. Since we are using C for that part of our code base... why not use it for all? The firmware I work on doesn't do a bunch of string manipulation of other things that makes a higher level language like Rust nice. Why add all that additional complexity to support Rust? By the way, anyone writing an operating system kernel is going to run in to the same thing with Rust.
It would be possible to bootstrap Rust on top of a basic kernel written in C and maybe even use it for some of the kernel code (drivers for example, like how OSX uses C++ for I/O Kit drivers), but Rust will never replace C. It would be nice if someone designed a new **Systems Programming Language** that can run without a run-time and had some of the features that newer languages do... but it seems the only thing people think about when designing new languages these days is the web and/or cloud computing.
Despite what the Rust developers claim, Rust is not a real Systems Programming Language in its current state since it requires a run-time. Its OK to have an optional run-time and for some features to stop working when its not there... but it must be optional not required.
As you can see, Intel is actually competing well against the best ARM can offer in their own backyard. The A8X does ~5% better in multi-threaded workloads, it has 3 cores vs. Core M's 2 cores. Single threaded, the A8X is ~26% slower than Core M. Despite having 4 cores, the Tegra K1 has ~16% worse multi-threaded performance than the Core M with 2 cores and ~53% slower single threaded performance. When you consider most GUI/web applications are single threaded (which is mostly what people use tablets for) Broadwell Core M is the best tablet chip on the market right now. Its only going to get better with Skylake.
At the same time, ARM hasn't been able to really touch Intel's home turf in the high performance market.
On the topic on instruction sets, honestly the most important difference between x86 and ARM is having an x86 design gives you a distinct advantage in the market for computers that run Windows. Given that there is no disadvantage for x86 in any other market segment (Android, Chrome, Mac, etc.) why would Intel switch to ARM when there is only upside to x86 and no downside?
>Law of supply and demand affects salaries. Companies that have not learned this, can't find qualified candidates, because they're not paying enough.
Companies are completely aware of supply and demand. Not being able to find good candidates is the excuse they give. The real reason why companies want H1-B's is because it increases the supply of high tech labor. Increasing the supply of any good or service, keeping the demand constant will reduce the price of the good or service. This is basic ECON-101. In this case, the service being sold is high tech labor. Increasing the supply of people seeking high tech employment reduces the average wage for high tech work.
Note that this is the reason why the same people pushing for more H-1B's are also donating to public schools to improve their high tech curriculum. They are actively seeking to increase the labor supply using whatever means possible. Whats surprising is how willing they are to make such a long term investment in education "philanthropy." It will take probably ~10 years for the education investment to bear fruit. Hard to call it philanthropy when its done for an entirely self serving reason:).
I think what this benchmark really tells us is two things:
1. nVidia has not optimized their driver stack for DX12 as much as AMD has optimized for DX12
2. The performance difference between AMD and nVidia is likely a software issue, not a hardware issue (nVidia's driver has a more optimized DX11 implementation than AMD's). However, it is possible that nVidia's silicon architecture is designed to run DX11 workloads better than AMD's.
Bullet #1 make sense, AMD has been developing Mantle for years now so they likely have a more mature stack for these low level APIs. Bullet #2 also makes sense, AMD/ATI's driver has been a known weak point for a long time now.
Freemium is pretty disgusting really. Instead of just buying the game, you have to keep paying for the game constantly. You pay every time they add a new sword/gun/zombie killing plant a la "micro transactions." Honestly its almost as bad as slot machines in a vegas casino. There is a funny tongue in cheek game called DLC Quest about this... which you only have to pay for once:)
Slashdot Mirror
There is a big difference between the floppy drive and the headphone jack. The floppy drive died out because a bunch of new, better in every way alternatives came out that made it no longer useful. The headphone jack is still quite useful.
If Apple wants to push technology forward and make a better headphone jack then why not do something that would actually improve audio quality like making the new connector support balanced headphone drive and get rid of the common ground? Combined with a quality pair of headphones that would really push audio fidelity forward.
Of course like everyone else here I expect this is probably just a money grab intended to sell a bunch of dongles and collect a ton of licensing fees on lighting connector headphones with zero actual improvement included.
...contains 621 million transistors... Imagine how many mind-boggling things will become possible if this much processing power ultimately finds its way into new consumer technologies.
Let see... 1,000 very small compute cores... sounds a awful lot like your typical GP-GPU these days. Only reason the power consumption is so small is because it has < 1 billion transistors. Compare that to the 17 billion transistor nVidia pascal monster. Even the non-Iris graphics Skylake desktop CPU has ~1.7 billion, and over half of those are spent on the GPU.
Chances are even paltry Intel HD Graphics running an OpenCL program will have more FLOPS than this thing. Don't be fooled by the flashy headline, the laws of physics still apply.
I suspect that the $1 trillion number the BSA came up with is a generous estimation that gives excessive weight to all the secondary sectors that the software industry supports. Just because construction firms purchase a bunch of trucks doesn't mean that construction jobs get counted as part of "the auto industry's impact on GDP." The only thing that counts towards GDP is the revenue generated by the sales of those trucks (worker wages DO NOT count as part of GDP unless they are government workers), same principle should apply to the software industry.
Just a bunch of rhetoric to talk up Congress about why its so important that they pass a bunch of new IP laws to protect the US economy.
Your right, there is something amiss this time. This is the first time consoles are architecturally identical to a standard PC system. It is also the first time that none of the consoles attempted to push technology forward in any way (the chips in both consoles are nothing to write home about performance wise, even at the time of the console's launch.) At the same time, small form factor PCs like NUCs were getting popular. Combined with Steam, PC manufactures started building gaming systems that *directly* competed with consoles in the living room. All things considered, consoles are exposed to the PC refresh cycle much more than ever before. Neither Sony or MSFT were concerned since the game software developers just target the lowest common denominator anyway.
The big miscalculation that both manufactures made is two emerging disruptive technologies have shown up. First... VR. Second, neither manufacturer predicted how aggressively TV manufactures would rapidly push the price of 4K displays down. Both of these offer compelling experiences that current gen pedestrian hardware design choices are incapable of driving. So the current gen consoles are going to end up having a short life. Otherwise the market is going to shift to the PC and leave them in the dust.
The problem is that the coal industry is leaving taxpayers with pension obligations and mine cleanup obligations.
In this case Peabody is essentially asking the court to take shares away from its current stockholders so that Peabody can then give those shares to their debtors as repayment for their debt. So in this case anyway, the current investors are the ones being f'd, not the US taxpayer.
At this point they are probably just trying to prevent SCO's former shareholders from suing McBride and his cronies for professional negligence.
So what the hell does "Ubuntu will primarily run on a foundation of native Windows libraries" mean?
Back in the WinXP days when Windows Services for UNIX (formerly known as Interix before Microsoft bought it) was free there where was a community driven effort to use Xming to run KDE and GNOME on Windows Services for UNIX 3.6 by recompiling all the user-space libraries to Interix and using a fork of the BSD package manager to install all the dependencies. After Microsoft starting charging money for Services for UNIX by requiring you to buy the "Ultimate" Windows Vista SKU interest dropped off rapidly. Question is will this be another bait and switch tactic to try to get you to buy the higher end Windows SKU when the next version comes out? It has happened once before.
From a technical standpoint, I honestly don't know how they are doing this, but my guess is that Microsoft has decided to dig up and revitalize Interix. It provided an implementation of POSIX as a WinNT kernel subsystem, similar to Win32 (ignoring that Win32 is given special treatment by the NT kernel.) Most of the work would be to make Interix compatible with ELF binaries and the Linux INT 0x80 syscall interface, make a version of ld that is compatible with Linux ELF binaries, throw in an X server implemented on either Win32 GDI or maybe one of the newer APIs like Direct2D, add a chroot jail and then let Ubuntu provide all the userspace libraries and applications.
PCIe 3.0 runs at 8 GT/s, which has very high signal integrity requirements, at that speed even a 1mm stray solder ball starts acting like an antenna. If you want to route that signal over cheap wire (which is a requirement) you are going to have signal integrity issues at trace lengths >12" from the PCIe port on the chip-set, meaning your cheap cable is probably 3-4" in length at best. A 3' cable is going to cost $100 if you do it this way. Note that a typical 50cm U.2 cable costs $50 because of the shielding and wire thickness needed for moving PCIe 3.0 over cable. This is why U.2 was originally an enterprise/server product and wasn't intended for consumer systems.
So, just using PCIe signaling as is doesn't pan out for the consumer market, customers won't buy it without cheap 6' cables. So you need to change the signal so that it can traverse a cheap cable better... this requires a bridge chip to convert from the PCIe signaling to external cable signaling... Intel set out to do EXACTLY what you are asking for (external PCIe) and Thunderbolt was the result.
There are two reasons why BIOS changes are needed for Thunderbolt. First, the Windows pci.sys bus driver doesn't do a very good job at assigning I/O resources to hot plugged PCIe devices when you hot plug a complex topology of 3-4 nested levels of virtual PCI/PCI bridges at once. Supposedly this is better in Win10 but still not perfect. Second, there are some subtle differences in the PCI enumeration algorithm for Thunderbolt versus regular PCI. So Non-Mac Thunderbolt systems have the BIOS do resource assignment for hot plugged Thunderbolt devices... even while the OS is running using SMM (OSX supports Thunderbolt natively and doesn't need the BIOS hacks.)
every ARM SoC is its own dysfunctional port
Honestly, even though we all (Linus included) shit on UEFI, ACPI, x86 and the PC in general... I think we all have to agree that despite the PC ecosystem has literally thousands of different OEMs that fact that somehow every PC in existence is able to boot stock unmodified operating system images is pretty amazing.
All of those PC specifications like PCIe, USB, x86, ACPI and UEFI certainly have their faults but honestly having industry standard specs that enable universal kernel binaries to boot on every platform is worth it compared to maintaining thousands of different kernel binaries for every single board the way the ARM ecosystem does it.
It took me a matter of minutes to find that people have been adding GPUs to Macs on a Thunderbolt port for years.
You are right, it is possible to use an external enclosure connected via Thunderbolt to add a GPU to a Mac. But those enclosures are expensive, and Thunderbolt isn't exactly designed with this task in mind. The performance you get out of this solution won't be as good as a regular old PC, and you going to spend 3X the cash for worse performance.
Consider that current Macs have Thunderbolt 2, which will give you 20 Gbit/sec of max bandwidth. Compare this to the 8 Gbit/sec per lane on PCIe 3.0 X 16 lanes = 128 GBit/sec bandwidth on a PCIe 3.0 X16 connection, Thunderbolt 2 only gives you 15% of the bandwidth. Surprisingly, Apple is late to the party shipping Thunderbolt 3 (Gigabyte and MSI have been offering it with their Skylake systems for a few months now) but when they do release a Thunderbolt 3 Mac, this will go up to 40 Gbit/sec, which is still only 31% of a PCIe 3.0 X16 link. Note that the PCIe external enclosures will also need to be updated to Thunderbolt 3, which has not happened yet.
Another thing to keep in mind is that on a lot of Macs Apple connects the Thunderbolt controller to the PCH PCIe, not the CPU PCIe, so you also have to count in the X4 DMI link between the PCH and the CPU will add latency and potentially be a bottleneck since all your disk and network access also goes over that X4 link. However, the high end Macs like the 15" Macbook Pro and the Mac Pro do have Thunderbolt connected to CPU PCIe.
Another thing to remember is that the 3D performance on the video drivers for OSX are usually not as optimized as the Windows drivers, there are many stories online about how installing Windows on your Mac boosts gaming performance. Honestly, the Occulus Rift guy is right here... he could have worded it more diplomatically though.
Looks like the fact that Valve largely controls PC gaming and is doing everything they can to push it away from Microsoft's platform has earned them Microsoft's perceived #1 gaming competitor. Make no mistake, Microsoft knows that gaming is one of the few remaining compelling reasons for consumers to use their platform. Most (but not all) desktop application use cases can be accomplished with a web browser these days. Microsoft knows that if they don't create a reason for game devs to use DirectX 12 then there is a risk that game devs will prefer Vulkan due to the multi-platform targeting (Windows, SteamOS, Android) which will erode the position of Windows as the best PC gaming platform.
Basically this is Microsoft saying that they don't care very much about Sony anymore, they perceive Valve as a greater threat and they are willing to give up the hardware sales that XBox exclusive titles would normally drive to instead incentivize continued purchase of Windows licenses for gaming PCs. It would not surprise me if Microsoft starts licensing the XBox brand the same way Steam Machines are licensed. We could see an "Alienware Xbox" sometime soon.
If this actually works it could be one of the most important advances in human medicine for decades. Hopefully it actually works and isn't the typical vaporware HIV cure.
I thought to myself... how can Microsoft force this? All of their corporate customers have volume licenses with downgrade rights. Intel and AMD can still release drivers for Windows 7 if they wanted to. Then it occurred to me... driver signing.
Microsoft has seriously shaken up how driver signing works starting with Windows 10. The only way to sign any new driver in a way that Windows 10 will accept is to upload it to Microsoft over the web and have them cross-sign it along with your original signature. It used to be that as long as you had a certificate which came from a root CA that was cross-signed by Microsoft then you could sign it yourself and Windows would accept it as valid.
Now Windows 10 checks the time stamp on the driver and if the time stamp is earlier than July 29th, 20015 (the date Windows 10 was released) then Windows 10 will accept the old cross-signed root CA. If its after that date then only drivers that are directly signed my Microsoft are accepted as valid by the OS.
So how does this affect Windows 7? Well believe it or not, Windows 7 will accept certificates with either SHA1 or SHA2 (aka SHA256) for USER MODE signature check (aka .exe and .dll files.) For kernel mode drivers, Windows 7 will only accept SHA1 certificates! So all it takes is for Microsoft to stop providing SHA1 hashes via their driver signing website and then you instantly lock out any new kernel mode binary from being able to load on both Windows 7 and Windows 10. That doesn't prevent someone that still has an old SHA1 code signing certificate from using it to sign Windows 7 only drivers. But most of those certificates are expiring in the next year or two, if they haven't expired already. Intel/AMD/etc could probably release drivers for maybe 1 more silicon generation before their old certificates expire and they lose the ability to release Windows 7 drivers without submitting them to Microsoft for approval.
Basically Microsoft is using code signing to create planned obsolescence for Windows 7.
i'm designing Libre Hardware, right now. i've been on this task for the past five years, since the embarrassing time when i encouraged 20 software libre developers to join me in buying one of the very first ARM netbooks to come out (back in 2010) that turned out to be GPL-violating.
So you have a GPL ARM netbook somewhere? Can you please provide me the URL to download the RTL for that ARM chip you have in that netbook? Also, please send me the URL to download the silicon layout files? Which foundry did you contract with to build that chip? TSMC?
All commercial contract silicon foundries with any semi-recent process node (32nm or lower) require you to sign an NDA before they provide you with the transistor models for their manufacturing process. If your ARM chip design is under a GPL license, how do you deal with the fact that it is impossible to distribute your layout file without also distributing the layout for your foundry's transistor design which is under NDA?
Even if your CPU design is fully synthesizable and you only distribute the RTL (which by the way will make your design a bit slower than if you had VLSI engineers custom design some of the critical paths in the CPU layout)... wouldn't running the synthesis tool be the same as running the compiler on software source code, so wouldn't the layout files that result from the synthesis be considered a derived work which also must be GPL licensed? Also, last time I checked there isn't any open source synthesis tools and both Synopsis and Cadence charge 6-figures to license their closed source synthesis tools. Are you addressing the lack of open source design tools? Do you have a cluster somewhere with some of that software available?
In other words... I'm 100% sure that your ARM silicon design is not GPL, in fact I'm 100% sure that it's not open source because ARM Limited Inc. only provides ARM licenses under NDA. You bought that ARM chip from some company with a closed source silicon design. The only thing you are focused on is designing an open source PCB to put a closed source CPU on top of. You make the incorrect assumption that just because you can send your PCB to any PCB manufacturer and get the same result back, the same thing can be applied to chips. PCBs are easy, chips are hard. The OP is right. There is a fundamental difference when you are talking about manufacturing something that requires billions of dollars worth of capital expense in order to create the factory necessary to build the device. Nobody spends billions to create the capability to manufacture modern silicon and then gives away their factory's transistor design in today's world. Until open source foundry exists and open source silicon design exists... your obsession over firmware binary blobs is penny wise and dollar dumb.
If you want to actually change something, you should be pitching open source foundry... honestly I think its a rather hard sell :) The much more feasible thing for you to do would be to start developing open source silicon design software. Just like how GCC was a prerequisite to an open source UNIX, open source silicon design tools are a prerequisite to open source hardware.
I don't know about everyone else, but IMHO the web browser is THE WORST platform to code for in existence. It amazes and depresses me how little has changed about client side web programming since IE4. Instead we have created these huge frameworks to try to hide the suck under an enormous pile of middleware. But still we are doing this fundamentally broken thing of shoehorning a language intended to describe formatted text documents (HTML) to instead describe a GUI for an application. This reminds me of IE4 and its web page dialogs.
If we truly are serious about having the web be an application platform then a new markup intended to describe cross platform application GUIs and a standard bytecode for the web is needed. Asm.js and enscripten or PNaCl both could be our new standard bytecode, both have pros and cons that I won't rehash. Honestly I'm not a huge fan of either one. But no one is trying to address the fact that HTML's layout system is designed for documents... Not for GUIs. We really need something like XUL or XAML made in to a web standard. I don't care about the politics of what language/tool we choose as long as its a good one thats open for all. I'm sick of the holy wars over tools and languages. That said JavaScript is garbage just like HTML and CSS for actual development and needs to be replaced with a sane language.
Honestly the thing that would make continuum really worth while would be if Microsoft got rid of the phone OS entirely and ported the telephony stack to the full Windows 10 OS and just install full Windows 10 on everything, including phones. Then when you enter desktop mode when you dock for phone you will be able to run Win32 apps in addition to the universal apps. With that, you will truly have a real, full computer in your pocket.
Of course this does mean that Microsoft would have to limit their phone OS to X86 CPUs, otherwise the feature would not be worthwhile. Honestly... I don't think that is as big of a deal as it sounds. Intel's smartphone chips have changed a lot in the last 2 years. If you haven't taken a look at the Zenfone 2 yet, its a great phone. You don't notice anything different between it and other high end Android phones other than the fact that is has an Intel logo on the back and it has the same features as a $600 phone for $300. Since nobody builds phones with Windows installed anymore except Microsoft, restricting the phone OS to X86 only isn't going to affect some existing OEM customer base :)
10 years ago, Intel was hinting at a massively parallel future (80 core processor rumored in development at the time)
I think the 80 core processor Intel was developing at the time eventually turned in to the Knights Corner aka Xeon Phi chip. Originally Intel developed this tech for the Larrabee project, which was intended to be a discrete GPU built out of a huge number of X86 cores. The thought was if you threw enough X86 cores at the problem, even software rendering on all those cores would be fast. As projects like llvmpipe and OpenSWR have shown, given a huge number of X86 cores this isn't as crazy of an idea as it initially sounds... but still a little crazy :) Ultimately Intel cancelled that project and decided to use that tech for super computing instead of graphics. A result of this is Intel retained the "Gen" design for their graphics core, which is a more traditional GPU design.
If it's not GPL'ed, it's not open source. And we all know what abhorrence MS harbors for GPL...
The Open Source Initiative has certified the MIT license as a valid open source license. Look I'm not a huge MS fan either, but they are using a real OSS license here. Just because MIT isn't copyleft doesn't mean its not OSS.
What you say was true of early releases of Rust. But they removed all traces of any kind of runtime for exactly this reason.
Oh cool. I'll have to give Rust a second look then!
Speaking as someone who writes firmware for a living, Rust will never be a replacement for C in its current state. C has one property that sets it apart from every other language that is higher level than assembly. It is possible to write a C program that does not need *ANY* C run-time library support. Our firmware runs on the bare metal without any OS whatsoever, so running Rust in firmware requires building all the services that the Rust run-time requires (heap, threads, etc.) and porting the Rust run-time to it.
So unless we want to write heap, threads, etc. in assembly... C is our only option for bootstrapping Rust. Since we are using C for that part of our code base... why not use it for all? The firmware I work on doesn't do a bunch of string manipulation of other things that makes a higher level language like Rust nice. Why add all that additional complexity to support Rust? By the way, anyone writing an operating system kernel is going to run in to the same thing with Rust.
It would be possible to bootstrap Rust on top of a basic kernel written in C and maybe even use it for some of the kernel code (drivers for example, like how OSX uses C++ for I/O Kit drivers), but Rust will never replace C. It would be nice if someone designed a new **Systems Programming Language** that can run without a run-time and had some of the features that newer languages do... but it seems the only thing people think about when designing new languages these days is the web and/or cloud computing.
Despite what the Rust developers claim, Rust is not a real Systems Programming Language in its current state since it requires a run-time. Its OK to have an optional run-time and for some features to stop working when its not there... but it must be optional not required.
Woah. I can't remember the last time a website actually got slashdotted.
Both the A8X and the Broadwell Core M have a TDP of ~4.5W, so they give us a good comparison between the latest and greatest ARM vs. x86 CPUs:
http://browser.primatelabs.com/geekbench3/compare/2959187?baseline=3338936
Lets compare against the nVidia Tegra K1 as well, which has a TDP of 5W vs. the Core M's 4.5W:
http://browser.primatelabs.com/geekbench3/compare/2959187?baseline=3347052
As you can see, Intel is actually competing well against the best ARM can offer in their own backyard. The A8X does ~5% better in multi-threaded workloads, it has 3 cores vs. Core M's 2 cores. Single threaded, the A8X is ~26% slower than Core M. Despite having 4 cores, the Tegra K1 has ~16% worse multi-threaded performance than the Core M with 2 cores and ~53% slower single threaded performance. When you consider most GUI/web applications are single threaded (which is mostly what people use tablets for) Broadwell Core M is the best tablet chip on the market right now. Its only going to get better with Skylake.
At the same time, ARM hasn't been able to really touch Intel's home turf in the high performance market.
On the topic on instruction sets, honestly the most important difference between x86 and ARM is having an x86 design gives you a distinct advantage in the market for computers that run Windows. Given that there is no disadvantage for x86 in any other market segment (Android, Chrome, Mac, etc.) why would Intel switch to ARM when there is only upside to x86 and no downside?
>Law of supply and demand affects salaries. Companies that have not learned this, can't find qualified candidates, because they're not paying enough.
Companies are completely aware of supply and demand. Not being able to find good candidates is the excuse they give. The real reason why companies want H1-B's is because it increases the supply of high tech labor. Increasing the supply of any good or service, keeping the demand constant will reduce the price of the good or service. This is basic ECON-101. In this case, the service being sold is high tech labor. Increasing the supply of people seeking high tech employment reduces the average wage for high tech work.
Note that this is the reason why the same people pushing for more H-1B's are also donating to public schools to improve their high tech curriculum. They are actively seeking to increase the labor supply using whatever means possible. Whats surprising is how willing they are to make such a long term investment in education "philanthropy." It will take probably ~10 years for the education investment to bear fruit. Hard to call it philanthropy when its done for an entirely self serving reason :).
I think what this benchmark really tells us is two things:
1. nVidia has not optimized their driver stack for DX12 as much as AMD has optimized for DX12
2. The performance difference between AMD and nVidia is likely a software issue, not a hardware issue (nVidia's driver has a more optimized DX11 implementation than AMD's). However, it is possible that nVidia's silicon architecture is designed to run DX11 workloads better than AMD's.
Bullet #1 make sense, AMD has been developing Mantle for years now so they likely have a more mature stack for these low level APIs. Bullet #2 also makes sense, AMD/ATI's driver has been a known weak point for a long time now.
Freemium is pretty disgusting really. Instead of just buying the game, you have to keep paying for the game constantly. You pay every time they add a new sword/gun/zombie killing plant a la "micro transactions." Honestly its almost as bad as slot machines in a vegas casino. There is a funny tongue in cheek game called DLC Quest about this... which you only have to pay for once :)