I thought the promise of Republican politics was smaller government and less taxes, but when they got handed the Presidency and later control of Congress with the debt on the run, I didn't notice any decline in taxes
That's because you weren't part of the Republican base, to whom those promises were made.
It is if you want any kind of economic growth. If you have no inflation and no interest then keeping your money under a mattress becomes as good as putting it in a bank - in both cases, it will be worth the same amount next year. With a small amount of inflation and a similar interest rate, you want to put the money in the bank so that it will remain worth the same amount in a year, rather than being worth less if you put it under your mattress. The bank will then loan it to businesses wishing to start or expand, enabling them to grow.
Actually, if you had proof of that in the general case, then you'd be inline for something like the nobel for economics (yes, not a real nobel, I know). See: Giffen Goods, Veblen Goods.
I vaguely remember there being something about the endian. FLAC required more byte swapping than ALE, so you could just about squeeze an ALE decoder into the DSP, but not a FLAC decoder. As far as I know, no one else managed to port FLAC to the DSP either.
Back then Swing didn't exist (well, Java didn't exist, but Swing didn't exist until Java 1.2 in 1998). Java used AWT, which wrapped native controls in Java classes, rather than doing all of the rendering using Java2D (which didn't exist initially either). Java 1.0 did launch with a browser written in Java, although its name escapes me at the moment, but the main focus was on embedding Java in browsers, not browsers in Java.
Netscape had one of the biggest IPOs of all time, and was eventually bought by AOL for a large sum. So, no, it was not erroneously considered to be too low. Unless it was more than three billion dollars (the Netscape market cap at closing on the day of their IPO in 1995 was $2.9bn).
Nokia's S60 browser and the Blackberry browser also use WebKit, as do the Android and WebOS browsers. Recent versions of OmniWeb also use it. There are a lot of small browsers for various platforms written using it as well, for example the AROS browser. There used to be quite a few Gecko-based ones, but WebKit is a bit more modular and easier to embed so fewer people are writing new ones and minority browsers have a habit of becoming abandoned after a few years.
Emerged? In 1994, there were half a dozen web browsers, and HTML was simple enough that writing one was a relatively easy task. WorldWideWeb itself was about a weekend's worth of work. HTML 2 made it a bit more complex, but a competent coder could have easily written an HTML 2 rendering engine in a couple of weeks. It wasn't until about 1997 that the choice for browsers on Windows was typically reduced to IE or NS (or Opera if you were weird). Mosaic, OmniWeb and a host of others were very common.
If they had bought Netscape, then they wouldn't have bought / licensed Mosaic and would have ended up with a different browser war. There were half a dozen browser makers around at the time, Netscape was just the biggest.
I suspect the improvements to the SIMD registers are going to make more of a difference. 16 integer registers is usually enough to avoid needing to spill to the stack. It really depends on how they're split between callee- and caller-save, but that's a decision for the ABI, rather than the ISA. A few more argument registers would probably help Objective-C, where you have two used for self and _cmd, so arguments are more likely to spill to the stack. A few more caller-save registers could reduce the number of register-register moves in a few complex sequences, but probably not very many for C-family code.
Languages like Lisp and Haskell are more likely to benefit. SBCL, for example, really likes having at least 16 registers to play with and 32 generally results in better code.
Mobile? Well, my current laptop is using 64-bit processes and none of them has even 1GB of address space mapped, so it will be a little while. That said, ARM won't release any core designs with this ISA until at least next year, and they probably won't make it into shipping products for another year.
Mobile isn't the only place ARM is aiming though. Low-power servers are a growing market and the 40-bit LPAE in the A15 is likely to look a little bit cramped in the next few years. Servers often want to do things like mmap huge files, so a 32-bit userspace address space can be problematic.
Full double-precision support in the vector unit is big win. Current ARM chips suck when you have to do anything with double precision floating point values.
No Thumb-3, so you're stuck with 32-bit instructions in 64-bit mode, which don't give as good i-cache usage. That's a shame, but I guess you can always run 32-bit Thumb-2 apps on your 64-bit kernel. There's no blx to 32-bit mode, you're stuck in 64-bit mode for an entire process (which makes sense).
Weakly ordered following the C1x / C++11 memory model: that's going to break a lot of code that was written for x86 and assumes a strongly-ordered architecture. It also means that, for good performance, people are going to have to actually read the documentation for stdatomic.h / , which is something no one wants to do.
Crypto instructions... meh. If you've got an application doing a lot of crypto, you're probably using these via an on-die coprocessor anyway. Also, hard-coding the crypto algorithms into the ISA seems like a mistake.
No shipping silicon until 2014 from ARM, although rumour has it that nVidia has an A64 core design almost finished and ready to appear in a Tegra chip in 2012.
Given that they've already fired the hardware team responsible for the TouchPad and Pre3, it seems unlikely. Now they're stuck with an OS that they don't have any hardware for and no one else wants to license. Which is a shame, because the TouchPad is really nice hardware and WebOS is the first tablet OS I've used and not hated (it's far from perfect, but it's definitely going in the right direction).
Nope, the reason Apple didn't support FLAC was that it couldn't be implemented on the DSPs of the third generation iPods. ALAC could, but this came at the cost of about 1-2% larger file sizes. More modern players have more powerful DSPs (some of which even include FLAC encoders as well as decoders provided by the manufacturer), so it's less important.
ALE (Or ALAC, as it seems to be called this week) was released for the third generation iPods. At the time, there was no FLAC decoder that could run on the DSP on these devices. You could decode FLAC on the ARM core, but that reduced battery life dramatically (the ARM core used about ten times as much power as the DSP - it was there to run the interface, but when playing music it would just load a few tracks into RAM, kick the DSP to start running, and then go back to sleep). Some third-party firmware for the iPod did this.
I'm not sure if this has changed. FLAC's CPU-based implementation seems to be a lot better than Apple's, but no one really cares about CPU usage for decompression, because it tends not to be a bottleneck. I know that there are now some FLAC decoders for the kind of hardware offload chips that you find in most media players, but I don't know if you can run the decoder competently on, say, a C64x DSP.
Yes. The RIAA wants the player market to be entirely comoditised, so any music consumer can pay the smallest possible amount for multiple playback devices, but keep paying the RIAA for their content.
I did some work for a company that stores legal documents a few years ago. When things are ready for disposal, they are shredded loaded into a locked container. This container is then driven away and not unlocked until it arrives at its destination. Once there, it's emptied into a swimming pool filled with bleach. It is then removed from there and recycled. By the time it comes out of the bleach, it is small fragments of white fluff.
OS X users are far down. We are, what, 6-7% of total computer users? There are more users of Chrome on Windows than there are users of OS X in total. Safari and Chrome do both use WebKit, but they use different JavaScript engines, and JavaScript is where a lot of the optimisation effort goes.
I've not been paying attention to Linux much, but the one that came to mind was CVE-2009-0065. A bug in the SCTP implementation, meant that anyone sending SCTP packets could corrupt the kernel memory, potentially leading to a remote arbitrary kernel-mode code execution. There was another one a few months later caused, ironically, by a bug in the security code that was supposed to prevent exactly the kind of bug it introduced.
More recently, CVE-2011-1076 is less serious but can potentially be used to make man in the middle attacks very easy if you're on a public network. CVE-2011-1776 is not remotely exploitable, but it does mean that any SD card that you plug in to your device may inject code into the kernel. CVE-2011-2723 is another one that lets remote attackers crash the machine. CVE-2011-1576 is probably not applicable to Android, but it's another remotely exploitable Linux kernel hole that allows memory corruption (any memory corruption bug is potentially an arbitrary code execution vulnerability).
That's four that I found in the Linux kernel (not counting any userland stuff) just by looking at the last couple of months of NVD logs. I'm sure you can find more if you check a whole year, let alone the lifetime of a mobile phone.
Sorry, I mean to say: Linux is perfect and has no bugs, certainly not any serious security holes...
A stable API is not a static API. Most of the NeXT APIs from OPENSTEP 4.2 still work on OS X 10.7, but if you're writing a new application for OS X then you won't confine yourself to those APIs, you'll use the more modern ones. If you're developing a new version of an application, then you often have the choice between spending ten minutes implementing a feature using a new API or many hours implementing it with older ones. Eventually, it stops being worthwhile to support platforms that don't have the new APIs.
Because old versions often have bugs, some of which are security holes. Given the frequency with which remotely exploitable bugs appear in the Linux kernel, leaving a large number of devices with an unpatched two-year-old kernel is just asking for someone to build a botnet out of them. A very lucractive botnet, as all it needs to do is make all of the phones make one spurious call to a premium rate number for a minute and the botnet author can retire.
When translating text into a different language, it is customary to also translate the various other locale-specific conventions. For example, if you are translating a note about a meeting on the third of January from French to American English, then you would be incorrect if you did not rewrite 1/3 as 3/1. Similarly, you would be incorrect if you did not change 100,000 into 100.000. This is especially important if there are three digits after the decimal point, because comma is used as a thousands separator in some locales and as a radix point in others.
Slashdot Mirror
I thought the promise of Republican politics was smaller government and less taxes, but when they got handed the Presidency and later control of Congress with the debt on the run, I didn't notice any decline in taxes
That's because you weren't part of the Republican base, to whom those promises were made.
It is if you want any kind of economic growth. If you have no inflation and no interest then keeping your money under a mattress becomes as good as putting it in a bank - in both cases, it will be worth the same amount next year. With a small amount of inflation and a similar interest rate, you want to put the money in the bank so that it will remain worth the same amount in a year, rather than being worth less if you put it under your mattress. The bank will then loan it to businesses wishing to start or expand, enabling them to grow.
Did you look up the terms I mentioned? Yes, in some cases lowering the price of a good can reduce its sales.
Actually, if you had proof of that in the general case, then you'd be inline for something like the nobel for economics (yes, not a real nobel, I know). See: Giffen Goods, Veblen Goods.
I vaguely remember there being something about the endian. FLAC required more byte swapping than ALE, so you could just about squeeze an ALE decoder into the DSP, but not a FLAC decoder. As far as I know, no one else managed to port FLAC to the DSP either.
Back then Swing didn't exist (well, Java didn't exist, but Swing didn't exist until Java 1.2 in 1998). Java used AWT, which wrapped native controls in Java classes, rather than doing all of the rendering using Java2D (which didn't exist initially either). Java 1.0 did launch with a browser written in Java, although its name escapes me at the moment, but the main focus was on embedding Java in browsers, not browsers in Java.
Netscape had one of the biggest IPOs of all time, and was eventually bought by AOL for a large sum. So, no, it was not erroneously considered to be too low. Unless it was more than three billion dollars (the Netscape market cap at closing on the day of their IPO in 1995 was $2.9bn).
Nokia's S60 browser and the Blackberry browser also use WebKit, as do the Android and WebOS browsers. Recent versions of OmniWeb also use it. There are a lot of small browsers for various platforms written using it as well, for example the AROS browser. There used to be quite a few Gecko-based ones, but WebKit is a bit more modular and easier to embed so fewer people are writing new ones and minority browsers have a habit of becoming abandoned after a few years.
Emerged? In 1994, there were half a dozen web browsers, and HTML was simple enough that writing one was a relatively easy task. WorldWideWeb itself was about a weekend's worth of work. HTML 2 made it a bit more complex, but a competent coder could have easily written an HTML 2 rendering engine in a couple of weeks. It wasn't until about 1997 that the choice for browsers on Windows was typically reduced to IE or NS (or Opera if you were weird). Mosaic, OmniWeb and a host of others were very common.
If they had bought Netscape, then they wouldn't have bought / licensed Mosaic and would have ended up with a different browser war. There were half a dozen browser makers around at the time, Netscape was just the biggest.
What makes you think this has anything to do with terrorists.
I suspect the improvements to the SIMD registers are going to make more of a difference. 16 integer registers is usually enough to avoid needing to spill to the stack. It really depends on how they're split between callee- and caller-save, but that's a decision for the ABI, rather than the ISA. A few more argument registers would probably help Objective-C, where you have two used for self and _cmd, so arguments are more likely to spill to the stack. A few more caller-save registers could reduce the number of register-register moves in a few complex sequences, but probably not very many for C-family code.
Languages like Lisp and Haskell are more likely to benefit. SBCL, for example, really likes having at least 16 registers to play with and 32 generally results in better code.
Mobile? Well, my current laptop is using 64-bit processes and none of them has even 1GB of address space mapped, so it will be a little while. That said, ARM won't release any core designs with this ISA until at least next year, and they probably won't make it into shipping products for another year.
Mobile isn't the only place ARM is aiming though. Low-power servers are a growing market and the 40-bit LPAE in the A15 is likely to look a little bit cramped in the next few years. Servers often want to do things like mmap huge files, so a 32-bit userspace address space can be problematic.
Full double-precision support in the vector unit is big win. Current ARM chips suck when you have to do anything with double precision floating point values.
No Thumb-3, so you're stuck with 32-bit instructions in 64-bit mode, which don't give as good i-cache usage. That's a shame, but I guess you can always run 32-bit Thumb-2 apps on your 64-bit kernel. There's no blx to 32-bit mode, you're stuck in 64-bit mode for an entire process (which makes sense).
Weakly ordered following the C1x / C++11 memory model: that's going to break a lot of code that was written for x86 and assumes a strongly-ordered architecture. It also means that, for good performance, people are going to have to actually read the documentation for stdatomic.h / , which is something no one wants to do.
Crypto instructions... meh. If you've got an application doing a lot of crypto, you're probably using these via an on-die coprocessor anyway. Also, hard-coding the crypto algorithms into the ISA seems like a mistake.
No shipping silicon until 2014 from ARM, although rumour has it that nVidia has an A64 core design almost finished and ready to appear in a Tegra chip in 2012.
Given that they've already fired the hardware team responsible for the TouchPad and Pre3, it seems unlikely. Now they're stuck with an OS that they don't have any hardware for and no one else wants to license. Which is a shame, because the TouchPad is really nice hardware and WebOS is the first tablet OS I've used and not hated (it's far from perfect, but it's definitely going in the right direction).
Nope, the reason Apple didn't support FLAC was that it couldn't be implemented on the DSPs of the third generation iPods. ALAC could, but this came at the cost of about 1-2% larger file sizes. More modern players have more powerful DSPs (some of which even include FLAC encoders as well as decoders provided by the manufacturer), so it's less important.
ALE (Or ALAC, as it seems to be called this week) was released for the third generation iPods. At the time, there was no FLAC decoder that could run on the DSP on these devices. You could decode FLAC on the ARM core, but that reduced battery life dramatically (the ARM core used about ten times as much power as the DSP - it was there to run the interface, but when playing music it would just load a few tracks into RAM, kick the DSP to start running, and then go back to sleep). Some third-party firmware for the iPod did this.
I'm not sure if this has changed. FLAC's CPU-based implementation seems to be a lot better than Apple's, but no one really cares about CPU usage for decompression, because it tends not to be a bottleneck. I know that there are now some FLAC decoders for the kind of hardware offload chips that you find in most media players, but I don't know if you can run the decoder competently on, say, a C64x DSP.
Yes. The RIAA wants the player market to be entirely comoditised, so any music consumer can pay the smallest possible amount for multiple playback devices, but keep paying the RIAA for their content.
I did some work for a company that stores legal documents a few years ago. When things are ready for disposal, they are shredded loaded into a locked container. This container is then driven away and not unlocked until it arrives at its destination. Once there, it's emptied into a swimming pool filled with bleach. It is then removed from there and recycled. By the time it comes out of the bleach, it is small fragments of white fluff.
That's by no means universal. My (US) publisher does not capitalise prepositions in titles.
OS X users are far down. We are, what, 6-7% of total computer users? There are more users of Chrome on Windows than there are users of OS X in total. Safari and Chrome do both use WebKit, but they use different JavaScript engines, and JavaScript is where a lot of the optimisation effort goes.
More recently, CVE-2011-1076 is less serious but can potentially be used to make man in the middle attacks very easy if you're on a public network. CVE-2011-1776 is not remotely exploitable, but it does mean that any SD card that you plug in to your device may inject code into the kernel. CVE-2011-2723 is another one that lets remote attackers crash the machine. CVE-2011-1576 is probably not applicable to Android, but it's another remotely exploitable Linux kernel hole that allows memory corruption (any memory corruption bug is potentially an arbitrary code execution vulnerability).
That's four that I found in the Linux kernel (not counting any userland stuff) just by looking at the last couple of months of NVD logs. I'm sure you can find more if you check a whole year, let alone the lifetime of a mobile phone.
Sorry, I mean to say: Linux is perfect and has no bugs, certainly not any serious security holes...
A stable API is not a static API. Most of the NeXT APIs from OPENSTEP 4.2 still work on OS X 10.7, but if you're writing a new application for OS X then you won't confine yourself to those APIs, you'll use the more modern ones. If you're developing a new version of an application, then you often have the choice between spending ten minutes implementing a feature using a new API or many hours implementing it with older ones. Eventually, it stops being worthwhile to support platforms that don't have the new APIs.
Because old versions often have bugs, some of which are security holes. Given the frequency with which remotely exploitable bugs appear in the Linux kernel, leaving a large number of devices with an unpatched two-year-old kernel is just asking for someone to build a botnet out of them. A very lucractive botnet, as all it needs to do is make all of the phones make one spurious call to a premium rate number for a minute and the botnet author can retire.
When translating text into a different language, it is customary to also translate the various other locale-specific conventions. For example, if you are translating a note about a meeting on the third of January from French to American English, then you would be incorrect if you did not rewrite 1/3 as 3/1. Similarly, you would be incorrect if you did not change 100,000 into 100.000. This is especially important if there are three digits after the decimal point, because comma is used as a thousands separator in some locales and as a radix point in others.