As someone who lives in Mountain View, I'd like to second this post. Google WiFi has never worked well. In my experience it hardly ever worked at all. I'd be happy to be rid of it.
Uh, Syria was until quite recently one of our supporters in the region. We've had generally decent to good relations with the Assad regime. It cooled a bit since he started killing his people, but we tend to take a dim view of those who would kill their people because they started talkng democracy.
You might be confusing Syria with Jordan, because Syria was most definitely not our friend at any point. They have been a client state of the Soviet Union / Russia for many years, their Alawite (a form of Shia) minority runs the military dictatorship that is sponsored by Iran, and it props up Hizbollah in Lebanon. The US has had an arms and technology embargo on Syria since at least the 70's, there are no direct flights between the two countries, and there are no banking ties between them.
A laser of this type is almost always a chemical laser because that is one of the best ways to portably produce that much energy in a hurry. The drawbacks of this are 1) the laser reactant supply needs to be reloaded after every shot or few shots. This is time consuming. 2) toxic chemical byproducts of the power-generating reaction. If you're defending a base in the middle of the desert, this may not be an issue. If you're defending land that you care about, like your home town, it is a big problem.
If the laser is battery-powered instead then prepare to wait a long time between firings for it to charge. Even a nuclear reactor on an aircraft carrier doesn't deliver the kind of wattage this needs in a burst, there will need to be a charge-discharge system.
Until the power problems are solved, don't expect to be seeing too many lasers shooting down missiles.
For what definition of "faster than"? A7 is a pretty weak core. It was optimized for very low power and die area, not for high performance. Tegra3 uses Cortex-A9, which is an older design but actually faster if all else is held equal (same clock speed, equivalent memory subsystem).
(The reason you see quad A7 popping up in cheap Allwinner SoCs is that A7 is tiny. Really tiny. Area has a direct relationship with cost in semiconductor manufacturing. Also, ARM probably charges lower per-unit royalties for smaller / lower performance cores like the A7.)
Someone mod this guy up. A7 is a single issue, in-order core with basically no frills. An A9 like in the Tegra 3 is a triple issue out of order processor with a much faster FPU. It blows an A7 away in performance by a wide margin, although it is a much larger and more expensive chip.
These are cheap for a reason, and they're unpopular in the rest of the world for a reason.
The Allwinner chips used in these tablets are all ARM Cortex-A8 based. A Cortex-A8 is basically unfit for a tablet. The lowest end tablets sold by Apple, Samsung, Motorola, Sony, Acer, and Asus 4 years ago didn't have a CPU this slow. Just because they can get away with selling these in China doesn't mean that they are worth anything.
"Don't be evil" is the greatest marketing line in the history of technology because so many doe-eyed nerds wholeheartedly believed an advertising company has their best interests in mind.
Intel brings x86 compatibility. But that's no benefit on mobile, and will often be a slight liability.
It's actually a massive liability. I can boot an ARM Cortex-A9 in 1000 lines of assembly. An Atom requires a multi-megabyte binary blog delivered by Intel (source unavailable) to simple turn on an Atom. And yes, it does start out in 16-bit real mode as if anyone wants that. Can you guess which one of these is more debuggable?
And of course, the ARM architecture is offered by multiple makers, in all kinds of configurations of core types and numbers, clock speeds and so on. With Intel you get what one single company decides to offer, and that's it. Not directly relevant to us consumers of course, but it does mean it's more likely the ARM set-up in your phone or tablet is adapted specifically for that hardware, not a more generic one-size-fits-all spec.
Today Intel sells three versions of the same desktop chip; a high end one with all of the features enabled, a midrange one with some features disabled, and a low end one with most features disabled. Device makes know that once Intel is in a position of strength, they will do to mobile chips exactly what they are doing to desktop chips today. Let's look at one feature: SHA hashing engine. Intel Core i7 devices have this built in. Core i3 also has this but disables it. What if you want a low end SoC with a SHA engine? Any ARM vendor will sell you one, SHA engines are cheap and easy and everyone has one. Intel makes you pay for the high end part just to get a minor feature. Multiply this by all of the other SoC components and you'll see why nobody wants Intel to be in the lead. With ARM, chip vendors are competing on features, performance, and price. Nobody is picking ARM the company, they are picking the ARM ecosystem of chip designers and chip fabricators where everyone competes.
It has a lot of BSD code in it and continues to share code with the other BSDs.
Really? I was under the impression that Apple do not distribute any source code for Darwin on ARM. Please show me where I can obtain the XNU ARM kernel source that is used in iOS.
Why would you need that? The platform-specific part of the kernel is a fairly minor part of the overall code. There's a lot more code investment in the VM, the FS, the network stack, and other major kernel subsystems, which are all generic code and distributed to the public, than the specific implementations of low level locks, interrupts, and page table map managers. The fact that we can't build and run XNU on ARM doesn't mean that we can't share code with it.
There seem to be some uninformed posters here, so here is the OS X relationship to BSD: The OS X/iOS kernel is based on Mach, which is a microkernel mashed together with a BSD kernel. It has a lot of BSD code in it and continues to share code with the other BSDs. It has features borrowed from BSD such as DTrace, PF firewall, file system support (including ZFS before it was removed), the networking subsystem, kqueue, jails, and others. While Mach is fundamentally different in some ways, to a POSIX binary it looks and feels just like any other BSD system.
The OS X userland is also based on BSD and was originally derived from FreeBSD. It uses the BSD libc and many of the command line tools are from the BSD world (from grep to ssh). It also includes some GNU tools, such as bash. Apple is actively working on replacing many of these, and they recently dropped GCC and GDB and replaced them with Clang and LLDB.
Oh god. Imagine if developer unions do happen and then I'd have to choose between working at a unionized company full of idiots or working at a non-union company that is staffed with Libertarians. I'd probably quit programming forever.
It does sound like fun and I would enjoy it given the right working conditions, though I imagine these are highly unlikely to be found in a military operation.
However, no lawyer can get you the guarantee you're looking for. If you are a male and a United States citizen, you'll remember having registered for Selective Service ("The Draft") before your 18th birthday. Under the right conditions any registered person can be called up for service, all it takes is an act of Congress.
In the first half of next year, there should be three almost totally independent[1] implementations of the ARMv8 architecture, with the Cortex A50 appearing later in the year.
Can you name the three vendors? Qualcomm for sure. Marvell seems likely. Nvidia says they will have a chip out, but I have serious doubts about their ability to deliver.
ARMv8 is not eliminating them, it's reducing the number of instructions that have them. Conditional instructions are useful because you can eliminate branches and so keep the pipeline full. For example, consider this contrived example:
if (a < b)
a++;
On ARMv7 and earlier, this would be a conditional add. The pipeline would always be full, the add would always be executed, but the result would only be retired if the condition is true. On MIPS, it would be a branch (complete with the insanity known as branch delay slots, which if you look at the diassembly of most MIPS code typically means with a nop, so you get to waste some i-cache as well) and if it's mispredicted then you get a pipeline stall.
On ARMv8, you don't have a conditional add, but you do have a conditional register-register move and you have twice as many registers. The compiler would still issue the add instruction and then would do a conditional move to put it in the result register. From the compiler perspective, this means that you can lower PHI nodes from your SSA representation directly to conditional moves in a lot of cases.
Basically, 32-bit ARM is designed for assembly writers, ARMv8 is designed for compilers. As a compiler writer, it's hands-down the best ISA I've worked with, although I would prefer to write assembly by hand for ARMv7. I wouldn't want to do either with MIPS, although I currently am working on MIPS-based CPU with some extra extensions.
Actually, ARM's reasoning is that modern branch predictors on high end AP's can do a good enough job of following a test and branch and keeping the pipeline(s) full that there is very little value in conditional instructions on future chips. It's hard to cause a pipeline stall or bubble by branching a few instructions forward or back on these CPUs since they are decoding well in advance of the execution pipelines. Added to that, there is an energy cost in executing an instruction and throwing away the result. Obviously, not all cases are wins. In the example you noted, a register to register mov on a register-renaming system is basically a 0-cycle operation (never makes it out of the instruction decoder), so it's hard to do better than that.
This is a reference to an older quote by Khomeini, but in Khomeini's days Iran was an ally of Israel. The alliance was broken off after the 1990 gulf war, because with Iraq gone and the USSR gone Israel had to change its strategy and Iran became a regional competitor.
I stopped reading after this sentence since it is so wrong, I assume the rest of it is also drivel. Israel and Iran were allies up until the Islamic revolution of 1979 in which Khomeini took power. You may have heard about the Iran hostage crisis, which happened at the same time when Iran's friendly relationship with the US was similarly dissolved. The Islamic council of Iran, which still rules today, has always been hostile to the US and Israel
This is a huge deal for developers since the iPad and iPhone/touch are now running the same software release. This means that developers no longer needs to target iOS 3.2 as the lowest common denominator for all devices, and can instead start using the new 4.x features (assuming they don't care about the very first generation iPhone/touch).
This is a tech blog. This was a story about technology and abuse of freedom of speech. This guy is trying to change the discussion to push his agenda when Israel was in no way involved in this story. Observe his obvious ploy and ignore it.
Every time Slashdot has a story of EFI, we get a thousand uninformed posts about what it is, isn't, what it should do and why it sucks. As someone who has worked on EFI for years, let me clear them up for you:
1) EFI was designed by Intel as a replacement for BIOS. UEFI (edk2) is the second generation EFI, and is open source (see: http://tianocore.sourceforge.net). Intel delivers all of their boot support code as EFI drivers these days.
2) EFI is NOT a graphical interface. Some Chinese motherboard makers created terrible graphical configuration applications for it. Apple created a pretty nice boot selector. It can just as easily "post" and give you a console-mode menu like you're used to.
3) EFI is very common. All Apple computers use it. Most PC (Windows / Linux) laptops use it (your laptop probably does if it was made in the last 4 years). EFI drops into BIOS emulation mode after boot because Windows doesn't support it.
4) EFI machines generally allocate a small EFI partition on the hard drive, particularly if they use GPT. All Intel-based machines boot from flash memory and would successfully boot without this partition. This partition is for additional EFI firmware volumes or drivers that can be dynamically loaded.
5) EFI is much better than BIOS. It runs in full 32/64 bit mode. It can dynamically load drivers built into the ROM of your hardware (like a video card) and therefore doesn't have to rely on ancient backward-compatibility modes. It can run "apps", like a safe firmware updater so you don't have to boot your PC with a DOS boot disk to update the firmware. It can communicate a lot of configuration information to the OS and even provide hooks for some low level hardware-specific drivers. It can do things like boot from a network-shared CD-ROM drive or from a disk image stored on a USB stick (without resorting to making bootable partitions and jumping through a bunch of hoops like your average Linux USB stick). EFI can read FAT, NTFS, EXT2, HFS+ filesystems and boot the kernel directly from there (and the initrd image) without involving grub or other second stage boot loader. It can boot your GPT-tagged disks in your chosen order no matter what order you changed them around (take your boot drive, move it to a USB enclosure, boot from it).
Booting Intel machines is really fucking complicated, and EFI makes it much simpler.
For example, side by side, the Android browser in Froyo as running on a Nexus One has been demonstrated to be faster than the iPhone 3GS and the iPad despite the fact that they are both based on Webkit.
The Nexus One has a 1 GHz processor and 512 MB of RAM, whereas the 3GS has a 600 MHz (both ARM Cortex A8) and 256 MB of RAM. The fact that up until Froyo the browser didn't run faster should be quite embarrassing.
Slashdot Mirror
As someone who lives in Mountain View, I'd like to second this post. Google WiFi has never worked well. In my experience it hardly ever worked at all. I'd be happy to be rid of it.
Uh, Syria was until quite recently one of our supporters in the region. We've had generally decent to good relations with the Assad regime. It cooled a bit since he started killing his people, but we tend to take a dim view of those who would kill their people because they started talkng democracy.
You might be confusing Syria with Jordan, because Syria was most definitely not our friend at any point. They have been a client state of the Soviet Union / Russia for many years, their Alawite (a form of Shia) minority runs the military dictatorship that is sponsored by Iran, and it props up Hizbollah in Lebanon. The US has had an arms and technology embargo on Syria since at least the 70's, there are no direct flights between the two countries, and there are no banking ties between them.
CNN's comments are equally terrible. It's hard to believe a reputable news organization allows them on its website.
Cost is not a big issue. The big issue is power.
A laser of this type is almost always a chemical laser because that is one of the best ways to portably produce that much energy in a hurry. The drawbacks of this are
1) the laser reactant supply needs to be reloaded after every shot or few shots. This is time consuming.
2) toxic chemical byproducts of the power-generating reaction. If you're defending a base in the middle of the desert, this may not be an issue. If you're defending land that you care about, like your home town, it is a big problem.
If the laser is battery-powered instead then prepare to wait a long time between firings for it to charge. Even a nuclear reactor on an aircraft carrier doesn't deliver the kind of wattage this needs in a burst, there will need to be a charge-discharge system.
Until the power problems are solved, don't expect to be seeing too many lasers shooting down missiles.
Both are faster than fastest Tegra3.
For what definition of "faster than"? A7 is a pretty weak core. It was optimized for very low power and die area, not for high performance. Tegra3 uses Cortex-A9, which is an older design but actually faster if all else is held equal (same clock speed, equivalent memory subsystem).
(The reason you see quad A7 popping up in cheap Allwinner SoCs is that A7 is tiny. Really tiny. Area has a direct relationship with cost in semiconductor manufacturing. Also, ARM probably charges lower per-unit royalties for smaller / lower performance cores like the A7.)
Someone mod this guy up. A7 is a single issue, in-order core with basically no frills. An A9 like in the Tegra 3 is a triple issue out of order processor with a much faster FPU. It blows an A7 away in performance by a wide margin, although it is a much larger and more expensive chip.
These are cheap for a reason, and they're unpopular in the rest of the world for a reason.
The Allwinner chips used in these tablets are all ARM Cortex-A8 based. A Cortex-A8 is basically unfit for a tablet. The lowest end tablets sold by Apple, Samsung, Motorola, Sony, Acer, and Asus 4 years ago didn't have a CPU this slow. Just because they can get away with selling these in China doesn't mean that they are worth anything.
"Don't be evil" is the greatest marketing line in the history of technology because so many doe-eyed nerds wholeheartedly believed an advertising company has their best interests in mind.
Intel brings x86 compatibility. But that's no benefit on mobile, and will often be a slight liability.
It's actually a massive liability. I can boot an ARM Cortex-A9 in 1000 lines of assembly. An Atom requires a multi-megabyte binary blog delivered by Intel (source unavailable) to simple turn on an Atom. And yes, it does start out in 16-bit real mode as if anyone wants that. Can you guess which one of these is more debuggable?
And of course, the ARM architecture is offered by multiple makers, in all kinds of configurations of core types and numbers, clock speeds and so on. With Intel you get what one single company decides to offer, and that's it. Not directly relevant to us consumers of course, but it does mean it's more likely the ARM set-up in your phone or tablet is adapted specifically for that hardware, not a more generic one-size-fits-all spec.
Today Intel sells three versions of the same desktop chip; a high end one with all of the features enabled, a midrange one with some features disabled, and a low end one with most features disabled. Device makes know that once Intel is in a position of strength, they will do to mobile chips exactly what they are doing to desktop chips today. Let's look at one feature: SHA hashing engine. Intel Core i7 devices have this built in. Core i3 also has this but disables it. What if you want a low end SoC with a SHA engine? Any ARM vendor will sell you one, SHA engines are cheap and easy and everyone has one. Intel makes you pay for the high end part just to get a minor feature. Multiply this by all of the other SoC components and you'll see why nobody wants Intel to be in the lead. With ARM, chip vendors are competing on features, performance, and price. Nobody is picking ARM the company, they are picking the ARM ecosystem of chip designers and chip fabricators where everyone competes.
It has a lot of BSD code in it and continues to share code with the other BSDs.
Really? I was under the impression that Apple do not distribute any source code for Darwin on ARM. Please show me where I can obtain the XNU ARM kernel source that is used in iOS.
Why would you need that? The platform-specific part of the kernel is a fairly minor part of the overall code. There's a lot more code investment in the VM, the FS, the network stack, and other major kernel subsystems, which are all generic code and distributed to the public, than the specific implementations of low level locks, interrupts, and page table map managers. The fact that we can't build and run XNU on ARM doesn't mean that we can't share code with it.
iOS is doing even better.
There seem to be some uninformed posters here, so here is the OS X relationship to BSD:
The OS X/iOS kernel is based on Mach, which is a microkernel mashed together with a BSD kernel. It has a lot of BSD code in it and continues to share code with the other BSDs. It has features borrowed from BSD such as DTrace, PF firewall, file system support (including ZFS before it was removed), the networking subsystem, kqueue, jails, and others. While Mach is fundamentally different in some ways, to a POSIX binary it looks and feels just like any other BSD system.
The OS X userland is also based on BSD and was originally derived from FreeBSD. It uses the BSD libc and many of the command line tools are from the BSD world (from grep to ssh). It also includes some GNU tools, such as bash. Apple is actively working on replacing many of these, and they recently dropped GCC and GDB and replaced them with Clang and LLDB.
Oh god. Imagine if developer unions do happen and then I'd have to choose between working at a unionized company full of idiots or working at a non-union company that is staffed with Libertarians. I'd probably quit programming forever.
It does sound like fun and I would enjoy it given the right working conditions, though I imagine these are highly unlikely to be found in a military operation.
However, no lawyer can get you the guarantee you're looking for. If you are a male and a United States citizen, you'll remember having registered for Selective Service ("The Draft") before your 18th birthday. Under the right conditions any registered person can be called up for service, all it takes is an act of Congress.
the ARMv8 back end for LLVM was written entirely by one guy in under a year and already performs well (although there's still room for optimisation).
Where can I find this LLVM back end? It does not appear to be on llvm.org.
In the first half of next year, there should be three almost totally independent[1] implementations of the ARMv8 architecture, with the Cortex A50 appearing later in the year.
Can you name the three vendors? Qualcomm for sure. Marvell seems likely. Nvidia says they will have a chip out, but I have serious doubts about their ability to deliver.
ARMv8 is not eliminating them, it's reducing the number of instructions that have them. Conditional instructions are useful because you can eliminate branches and so keep the pipeline full. For example, consider this contrived example:
On ARMv7 and earlier, this would be a conditional add. The pipeline would always be full, the add would always be executed, but the result would only be retired if the condition is true. On MIPS, it would be a branch (complete with the insanity known as branch delay slots, which if you look at the diassembly of most MIPS code typically means with a nop, so you get to waste some i-cache as well) and if it's mispredicted then you get a pipeline stall.
On ARMv8, you don't have a conditional add, but you do have a conditional register-register move and you have twice as many registers. The compiler would still issue the add instruction and then would do a conditional move to put it in the result register. From the compiler perspective, this means that you can lower PHI nodes from your SSA representation directly to conditional moves in a lot of cases.
Basically, 32-bit ARM is designed for assembly writers, ARMv8 is designed for compilers. As a compiler writer, it's hands-down the best ISA I've worked with, although I would prefer to write assembly by hand for ARMv7. I wouldn't want to do either with MIPS, although I currently am working on MIPS-based CPU with some extra extensions.
Actually, ARM's reasoning is that modern branch predictors on high end AP's can do a good enough job of following a test and branch and keeping the pipeline(s) full that there is very little value in conditional instructions on future chips. It's hard to cause a pipeline stall or bubble by branching a few instructions forward or back on these CPUs since they are decoding well in advance of the execution pipelines. Added to that, there is an energy cost in executing an instruction and throwing away the result. Obviously, not all cases are wins. In the example you noted, a register to register mov on a register-renaming system is basically a 0-cycle operation (never makes it out of the instruction decoder), so it's hard to do better than that.
This is either either comedy or extreme stupidity, but I can't tell which.
They are also more attractive and have great personalities
Slashdot is more of a duplicator than an aggregator.
This is a reference to an older quote by Khomeini, but in Khomeini's days Iran was an ally of Israel. The alliance was broken off after the 1990 gulf war, because with Iraq gone and the USSR gone Israel had to change its strategy and Iran became a regional competitor.
I stopped reading after this sentence since it is so wrong, I assume the rest of it is also drivel. Israel and Iran were allies up until the Islamic revolution of 1979 in which Khomeini took power. You may have heard about the Iran hostage crisis, which happened at the same time when Iran's friendly relationship with the US was similarly dissolved. The Islamic council of Iran, which still rules today, has always been hostile to the US and Israel
This is a huge deal for developers since the iPad and iPhone/touch are now running the same software release. This means that developers no longer needs to target iOS 3.2 as the lowest common denominator for all devices, and can instead start using the new 4.x features (assuming they don't care about the very first generation iPhone/touch).
This is a tech blog. This was a story about technology and abuse of freedom of speech. This guy is trying to change the discussion to push his agenda when Israel was in no way involved in this story. Observe his obvious ploy and ignore it.
moderator guide: this should be modded funny (or cringeworthy), not insightful
Every time Slashdot has a story of EFI, we get a thousand uninformed posts about what it is, isn't, what it should do and why it sucks. As someone who has worked on EFI for years, let me clear them up for you:
1) EFI was designed by Intel as a replacement for BIOS. UEFI (edk2) is the second generation EFI, and is open source (see: http://tianocore.sourceforge.net). Intel delivers all of their boot support code as EFI drivers these days.
2) EFI is NOT a graphical interface. Some Chinese motherboard makers created terrible graphical configuration applications for it. Apple created a pretty nice boot selector. It can just as easily "post" and give you a console-mode menu like you're used to.
3) EFI is very common. All Apple computers use it. Most PC (Windows / Linux) laptops use it (your laptop probably does if it was made in the last 4 years). EFI drops into BIOS emulation mode after boot because Windows doesn't support it.
4) EFI machines generally allocate a small EFI partition on the hard drive, particularly if they use GPT. All Intel-based machines boot from flash memory and would successfully boot without this partition. This partition is for additional EFI firmware volumes or drivers that can be dynamically loaded.
5) EFI is much better than BIOS. It runs in full 32/64 bit mode. It can dynamically load drivers built into the ROM of your hardware (like a video card) and therefore doesn't have to rely on ancient backward-compatibility modes. It can run "apps", like a safe firmware updater so you don't have to boot your PC with a DOS boot disk to update the firmware. It can communicate a lot of configuration information to the OS and even provide hooks for some low level hardware-specific drivers. It can do things like boot from a network-shared CD-ROM drive or from a disk image stored on a USB stick (without resorting to making bootable partitions and jumping through a bunch of hoops like your average Linux USB stick). EFI can read FAT, NTFS, EXT2, HFS+ filesystems and boot the kernel directly from there (and the initrd image) without involving grub or other second stage boot loader. It can boot your GPT-tagged disks in your chosen order no matter what order you changed them around (take your boot drive, move it to a USB enclosure, boot from it).
Booting Intel machines is really fucking complicated, and EFI makes it much simpler.
Sharon Apple for the win. Information High
Megazone 23 (1985) has that beat by about 10 years. The character of Eve Tokimatsuri is a computer-generated popular singer.
Himitsu Kudasai - Megazone 23, Part II
For example, side by side, the Android browser in Froyo as running on a Nexus One has been demonstrated to be faster than the iPhone 3GS and the iPad despite the fact that they are both based on Webkit.
The Nexus One has a 1 GHz processor and 512 MB of RAM, whereas the 3GS has a 600 MHz (both ARM Cortex A8) and 256 MB of RAM. The fact that up until Froyo the browser didn't run faster should be quite embarrassing.