It also scales based on processor resources. They hit serious TLB scalability issues at around 17 processes (varies a bit between CPUs, in some systems - particularly mobile - you'll hit RAM limits sooner), so if you have more tabs open than this, you will start having multiple independent sites share the same renderer process.
but it was fully backwards compatible with GW-Basic
No it wasn't. I had to install GWBASIC separately from a DOS 4 install disk after upgrading to DOS 5, because the Chain Reaction GWBASIC game didn't work with QBASIC.
Typically not to end users though. Microsoft sold the BASIC that computer vendors (including Apple) burned into ROM. Microsoft QuickBASIC for DOS contained a compiler that could produce stand-alone.exe or.com binaries, though the free QBASIC that they bundled with DOS 5 and later was a cut-down version that only included the interpreter.
Robots don't feel those emotions, and have committed no massacres on that scale. I trust robots more than I trust humans.
Do you trust a gun? Do you trust a bomb? Of course not, because the concept is meaningless: neither will cause harm without instructions from a human. Both can magnify the amount of harm that a human can do. Autonomous weapons, of which landmines are the simplest possible case, expand both the quantity that a person can do harm and the time over which they can do it.
During the cold war, there were at least two incidents where humans refused to follow legitimate orders to launch nuclear weapons - in either case, the likely outcome of following the orders would have been the deaths of many millions. The worst atrocities of the second world war were caused by people 'just following orders'. And you think that it's a good idea to remove the part of the chain of command capable of disobeying orders.
I was quite surprised on my last visit to Google. I'd expected that it would be the one place where the OpenStreetMap data would be guaranteed to be worse than Google Maps. I guess a lot more Googlers are OSM contributors than I'd imagined...
Usually. The TomTom address database, for example, thinks that my flat is a mile away from where it is, and due to the arrangement of one-way systems, it's fairly complicated to get from where it thinks I am to where I actually am - and I live near the middle of a city.
The person in your story was relying on his ability to read a map, which sounds pretty reasonable, and his ability to read a compass (which was not such a good plan, if he didn't sanity check it with the direction of the sun). The people in TFA, however, are carrying a device that tells them their precise position in the world to within a few metres. If you're not periodically checking and saying 'hmm, I want to get from here to here and I'm nowhere between the two points' then I think that counts as a bit stupid.
They didn't, the fastest P4 Xeon outperformed the fastest Athlons, but for any given Athlon the equivalent speed P4 was a lot more expensive. Once the Opterons came out, that changed: if you wanted the fastest x86 chip you could buy, you bought from AMD, especially in multi-socket configurations (quad-processor Opterons wiped the floor with memory-starved quad Xeons until Intel integrated the memory controller on die). Worse (for Intel), if you were willing to recompile your code you could get another 20+% out of the Opterons using the x86-64 ISA (more GPRs and cheaper PIC made a big difference, and a floating point ABI that used SSE exclusively and not x87 could give you a 100% speedup in float-heavy code, where even if the x86-32 compiler was using SSE registers for compute it was still losing performance moving them to and from the x87 register stack for function calls / returns).
The Thunderbird was nice, but it was more of a price/performance winner than overall performance. A 1GHz Thunderbird ran stable at 1.3GHz and was similar performance to a 2GHz Pentium 4 at a fraction of the cost (particularly as the P4 required RAMBUS DRAM, so you could stick twice as much DDR in Athlon for the same money). It wasn't until the Opteron that AMD really started winning on performance. The integrated DRAM controller was a big win and being first to 64 bits (which, on x86, means more GPRs, sane floating point ISA, and PC-relative addressing) gave them a huge advantage. Unfortunately, they haven't really been competitive since the Core 2, except in market segments where Intel intentionally cripples their offerings (e.g. no more than 2 SATA ports on the Atom Mini-ITX boards to avoid competition with the i3 boards, making AMD the only viable option).
It's about both cost and risk analysis. If you've got a lot of infrastructure, then you've probably already got a team of decent admins. Adding another server has a very small marginal cost. If you haven't, then the cost is basically the cost of hiring a sysadmin. Even the cheapest full-time sysadmin costs a lot more than you can easily spend with GitHub. Alternatively, you get one of your devs to run it. Now you have a service that is only understood well by one person, where installing security updates (let alone testing them first) is nowhere near that top priority in that person's professional life, and where at even one hour a week spent on sysadmin tasks you're still spending a lot more than an equivalent service from GitHub would cost.
In both of the latter cases, the competition for GitHub isn't a competent and motivated in-house team. It is almost certainly better to run your own infrastructure well, but the competition for GitHub is running your own infrastructure badly and they're a very attractive proposition in that comparison.
Outsourcing things that are not your core competency is not intrinsically bad, the problem is when people outsource things that are their core competency (e.g. software companies deciding to outsource all of the development - it's not a huge step from there to the people working for the outsourcing company to decide to also handle outsourcing management and start up a competitor, with all of the expertise that should be yours), or outsourcing without doing a proper cost-benefit analysis (other than 'oh, look, it's cheaper this quarter!').
If you think outsourcing storage of documents is bad remember that, legal companies, hospitals and so on have been doing this for decades without issues - storing large quantities of paper / microfiche is not their core competency and there are companies that can, due to economies of scale, do it much cheaper. Oh, and if that still scares you, remember that most companies outsource storing all of their money as well...
Something of a biased set. I've been using Firefox on Android for over a year, and I am very happy with it. I wasn't aware until your post that Mozilla was collecting satisfaction stats, and even now I can't really be bothered to post there - but I probably would if I were unhappy with it. Firefox with the self-destructing cookies add-on is the only mobile browser that I've found that gives me the cookie management policy that I want.
Perhaps they're expecting people to install add-ons? Fine-grained cookie management was why I switched to Firefox on Android, but I actually ended up using the self-destructing cookies add-on, which has exactly the policy that I want: any site can set a cookie, but unless I explicitly opt in (which I can do retroactively with the undelete button) to keeping it, then it's deleted when I navigate away from the site. Everything works as if I had cookies set to automatically accept, but doesn't get to persist any state for me across visits unless I permit it to.
What do you think those big things under the wings are? When the throttle is at idle, they're being pushed around by the airflow from forward momentum.
A plane travelling at 500 miles per hour, at an altitude of 40,000 feet, has to lose a huge amount of both kinetic and gravitational potential energy before it's stationary on the runway. If you can capture 1% of this, then you can taxi around the airport for quite an extended period.
A number of airlines are now also powering the flight systems from the ground when connected to the terminal, so that they're not burning expensive avgas to generate electricity.
MINIX is far more capable these days than HURD, is a more modern microkernel design, and is more permissively licensed. The only reasons for continuing to work on HURD are that you really like the particular filesystem namespace arrangement of servers that they use, or that you are fanatical about GPLv3.
Read the research. There was something published a few weeks ago that made it into the mainstream press on the effects of different sugars on different people, for example. The variation that they measured was huge.
Which would be equally unhelpful for readers that are not familiar with UTC
Fortunately, for now, most readers of Slashdot are from Earth. Every time zone is expressed as an offset from UTC. Given a time in UTC, it is easy to work out what it is in your own time zone. Given a time in any other time zone, you do the conversion by first looking up the UTC offset of the reported time zone, subtracting it, and then adding your own UTC offset.
It does, but the simple fact is if you're fat and trending towards obese you're eating too much for your particular configuration.
Even that's not really true. You're eating too much of some things, but for some people it's very hard to find foods that contain enough of things that they are bad at metabolising (certain amino acids or vitamins, for example), without also including far too many of certain carbohydrates or fats that they do absorb. There are outliers who, eating what for most people would be a fairly balanced diet, are both putting on weight and exhibiting symptoms of starvation. There are a lot more people who tend in this direction, but to a lesser extreme.
You might want to take a university-level biology course. Hint: science taught at school contains simplifications. Variations in intestinal flora, for example, has a big impact on the effect of various foodstuffs on different populations.
The Flash spec has been published since at least the '90s, though the click-through license agreement prohibited writing tools for playing back flash until about 10 years ago. There were numerous third-party tools for producing Flash, just as there were for PDF and PostScript, because that's always been Adobe's explicit policy for getting adoption for their formats.
Except that the "open" PDF standard you're talking about is only a small subset of the oldest, most primitive image/text drawing features of said file format
That's not even remotely true. Read the PDF 1.7 specification (chapter 8, specifically) and you'll see all of that stuff documented. JavaScript has been part of the spec since PDF 1.3. The fact that some viewers don't implement features that have been part of the spec for over 10 years is not the fault of the spec.
You might be thinking of the PDF/A family of standards. These are ISO standards for long-term document archiving and specify an intentionally restricted subset of PDF features to ensure that it will always be easy to implement readers for them.
I'm not a semiconductor expert, but as I understand it: the thinner the traces on the semiconductor, the higher clock rate can go or the lower the power dissipation can be
That was true until about 2007. Then we hit the end of Dennard Scaling. Now you get more transistors, but your power consumption per transistor remains quite similar and so you need to be more clever. That's much easier on a CPU than a GPU because CPUs run quite a wide variety of workloads and so there are lots of things you can add that will be a bit win for a subset of workloads but not consume power at other times. On a GPU, it's harder because they tend to saturate a lot more of the execution engines that they ship with.
As for higher clock rate, that's sort-of true, but bumping the clock rate has a big impact on power consumption and so you don't get very much from it either.
Also, with the newer processes the yields are often lower and so, even though you can pack more on a wafer, once it's not going to be much cheaper (especially not once you factor in the need to recoup the $100bn that you spent on R&D to get the new fab up and running - you need to amortise that across a lot of chips to make it worthwhile).
In summary, being a generation behind is far less of a disadvantage than it was a decade ago.
What's all "proprietary" about Intel graphics exactly?
Their open source support in the Linux kernel is substantially better than AMD's half-assed "sorta kinda open when we feel like it for obsolete parts" approach.
Add to that, Intel publishes incredibly detailed ISA specs for their GPUs. They have some quite neat features in some of them, such as a two dimensional register file, where operands to instructions are identified by a base and a stripe size, so you can load four vectors horizontally (e.g. 4 pixel values) and then compute on them vertically (e.g. red values, green values, etc) without needing to do any vector shuffle operations. You can also do diagonal operations, which makes the code very dense as you rarely need to do any permute operations.
Slashdot Mirror
It also scales based on processor resources. They hit serious TLB scalability issues at around 17 processes (varies a bit between CPUs, in some systems - particularly mobile - you'll hit RAM limits sooner), so if you have more tabs open than this, you will start having multiple independent sites share the same renderer process.
but it was fully backwards compatible with GW-Basic
No it wasn't. I had to install GWBASIC separately from a DOS 4 install disk after upgrading to DOS 5, because the Chain Reaction GWBASIC game didn't work with QBASIC.
Typically not to end users though. Microsoft sold the BASIC that computer vendors (including Apple) burned into ROM. Microsoft QuickBASIC for DOS contained a compiler that could produce stand-alone .exe or .com binaries, though the free QBASIC that they bundled with DOS 5 and later was a cut-down version that only included the interpreter.
Robots don't feel those emotions, and have committed no massacres on that scale. I trust robots more than I trust humans.
Do you trust a gun? Do you trust a bomb? Of course not, because the concept is meaningless: neither will cause harm without instructions from a human. Both can magnify the amount of harm that a human can do. Autonomous weapons, of which landmines are the simplest possible case, expand both the quantity that a person can do harm and the time over which they can do it.
During the cold war, there were at least two incidents where humans refused to follow legitimate orders to launch nuclear weapons - in either case, the likely outcome of following the orders would have been the deaths of many millions. The worst atrocities of the second world war were caused by people 'just following orders'. And you think that it's a good idea to remove the part of the chain of command capable of disobeying orders.
I was quite surprised on my last visit to Google. I'd expected that it would be the one place where the OpenStreetMap data would be guaranteed to be worse than Google Maps. I guess a lot more Googlers are OSM contributors than I'd imagined...
Usually. The TomTom address database, for example, thinks that my flat is a mile away from where it is, and due to the arrangement of one-way systems, it's fairly complicated to get from where it thinks I am to where I actually am - and I live near the middle of a city.
The person in your story was relying on his ability to read a map, which sounds pretty reasonable, and his ability to read a compass (which was not such a good plan, if he didn't sanity check it with the direction of the sun). The people in TFA, however, are carrying a device that tells them their precise position in the world to within a few metres. If you're not periodically checking and saying 'hmm, I want to get from here to here and I'm nowhere between the two points' then I think that counts as a bit stupid.
They didn't, the fastest P4 Xeon outperformed the fastest Athlons, but for any given Athlon the equivalent speed P4 was a lot more expensive. Once the Opterons came out, that changed: if you wanted the fastest x86 chip you could buy, you bought from AMD, especially in multi-socket configurations (quad-processor Opterons wiped the floor with memory-starved quad Xeons until Intel integrated the memory controller on die). Worse (for Intel), if you were willing to recompile your code you could get another 20+% out of the Opterons using the x86-64 ISA (more GPRs and cheaper PIC made a big difference, and a floating point ABI that used SSE exclusively and not x87 could give you a 100% speedup in float-heavy code, where even if the x86-32 compiler was using SSE registers for compute it was still losing performance moving them to and from the x87 register stack for function calls / returns).
The Thunderbird was nice, but it was more of a price/performance winner than overall performance. A 1GHz Thunderbird ran stable at 1.3GHz and was similar performance to a 2GHz Pentium 4 at a fraction of the cost (particularly as the P4 required RAMBUS DRAM, so you could stick twice as much DDR in Athlon for the same money). It wasn't until the Opteron that AMD really started winning on performance. The integrated DRAM controller was a big win and being first to 64 bits (which, on x86, means more GPRs, sane floating point ISA, and PC-relative addressing) gave them a huge advantage. Unfortunately, they haven't really been competitive since the Core 2, except in market segments where Intel intentionally cripples their offerings (e.g. no more than 2 SATA ports on the Atom Mini-ITX boards to avoid competition with the i3 boards, making AMD the only viable option).
It's about both cost and risk analysis. If you've got a lot of infrastructure, then you've probably already got a team of decent admins. Adding another server has a very small marginal cost. If you haven't, then the cost is basically the cost of hiring a sysadmin. Even the cheapest full-time sysadmin costs a lot more than you can easily spend with GitHub. Alternatively, you get one of your devs to run it. Now you have a service that is only understood well by one person, where installing security updates (let alone testing them first) is nowhere near that top priority in that person's professional life, and where at even one hour a week spent on sysadmin tasks you're still spending a lot more than an equivalent service from GitHub would cost.
In both of the latter cases, the competition for GitHub isn't a competent and motivated in-house team. It is almost certainly better to run your own infrastructure well, but the competition for GitHub is running your own infrastructure badly and they're a very attractive proposition in that comparison.
Outsourcing things that are not your core competency is not intrinsically bad, the problem is when people outsource things that are their core competency (e.g. software companies deciding to outsource all of the development - it's not a huge step from there to the people working for the outsourcing company to decide to also handle outsourcing management and start up a competitor, with all of the expertise that should be yours), or outsourcing without doing a proper cost-benefit analysis (other than 'oh, look, it's cheaper this quarter!').
If you think outsourcing storage of documents is bad remember that, legal companies, hospitals and so on have been doing this for decades without issues - storing large quantities of paper / microfiche is not their core competency and there are companies that can, due to economies of scale, do it much cheaper. Oh, and if that still scares you, remember that most companies outsource storing all of their money as well...
Something of a biased set. I've been using Firefox on Android for over a year, and I am very happy with it. I wasn't aware until your post that Mozilla was collecting satisfaction stats, and even now I can't really be bothered to post there - but I probably would if I were unhappy with it. Firefox with the self-destructing cookies add-on is the only mobile browser that I've found that gives me the cookie management policy that I want.
Perhaps they're expecting people to install add-ons? Fine-grained cookie management was why I switched to Firefox on Android, but I actually ended up using the self-destructing cookies add-on, which has exactly the policy that I want: any site can set a cookie, but unless I explicitly opt in (which I can do retroactively with the undelete button) to keeping it, then it's deleted when I navigate away from the site. Everything works as if I had cookies set to automatically accept, but doesn't get to persist any state for me across visits unless I permit it to.
no windmills glued on the plane please
What do you think those big things under the wings are? When the throttle is at idle, they're being pushed around by the airflow from forward momentum.
A plane travelling at 500 miles per hour, at an altitude of 40,000 feet, has to lose a huge amount of both kinetic and gravitational potential energy before it's stationary on the runway. If you can capture 1% of this, then you can taxi around the airport for quite an extended period.
A number of airlines are now also powering the flight systems from the ground when connected to the terminal, so that they're not burning expensive avgas to generate electricity.
MINIX is far more capable these days than HURD, is a more modern microkernel design, and is more permissively licensed. The only reasons for continuing to work on HURD are that you really like the particular filesystem namespace arrangement of servers that they use, or that you are fanatical about GPLv3.
Joy of Tech from a couple of days ago summed it up pretty well.
Read the research. There was something published a few weeks ago that made it into the mainstream press on the effects of different sugars on different people, for example. The variation that they measured was huge.
Which would be equally unhelpful for readers that are not familiar with UTC
Fortunately, for now, most readers of Slashdot are from Earth. Every time zone is expressed as an offset from UTC. Given a time in UTC, it is easy to work out what it is in your own time zone. Given a time in any other time zone, you do the conversion by first looking up the UTC offset of the reported time zone, subtracting it, and then adding your own UTC offset.
It does, but the simple fact is if you're fat and trending towards obese you're eating too much for your particular configuration.
Even that's not really true. You're eating too much of some things, but for some people it's very hard to find foods that contain enough of things that they are bad at metabolising (certain amino acids or vitamins, for example), without also including far too many of certain carbohydrates or fats that they do absorb. There are outliers who, eating what for most people would be a fairly balanced diet, are both putting on weight and exhibiting symptoms of starvation. There are a lot more people who tend in this direction, but to a lesser extreme.
You might want to take a university-level biology course. Hint: science taught at school contains simplifications. Variations in intestinal flora, for example, has a big impact on the effect of various foodstuffs on different populations.
The Flash spec has been published since at least the '90s, though the click-through license agreement prohibited writing tools for playing back flash until about 10 years ago. There were numerous third-party tools for producing Flash, just as there were for PDF and PostScript, because that's always been Adobe's explicit policy for getting adoption for their formats.
Have you actually read the PDF spec? All of the interactive forms stuff is documented (see chapter 8), as are the multimedia parts (see chapter 9).
Except that the "open" PDF standard you're talking about is only a small subset of the oldest, most primitive image/text drawing features of said file format
That's not even remotely true. Read the PDF 1.7 specification (chapter 8, specifically) and you'll see all of that stuff documented. JavaScript has been part of the spec since PDF 1.3. The fact that some viewers don't implement features that have been part of the spec for over 10 years is not the fault of the spec.
You might be thinking of the PDF/A family of standards. These are ISO standards for long-term document archiving and specify an intentionally restricted subset of PDF features to ensure that it will always be easy to implement readers for them.
I'm not a semiconductor expert, but as I understand it: the thinner the traces on the semiconductor, the higher clock rate can go or the lower the power dissipation can be
That was true until about 2007. Then we hit the end of Dennard Scaling. Now you get more transistors, but your power consumption per transistor remains quite similar and so you need to be more clever. That's much easier on a CPU than a GPU because CPUs run quite a wide variety of workloads and so there are lots of things you can add that will be a bit win for a subset of workloads but not consume power at other times. On a GPU, it's harder because they tend to saturate a lot more of the execution engines that they ship with.
As for higher clock rate, that's sort-of true, but bumping the clock rate has a big impact on power consumption and so you don't get very much from it either.
Also, with the newer processes the yields are often lower and so, even though you can pack more on a wafer, once it's not going to be much cheaper (especially not once you factor in the need to recoup the $100bn that you spent on R&D to get the new fab up and running - you need to amortise that across a lot of chips to make it worthwhile).
In summary, being a generation behind is far less of a disadvantage than it was a decade ago.
What's all "proprietary" about Intel graphics exactly?
Their open source support in the Linux kernel is substantially better than AMD's half-assed "sorta kinda open when we feel like it for obsolete parts" approach.
Add to that, Intel publishes incredibly detailed ISA specs for their GPUs. They have some quite neat features in some of them, such as a two dimensional register file, where operands to instructions are identified by a base and a stripe size, so you can load four vectors horizontally (e.g. 4 pixel values) and then compute on them vertically (e.g. red values, green values, etc) without needing to do any vector shuffle operations. You can also do diagonal operations, which makes the code very dense as you rarely need to do any permute operations.