Re:64-bit computation vs. 64-bit storage
on
Asm.js Gets Faster
·
· Score: 1
That's only when the AVX2 and FMA instructions are used. I do not know of any JS engines that vectorize code to allow the use of vector extensions. Most of them just make use of the basic scalar FP instructions or even use old x87 code.
Re:Or anything running in a VM
on
Asm.js Gets Faster
·
· Score: 3, Informative
Ideal virtual machines are indistinguishable from networked servers. Most x86 VMMs don't quite reach this level of isolation, but the VMMs used on IBM's PowerPC based servers and mainframes do.
From the perspective of system security, a single compromised application risks exposing to an attacker data used by other applications which would normally be outside of the scope of the compromised application. Most of these issues can be addressed through some simple best practices such as proper use of chroot and user restrictions, but those do not scale well and do not address usability concerns. A good example is the shared hosting that grew dominant in the early 2000s while x86 virtualization was still in its infancy. It was common to see web servers with dozens if not hundreds of amateur websites running on them at once. For performance reasons a web server would have read access to all of the web data; a vulnerability in one website allowing arbitrary script execution would allow an attacker to read data belonging to other websites on the same server.
From the perspective of users, a system designed to run 100 applications from 20 different working groups does not provide a lot of room for rapid reconfiguration. Shared resource conflicts, version conflicts, permissions, mounts, network access, etc... it gets extremely messy extremely quickly. Addressing this requires a lot of administrative overhead and every additional person that is given root privileges is an additional person that can bring the entire system down.
Virtual machines on the other hand give every user their own playground, including full administrative privileges, in which they can screw around with to their hearts content without the possibility of screwing up anything else or compromising anything that is not a part of their environment. Everyone gets to be a god in their own little sandbox.
Now, that doesn't mean that the entire operating system needs to be duplicated for every single application. Certain elements such as the kernel and drivers can be factored out and applied to all environments. Solaris provides OS level virtualization in which a single kernel can manage multiple fully independent "zones" for a great deal of reduced overhead. Linux Containers is a very similar approach that has garnered some recent attention.
Re:64-bit computation vs. 64-bit storage
on
Asm.js Gets Faster
·
· Score: 4, Informative
That's the backend of the Haswell microarchitecture. Note that 4 of the 8 execution ports have integer ALUs on them, allowing for up to 4 scalar integer operations to begin execution every cycle (including multiplication). Two of these are on the same port as vector integer unit, which can be exploited for an obnoxious amount of integer math to be performed at once. There are only two scalar FP units, one for multiplication on port-0 and one for addition on port-1.
The same FP hardware is used to perform scalar, vector, and fused FP operations, but taking advantage of this requires a compiler that is smart enough to exploit those instructions in the presence of a Haswell microprocessor only and fast enough to do it quickly. Exploiting multiple identical execution units in a dynamically scheduled machine requires no extra effort on behalf of the compiler.
Microprocessors used in PCs have always been very integer heavy for practical reasons (they're just not needed for most applications), and mobile devices are even more integer heavy for power consumption reasons.
Using FP64 for all data types is obnoxiously lazy and it makes me want to strangle front end developers.
Yeah that's where I found many answers to my questions. There's no easy way to look through it and few if any solutions are catalogued or included in the wiki. Sometime over the Christmas holidays I will write a more comprehensive guide.
Altera's reference Cyclone V SX Series development kit is $1600. This includes the subscription edition of Altera's SoCEDS suite which allows for bare metal debugging over JTAG.
The SoCKit is only $300. The hardware is (nearly) identical and it is designed to be compatible with Altera's reference design at both the harware and software level. It does not come with the subscription edition of Altera's SoCEDS so users are limited to either the 30 day trial or a free licence which supports only gdb over IP for application debugging (thus restricting it to linux only).
I love the PMOD connectors on the Zed. I purchased the analog essentials kit from Maxim to play around with. The documentation and reference designs are pretty good.
The on-chip memory on the Xilinx HPS is larger (256KiB) than Altera's (64KiB) but the Altera Cyclone V S and Arria V S chips have hard memory controllers on both the HPS and FPGA side (1 on the Cyclone V FPGA, 3 on the Arria V FPGA). This is why the ZedBoard has only 512MiB of DDR3 attached to only the HPS, while the SoCKit has 2GiB of DDR3 with 1GiB attached to each of the HPS and FPGA. This allows for 2x to 4x the DDR3 bandwidth with only marginal cost in soft logic.
Both chips use AXI bridges to connect the HPS and the FPGA together, but it seems like there are some minor differences in the way that they are configured; I haven't done enough work on this aspect yet though to make a judgement call.
I'm not at all trashing the Zynq chips. Xilinx and Altera are both terrific companies.
I haven't found any hardware errata yet, just a truckload of missing, poorly written, or conflicting documentation. I'll provide you with a rough workflow that I've followed to get started. Feel free to ask me any questions.
Step1: Grab the Arrow lab material from the following link and work through them on Quartus 13.1. They're written for Quartus 13.0sp1 but they can be followed on Quartus 13.1 without issue. The only additional step is upgrading the IP cores from those packaged with 13.0sp1 to those packaged with 13.1; this will be done automatically when the sopc is opened in Qsys
Working through the hardware side will get you a usable sof file to program the FPGA. Working through the software side will get you a usable preloader. Although the SoCKit is heavily based off of Altera's reference development kit (GHRD) the preloader is different in large part due to slightly different SDRAM specifications. Attempting to use the preloader included in Altera's SoCEDS will not work.
The programming stage of the documentation is a bit flawed. The reference configuration assumes a single JTAG device, but there can be more. At a minimum there will be one for the HPS, but a bank of two dipswitches on the board can enable JTAG for the HPS itself and any devices connected via HSMC. Just use autodetect to pick up all JTAG devices and program the SOF file to the FPGA device, it's very clear as to which is which.
Next, grab the github repositories for the linux-socfpga (kernel), poky-socfpga (base filesystem), and u-boot-socfpga (bootloader). Grab the latest version tagged with '-rel'. I used the following:
kernel: socfpga-3.9-rel
u-boot: socfpga_v2013.01.01-rel
poky: danny-altera-rel
The wiki on rocketboards can be followed to install the dependencies and begin compilation. I can verify that everything builds nicely on CentOS 6.5 without much fuss, Ubuntu is extremely problematic so I would avoid it.
If you look at the SD Card image that ships with the SoCKit you'll notice that it has a FAT filesystem with two files on it, socfpga.dtb and uImage. These are the device-tree-blob, and linux-kernel-image respectively. The kernel is in a u-boot image format, which is simply a zImage with an additional header. The bootloader that ships with Terasic's SD card image uses an early 2012 version of u-boot and does not support booting directly from a zImage. Support for this (bootz command) is present in the 2013.01.01 release of u-boot so it is no longer necessary to attach the additional header to the kernel image. Just configure and compile the kernel as a zImage as they do in the wiki.
An additional step is missing in the wiki (at least it was last time I looked). The dtb is tightly coupled to the kernel version. Using a dtb from the terasic reference SD image will work for kernel version 3.7, but it will not work for kernel 3.9 or above. The reference one created by Altera's sopc2dts tool is crap and won't work either. However, a working dtb has been included in the linux-socfpga tree under arch/arm/boot/dts/socfpga_cyclone5.dts. This can be compiled to a dtb either through the dtc tool itself, or in-situ by running 'make ARCH=arm dtbs'. This is good enough to get started with, but if you add additional memory mapped devices to your system you will have to modify it by hand and recompile it.
NOTE: the socfpga_cyclone5.dts file exists in the 3.9-rel tree, but has been replaced and expanded in master by one specifically tailored towards the SoCKit. I haven't looked at this yet, it's on my todo list. You may wish to check it out.
OTHER NOTE:The bootloader will look for socfpga.dtb by default. You can change the name of the file that it looks for by tweaking the bootloader environment settings (this is good practice) or you can change the name of the file when you copy it to the filesystem.
The SoCKit is definitely the beefier of the two, as the Altera Cyclone V SX series FPGAs are far more powerful than their Zynq-7000 series counterparts.
However, the SoCKit has the most obnoxiously bad documentation that I've ever seen. The reference material from Arrow is extremely thin yet somehow still manages to have spelling mistakes in it that would prevent it from functioning if certain functions were enabled. Terasic's material "works" but Terasic does not include any documentation on the HPS whatsoever, just a prebuilt image and some C code to go with it.
I've spent the better part of the past 3 weeks just figuring everything out on my own. Altera's documentation is rock solid, but that only covers the FPGA itself, not the peripherals. Today was spent figuring out how the various clock sources are connected to the FPGA. Despite offering the exact same board in the exact same configuration, Arrow and Terasic provide conflicting and equally useless documentation. Sometime in the next couple of days I'm going to go probing at it with my scope.
The silver lining though is that I've been documenting that I've done, so I should be able to compile a very comprehensive and updated getting started guide in the near future. The ones on the RocketBoards wiki just don't cut it.
The Zedboard is accompanied by much superior documentation. The board design isn't as nice, but it's not as irritating to work with.
I have no doubt that the hardware-based random number generators works in the exact fashion that their manufacturers have specified. Given the amount of scrutiny that is presently being placed upon them I am certain that any sort of pattern in the entropy under normal operation would have been discovered by now.
However, this does not preclude the existence of a backdoor which alters normal operation. Setup certain registers in a particular fashion, call an undocumented instruction, and boom, the random number generator's entropy drops by several orders of magnitude. Not enough to be noticeable, but enough to make attacking it easier. There are however several problems with this:
1. It would require that the machine be compromised locally, with at least user level privilege. Security is mostly moot at this point and there are far better attack vectors available.
2. It would require sneaking undocumented instructions past dozens of engineers working at multiple levels of design and validation. Working backdoors into software is easy and can even slide under the radar if done properly, but in hardware they would stick out like a sore thumb. I have a hard time believing that the existence of a deliberate backdoor in hardware from a company the size of Intel would go unnoticed for long, or that everyone involved would be willing to keep it a secret.
3. There are far better attack vectors available to compromise cryptographic functions at the hardware level than messing with the RNG. Critics have taken a tunnel vision approach to the possibility that RDRAND and other hardware based random number generators may be compromised as they cannot be audited, yet completely overlook that nothing else about the hardware can be audited either. There are whole layers of management functions built into Intel's chips which could provide undocumented backdoors.
The ARM microarchitecture is hardly complex. It's very simple, employing only minor variations on technology that predates it by decades. Most computer engineers would call the bulk of the ARMv7 microarchitecture and other ARM IP obvious to one skilled in the trade. In fact, almost all straight RISC microprocessors follow a very similar architecture. ARM Holdings, despite manufacturing nothing, has wielded their patent portfolio offensively against companies and even bought a large stake in a consortium that acquired MIPS patents that ARM most likely infringed upon. What ARM has done very well is package it all together in a very verbose and detailed IP portfolio that can be instantiated, simulated, and fabricated with ease by licencors. I imagine that many of their patents could be challenged successfully, but no one has any motivation to do so.
You will not get any argument from me about Rambus being a patent troll, but it's important to remember that while usefulness is a requirement for patentability, marketability is not.
Add to that the fact is that Rambus itself does not manufacture anything -- it's a technology licencing house that has a few engineers and an army of lawyers -- and you get a perfect example of a patent troll.
ARM Holdings PLC is an R&D company that doesn't manufacture anything. They generate all of their revenue through licencing IP to third parties whom in turn do the manufacturing. I do not see anyone calling them a patent troll.
Rambus Inc. is definitely a shady corporation but simply failing to manufacture products with IP that one owns and initiating litigation against those who infringe upon it does not automatically make one a patent troll.
That's the traditional way, yes. There's a more recent method (which may not involve using the L3 band for communication) that operates by detecting atmospheric disturbances caused by shockwaves and electron emission in the atmosphere. The double flash will not detect subterranean tests, but looking for radio communication interference will. It's a roundabout method but researchers were able to detect North Korea's subterranean tests this way.
The L3 band is the transmission band used to communicate with the base stations on the ground. The disturbances themselves are detected using the satellite's onboard instruments.
The GPS satellites are incredibly sensitive to atmospheric disturbances and can detect anything that causes interference with radio transmissions, such as electron emission from a subterranean nuclear test. It is not necessary to detect the emission source itself, just the effects of the emission.
In some cases yes. The L3 band used by the GPS satellite system is used to detect and report nuclear detonations, but I do not know if a small amount of cobalt-60 would be detected by a satellite 26,000 kilometres away.
.NET is already an extremely verbose platform that is many years ahead of its competition. If it seems like they've neglected it a bit that may be because there's currently either no motivation to add new features to it, or there's currently not enough features worth adding to it that would justify an incremental release and all of the accompanying documentation. I'd rather that they take a step back, let it mature a bit, and clean things up a bit if necessary.
The first amendment has nothing to do with this. It simply prevents the government from creating any law which abridges the freedom of speech. The freedom to speak about certain matters is something that the government cannot take away from you without a damn good reason, however the freedom to speak about certain matters is something that individuals can sign away on their own.
Non disclosure agreements are incredibly common contracts in the business world that in effect are in effect unilateral or bilateral restrictions on one's freedom of speech. Breaching an NDA can result in civil liability as well as various criminal offences under some trade secret acts.
NDAs have been found to be enforceable many times in the past as they are often necessary to protect sensitive private information and provide a legal vehicle for redress in the event of such disclosure. However, I agree that a judge would find that a clause prohibiting criticism of a product would be unconscionable, but not for reasons of violating the first amendment.
Attorneys cannot make arguments for matters of fact that are not in dispute. As far as this trial is concerned there is no question as to whether or not Samsung infringed on the products that are the subject of the trial, that was settled by the previous jury. The only question is what the actual damages are.
This is a retrial ordered by the trial court to reassess damages on products that the previous jury found that they did infringe. The trial judge found that the jury used a legally impermissible method of calculating damages, and that damages had to be reassessed in those cases. If the appeals court later finds that the entire trial needs to be done over due to the fact that the judge and jury dropped the ball entirely then infringement can be reassessed at that point.
Samsung can't argue that they didn't infringe on the patents, that was already settled in the case. This was simply a retrial on assessment of damages. Samsung can (and is) appealing the original verdict and will most likely appeal the new damages as well.
Nokia's market share was already dropping rapidly when Stephen Elop was brought on board. Symbian was too far behind iOS and other competing operating systems, and was facing delays in catching up.
Slashdot Mirror
wrong architecture.
Cost sensitive embedded systems use ARM based microprocessors to which this is not applicable.
I used to have pet rats. Rats will eat anything
That's only when the AVX2 and FMA instructions are used. I do not know of any JS engines that vectorize code to allow the use of vector extensions. Most of them just make use of the basic scalar FP instructions or even use old x87 code.
Ideal virtual machines are indistinguishable from networked servers. Most x86 VMMs don't quite reach this level of isolation, but the VMMs used on IBM's PowerPC based servers and mainframes do.
From the perspective of system security, a single compromised application risks exposing to an attacker data used by other applications which would normally be outside of the scope of the compromised application. Most of these issues can be addressed through some simple best practices such as proper use of chroot and user restrictions, but those do not scale well and do not address usability concerns. A good example is the shared hosting that grew dominant in the early 2000s while x86 virtualization was still in its infancy. It was common to see web servers with dozens if not hundreds of amateur websites running on them at once. For performance reasons a web server would have read access to all of the web data; a vulnerability in one website allowing arbitrary script execution would allow an attacker to read data belonging to other websites on the same server.
From the perspective of users, a system designed to run 100 applications from 20 different working groups does not provide a lot of room for rapid reconfiguration. Shared resource conflicts, version conflicts, permissions, mounts, network access, etc... it gets extremely messy extremely quickly. Addressing this requires a lot of administrative overhead and every additional person that is given root privileges is an additional person that can bring the entire system down.
Virtual machines on the other hand give every user their own playground, including full administrative privileges, in which they can screw around with to their hearts content without the possibility of screwing up anything else or compromising anything that is not a part of their environment. Everyone gets to be a god in their own little sandbox.
Now, that doesn't mean that the entire operating system needs to be duplicated for every single application. Certain elements such as the kernel and drivers can be factored out and applied to all environments. Solaris provides OS level virtualization in which a single kernel can manage multiple fully independent "zones" for a great deal of reduced overhead. Linux Containers is a very similar approach that has garnered some recent attention.
Take a look at the image at the following link
http://www.anandtech.com/show/6355/intels-haswell-architecture/8
That's the backend of the Haswell microarchitecture. Note that 4 of the 8 execution ports have integer ALUs on them, allowing for up to 4 scalar integer operations to begin execution every cycle (including multiplication). Two of these are on the same port as vector integer unit, which can be exploited for an obnoxious amount of integer math to be performed at once. There are only two scalar FP units, one for multiplication on port-0 and one for addition on port-1.
The same FP hardware is used to perform scalar, vector, and fused FP operations, but taking advantage of this requires a compiler that is smart enough to exploit those instructions in the presence of a Haswell microprocessor only and fast enough to do it quickly. Exploiting multiple identical execution units in a dynamically scheduled machine requires no extra effort on behalf of the compiler.
Microprocessors used in PCs have always been very integer heavy for practical reasons (they're just not needed for most applications), and mobile devices are even more integer heavy for power consumption reasons.
Using FP64 for all data types is obnoxiously lazy and it makes me want to strangle front end developers.
Yeah that's where I found many answers to my questions. There's no easy way to look through it and few if any solutions are catalogued or included in the wiki. Sometime over the Christmas holidays I will write a more comprehensive guide.
Altera's reference Cyclone V SX Series development kit is $1600. This includes the subscription edition of Altera's SoCEDS suite which allows for bare metal debugging over JTAG.
The SoCKit is only $300. The hardware is (nearly) identical and it is designed to be compatible with Altera's reference design at both the harware and software level. It does not come with the subscription edition of Altera's SoCEDS so users are limited to either the 30 day trial or a free licence which supports only gdb over IP for application debugging (thus restricting it to linux only).
I love the PMOD connectors on the Zed. I purchased the analog essentials kit from Maxim to play around with. The documentation and reference designs are pretty good.
The on-chip memory on the Xilinx HPS is larger (256KiB) than Altera's (64KiB) but the Altera Cyclone V S and Arria V S chips have hard memory controllers on both the HPS and FPGA side (1 on the Cyclone V FPGA, 3 on the Arria V FPGA). This is why the ZedBoard has only 512MiB of DDR3 attached to only the HPS, while the SoCKit has 2GiB of DDR3 with 1GiB attached to each of the HPS and FPGA. This allows for 2x to 4x the DDR3 bandwidth with only marginal cost in soft logic.
Both chips use AXI bridges to connect the HPS and the FPGA together, but it seems like there are some minor differences in the way that they are configured; I haven't done enough work on this aspect yet though to make a judgement call.
I'm not at all trashing the Zynq chips. Xilinx and Altera are both terrific companies.
I haven't found any hardware errata yet, just a truckload of missing, poorly written, or conflicting documentation. I'll provide you with a rough workflow that I've followed to get started. Feel free to ask me any questions.
Step1: Grab the Arrow lab material from the following link and work through them on Quartus 13.1. They're written for Quartus 13.0sp1 but they can be followed on Quartus 13.1 without issue. The only additional step is upgrading the IP cores from those packaged with 13.0sp1 to those packaged with 13.1; this will be done automatically when the sopc is opened in Qsys
http://www.arrownac.com/solutions/sockit/files/SoCKIT_Materials.zip
Working through the hardware side will get you a usable sof file to program the FPGA. Working through the software side will get you a usable preloader. Although the SoCKit is heavily based off of Altera's reference development kit (GHRD) the preloader is different in large part due to slightly different SDRAM specifications. Attempting to use the preloader included in Altera's SoCEDS will not work.
The programming stage of the documentation is a bit flawed. The reference configuration assumes a single JTAG device, but there can be more. At a minimum there will be one for the HPS, but a bank of two dipswitches on the board can enable JTAG for the HPS itself and any devices connected via HSMC. Just use autodetect to pick up all JTAG devices and program the SOF file to the FPGA device, it's very clear as to which is which.
Next, grab the github repositories for the linux-socfpga (kernel), poky-socfpga (base filesystem), and u-boot-socfpga (bootloader). Grab the latest version tagged with '-rel'. I used the following:
kernel: socfpga-3.9-rel
u-boot: socfpga_v2013.01.01-rel
poky: danny-altera-rel
The wiki on rocketboards can be followed to install the dependencies and begin compilation. I can verify that everything builds nicely on CentOS 6.5 without much fuss, Ubuntu is extremely problematic so I would avoid it.
If you look at the SD Card image that ships with the SoCKit you'll notice that it has a FAT filesystem with two files on it, socfpga.dtb and uImage. These are the device-tree-blob, and linux-kernel-image respectively. The kernel is in a u-boot image format, which is simply a zImage with an additional header. The bootloader that ships with Terasic's SD card image uses an early 2012 version of u-boot and does not support booting directly from a zImage. Support for this (bootz command) is present in the 2013.01.01 release of u-boot so it is no longer necessary to attach the additional header to the kernel image. Just configure and compile the kernel as a zImage as they do in the wiki.
An additional step is missing in the wiki (at least it was last time I looked). The dtb is tightly coupled to the kernel version. Using a dtb from the terasic reference SD image will work for kernel version 3.7, but it will not work for kernel 3.9 or above. The reference one created by Altera's sopc2dts tool is crap and won't work either. However, a working dtb has been included in the linux-socfpga tree under arch/arm/boot/dts/socfpga_cyclone5.dts. This can be compiled to a dtb either through the dtc tool itself, or in-situ by running 'make ARCH=arm dtbs'. This is good enough to get started with, but if you add additional memory mapped devices to your system you will have to modify it by hand and recompile it.
NOTE: the socfpga_cyclone5.dts file exists in the 3.9-rel tree, but has been replaced and expanded in master by one specifically tailored towards the SoCKit. I haven't looked at this yet, it's on my todo list. You may wish to check it out.
OTHER NOTE:The bootloader will look for socfpga.dtb by default. You can change the name of the file that it looks for by tweaking the bootloader environment settings (this is good practice) or you can change the name of the file when you copy it to the filesystem.
Expand the compiled
I have both the Zedboard and the SoCKit
The SoCKit is definitely the beefier of the two, as the Altera Cyclone V SX series FPGAs are far more powerful than their Zynq-7000 series counterparts.
However, the SoCKit has the most obnoxiously bad documentation that I've ever seen. The reference material from Arrow is extremely thin yet somehow still manages to have spelling mistakes in it that would prevent it from functioning if certain functions were enabled. Terasic's material "works" but Terasic does not include any documentation on the HPS whatsoever, just a prebuilt image and some C code to go with it.
I've spent the better part of the past 3 weeks just figuring everything out on my own. Altera's documentation is rock solid, but that only covers the FPGA itself, not the peripherals. Today was spent figuring out how the various clock sources are connected to the FPGA. Despite offering the exact same board in the exact same configuration, Arrow and Terasic provide conflicting and equally useless documentation. Sometime in the next couple of days I'm going to go probing at it with my scope.
The silver lining though is that I've been documenting that I've done, so I should be able to compile a very comprehensive and updated getting started guide in the near future. The ones on the RocketBoards wiki just don't cut it.
The Zedboard is accompanied by much superior documentation. The board design isn't as nice, but it's not as irritating to work with.
yeah because Terrorists have proven to be so incredibly afraid of dying
I have no doubt that the hardware-based random number generators works in the exact fashion that their manufacturers have specified. Given the amount of scrutiny that is presently being placed upon them I am certain that any sort of pattern in the entropy under normal operation would have been discovered by now.
However, this does not preclude the existence of a backdoor which alters normal operation. Setup certain registers in a particular fashion, call an undocumented instruction, and boom, the random number generator's entropy drops by several orders of magnitude. Not enough to be noticeable, but enough to make attacking it easier. There are however several problems with this:
1. It would require that the machine be compromised locally, with at least user level privilege. Security is mostly moot at this point and there are far better attack vectors available.
2. It would require sneaking undocumented instructions past dozens of engineers working at multiple levels of design and validation. Working backdoors into software is easy and can even slide under the radar if done properly, but in hardware they would stick out like a sore thumb. I have a hard time believing that the existence of a deliberate backdoor in hardware from a company the size of Intel would go unnoticed for long, or that everyone involved would be willing to keep it a secret.
3. There are far better attack vectors available to compromise cryptographic functions at the hardware level than messing with the RNG. Critics have taken a tunnel vision approach to the possibility that RDRAND and other hardware based random number generators may be compromised as they cannot be audited, yet completely overlook that nothing else about the hardware can be audited either. There are whole layers of management functions built into Intel's chips which could provide undocumented backdoors.
The ARM microarchitecture is hardly complex. It's very simple, employing only minor variations on technology that predates it by decades. Most computer engineers would call the bulk of the ARMv7 microarchitecture and other ARM IP obvious to one skilled in the trade. In fact, almost all straight RISC microprocessors follow a very similar architecture. ARM Holdings, despite manufacturing nothing, has wielded their patent portfolio offensively against companies and even bought a large stake in a consortium that acquired MIPS patents that ARM most likely infringed upon. What ARM has done very well is package it all together in a very verbose and detailed IP portfolio that can be instantiated, simulated, and fabricated with ease by licencors. I imagine that many of their patents could be challenged successfully, but no one has any motivation to do so.
You will not get any argument from me about Rambus being a patent troll, but it's important to remember that while usefulness is a requirement for patentability, marketability is not.
Add to that the fact is that Rambus itself does not manufacture anything -- it's a technology licencing house that has a few engineers and an army of lawyers -- and you get a perfect example of a patent troll.
ARM Holdings PLC is an R&D company that doesn't manufacture anything. They generate all of their revenue through licencing IP to third parties whom in turn do the manufacturing. I do not see anyone calling them a patent troll.
Rambus Inc. is definitely a shady corporation but simply failing to manufacture products with IP that one owns and initiating litigation against those who infringe upon it does not automatically make one a patent troll.
That's the traditional way, yes. There's a more recent method (which may not involve using the L3 band for communication) that operates by detecting atmospheric disturbances caused by shockwaves and electron emission in the atmosphere. The double flash will not detect subterranean tests, but looking for radio communication interference will. It's a roundabout method but researchers were able to detect North Korea's subterranean tests this way.
The L3 band is the transmission band used to communicate with the base stations on the ground. The disturbances themselves are detected using the satellite's onboard instruments.
The GPS satellites are incredibly sensitive to atmospheric disturbances and can detect anything that causes interference with radio transmissions, such as electron emission from a subterranean nuclear test. It is not necessary to detect the emission source itself, just the effects of the emission.
In some cases yes. The L3 band used by the GPS satellite system is used to detect and report nuclear detonations, but I do not know if a small amount of cobalt-60 would be detected by a satellite 26,000 kilometres away.
.NET is already an extremely verbose platform that is many years ahead of its competition. If it seems like they've neglected it a bit that may be because there's currently either no motivation to add new features to it, or there's currently not enough features worth adding to it that would justify an incremental release and all of the accompanying documentation. I'd rather that they take a step back, let it mature a bit, and clean things up a bit if necessary.
The first amendment has nothing to do with this. It simply prevents the government from creating any law which abridges the freedom of speech. The freedom to speak about certain matters is something that the government cannot take away from you without a damn good reason, however the freedom to speak about certain matters is something that individuals can sign away on their own.
Non disclosure agreements are incredibly common contracts in the business world that in effect are in effect unilateral or bilateral restrictions on one's freedom of speech. Breaching an NDA can result in civil liability as well as various criminal offences under some trade secret acts.
NDAs have been found to be enforceable many times in the past as they are often necessary to protect sensitive private information and provide a legal vehicle for redress in the event of such disclosure. However, I agree that a judge would find that a clause prohibiting criticism of a product would be unconscionable, but not for reasons of violating the first amendment.
No, they cant.
Attorneys cannot make arguments for matters of fact that are not in dispute. As far as this trial is concerned there is no question as to whether or not Samsung infringed on the products that are the subject of the trial, that was settled by the previous jury. The only question is what the actual damages are.
This is a retrial ordered by the trial court to reassess damages on products that the previous jury found that they did infringe. The trial judge found that the jury used a legally impermissible method of calculating damages, and that damages had to be reassessed in those cases. If the appeals court later finds that the entire trial needs to be done over due to the fact that the judge and jury dropped the ball entirely then infringement can be reassessed at that point.
Samsung can't argue that they didn't infringe on the patents, that was already settled in the case. This was simply a retrial on assessment of damages. Samsung can (and is) appealing the original verdict and will most likely appeal the new damages as well.
The networks carrying the traffic belong to the ISPs but the data travelling across the networks does not.
This is already the case.
Most of the big Linux Kernel devs are paid employees of Redhat and IBM
OnLive was such a bastion of success wasn't it?
It's a limitation implemented in firmware/microcode for marketing purposes.
The Titan, GTX 780 and GTX 780 Ti all use the same physical chip.
Ding!
Nokia's market share was already dropping rapidly when Stephen Elop was brought on board. Symbian was too far behind iOS and other competing operating systems, and was facing delays in catching up.