The main issue for Microsoft was putting Windows-specific APIs in the java.* namespace. This broke the 'if you only use java.* stuff then your app will run anywhere' guarantee for Java developers and was in direct violation of the Java license (which included patent and copyright grants). Dalvik's register-based VM, which doesn't use the.class files at all, is partly a way of getting around the JVM patents and meaning that copyright is the only thing that they can infringe. As they're not using any code licensed from Oracle, the only argument left is that they're using the same interfaces.
Or you're doing something right. Good API design is good UI design. If your UI sucks in most pieces of software, your software is a lot less valuable. Most programmers are far too tolerant of crappy APIs and will happily use a poorly designed UI and blame other programmers who struggle.
Some bits are easy (for example, don't be the idiot LLVM contributor who thought that having isBundle() and isBundled() methods on the MachineInstr class that do completely different things was a good idea). Some bits are harder - making sure that you have consistent abstractions that you use across entire frameworks, making sure that you use consistent naming everywhere.
A good API is a considerable engineering effort. It's not excluded from copyright because it's not creative, it's excluded because interoperability is considered more important. The trend in copyright law has been removing exemptions that benefit society as a whole in favour of total control by the originator, so it's not a surprise that this is being weakened.
Rolex makes some relatively cheap watches. The ones I've seen in shops (and therefore probably cheaper online) start at around £250. They are, however, monumentally ugly. They're part of the trend in mens watches that say 'I need to assert my masculinity by showing that I can lug a big lump of metal around on my wrist all day'. The only watchmaker that I know of that makes watches that are aimed at people who appreciate good industrial design and want a watch that is easy to ready but very light is Skagen (they're also a fraction of the price of even a cheap Rolex). I've had one of their watches for around 8 years and not seen anything comparable from other manufacturers.
I suspect that's a big part of the reason that watch wearing has declined. Most of the watchmakers cater exclusively for the market segment that wants to make a statement (and that statement is: I have lots of money but no taste) and not for those that want something functional and aesthetically pleasing.
For quickly checking the time without having to pull something out of your pocket? And so you can still tell the time when you don't take your phone with you (a watch is a lot more portable than even a small phone)? I have a Skagen watch (which I've had for about 7 years now) which has a thin titanium mesh strap and is so thin that I can forget that I'm wearing it. No phone can replace that.
I guess you've never been to anything where the invitation says black tie as the dress code then? I have a few everyday wear shirts that I wear with cufflinks too, because the button fell off on one cuff and it was less effort to cut the other one off and wear cufflinks than sew on a replacement.
There are no essential features in any word processor that aren't covered by a linotype machine. That doesn't mean that you'd expect people to be equally productive with both.
LibreOffice has a less permissive license than OpenOffice, so can't be folded back in. LibreOffice's origins are Novell's Go-OO project, which included stuff that they refused to license under the upstream license and so could not be contributed back and stuff covered by the MS-Novell patent license that upstream wouldn't accept because it wasn't clear that the patent license applied to anyone distributing derived works.
I've written a few books from Pearson. Their QA process involves a round of copyediting and then a round of proofreading, by different people. They also have a few technical reviewers who read and find technical errors (the Japanese translator was the best at this for my last book and also great at finding idiom uses that would be confusing to a non-native speaker). They don't catch everything, but they catch most things.
The O'Reilly books that I've read look as if they've been skim-read by someone and then sent to the printer.
Exactly. I don't block ads. I do block tracking JavaScript. Anything that uses Flash / HTML5 video / audio needs me to click on it before I see it. The result? I very rarely see ads. Put plain-text ads that are relevant to the content of the page, and I might click on them. I used to click on Google ads periodically back when they did this, but they gradually went down the route of trying to profile me and find things that I was interested in and replaced all of the ads that were relevant to the stuff I was looking at now with ads for things that I bought last month and won't need to buy again for a long time.
The Chrome UI sucks on OS X, as does the lack of Keychain integration. You can fix the latter in Firefox with a plugin, but its UI is also decidedly non-native (thought a lot better than it was even 5 years ago).
Qt is a great way of writing Mac applications if your goal is to piss off your users. If you want an app that looks sort-of vaguely like a Mac app and doesn't behave at all like one, then use Qt.
If you have to ask that question, either you have never used git on the command line, or you should be permanently banned from ever designing user interfaces.
I do incremental LLVM builds on my laptop quite often. Unless I've changed a header that's included by a lot of things, they're quick, but the LLVM codebase has around 2200 C++ files, many of which are a few thousand lines long. If I'm making invasive changes, testing them on the bigger machine is a lot more pleasant - recompiling 2200 files on 32 cores is a lot faster than on 4+4 (and the Xeon cores are faster than the mobile i7 ones).
As for the RAM, FreeBSD make universe (which builds the base system for all supported target architectures) produces around 50GB of object code (which all wants to stay in the buffer cache so that the linker can read it quickly). Even LLVM by itself produces around 12GB when you do a debug build (which I don't as part of the FreeBSD build, but I do as part of regular LLVM development) and linking that really wants the linker to be pulling in the files from RAM for best performance.
The big machines have a few TBs of spinning rust, a 512GB SSD split between L2ARC and log device, and 256GB of RAM. The log device on the SSD makes a big difference because writes run at linear write to SSD speed, not random write to HDD speed (eventually it gets full if you keep doing it, but there's enough SSD that you rarely see that with out workloads). The big amount of RAM means that most reads are serviced from the OS buffer cache. The L2ARC means that most of the rest come from there.
I should mention that these are multi-user systems, though usually we're doing big compile jobs at random times (unlike on the CI systems, with similar specs, where we're doing them solidly round the clock). We turn on dedup for all home directories, which makes a big difference: everyone can have checkouts of the same source trees without using more disk / L2ARC / ARC space and object code is often deduplicated too. You do notice when more than one person is doing a big build though - the time increase is noticeable, even with enough RAM that neither of you is likely to be touching the disk.
My last two laptops have had SSDs. For big compile jobs, use a machine with an SSD and 256GB of RAM. Most of the I/O is serviced entirely from the buffer cache and never even goes to the SSD. It's CPU bound.
You might be surprised. Netflix currently supports around 80 different clients for their service (apps for various platforms, different technologies for the web interface, and embedded things). Codecs are a big issue for them.
And is a gas that is so much lighter than air that it's hard to find on Earth because any released into the atmosphere floats quickly to the top and is skimmed off by solar wind. If you release a load of radioactive helium isotopes into the air, then anyone breathing in as they're released is likely to have problems, but the molecules that are not inhaled will be gone from the site within a few minutes. Not sure what isotope of Helium you're thinking of though - I'm not aware of any unstable isotopes that have a half life of over a second. If you meant Hydrogen, then deuterium is fairly stable and tritium has a half life of around 12 years. Tritium is a beta emitter (and glows - lots of key fobs and so on have tritium in them). It will dissipate in a similar way, though unlike helium it is likely to react with oxygen and fall as heavy water rain (not very dangerous - it's only a beta emitter, but it's not a great idea to inhale or drink it).
I'm not sure if they ever prototyped it (I don't think they did, but I wouldn't be entirely surprised), but there was a design that involved dropping a fusion warhead to the bottom of a mine shaft filled with water and then driving a geothermal-style power plant from the resulting steam.
It depends. Building a wood-fired steam engine is pretty easy: the amount of heat is fairly small and a slow trickle of water can take it away (turned into steam, driven past turbines or used to power pistons), keeping the boiler at an equilibrium temperature. Move up to a denser fuel and the engineering becomes harder - you need higher water pressure and to get the steam out faster. Move up to fission and the coolant cycle can get quite large - remember, if you're moving the water past the nuclear reaction then stray neutrons are going to turn it into heavy water and you're not going to want to just dump it (though you might want to extract the tritium for other uses), so you need a closed cycle where you can cool the water down enough that you can feed it back over the reactor in a loop, taking the energy out in the turbines somewhere. You often do this with a couple of loops of coolant, where the coolant that's run over the reactor heats something else which then drives the turbines, so your turbines are not having to pass irradiated coolant.
Scale it up more and it becomes an even more difficult engineering challenge. For comparison, look at a 100W lightbulb and a 100W Pentium 4. Both need to dissipate 100W, but one is doing it over the surface of a large bulb, the other over about a square centimetre on the top of the package - the total heat is the same, but it's a lot harder to keep the P4 cool than it is to cool the lightbulb.
From the first source I found, nuclear deaths per TWh are 0.04 (coal is 15-170, depending on the statistics you pick). While 0.04 is not quite zero, that's where it would end up if you did any rounding...
The real problem is the cost to fight them. In your example, two people invent at the same time, both have evidence that they invented prior to the filing. That's a clear cut case of prior art and the patent would be invalid. The only requirement is that the person who lost the race has about $1M to spend on legal fees to take it to court. Now multiply that by the number of invalid patents that a video codec might infringe...
Really, Google is the only company that matters. And maybe Netflix.
You might have those the wrong way around, at least for the US market. I didn't find newer figures in a quick search, but in 2013 YouTube consumed 18.69% of downstream bandwidth in the USA, Netflix consumed 31.62%. Netflix passed one third a little while ago, I'm not sure how YouTube has grown in that period, but I suspect it's still around 2/3 of the use of Netflix.
Cisco has a vested interest in things that use more bandwidth because it makes people buy more routers, but don't forget that Cisco also sells a load of high-end video conferencing systems. They're not just doing this to get other people to use it, they're doing it because they want to use it in their own stuff. If it's widely adopted by others, then this will mean that people will produce hardware implementations and that will reduce the CPU requirements for the products Cisco sells, making them cheaper to produce (Cisco's video conferencing stuff doesn't sell enough units to be worth an ASIC just for them - a fast enough DSP or CPU is cheaper than a custom ASIC). If it ends up in most smartphones, then that means that Cisco will be able to sell client software for their systems that runs on every phone your employees have.
I used to be able to put my hand on the CPU of my PC in the early 1990s while the thing was on. Good luck doing that now
And my laptop can do everything that the PC from the early '90s could do without even turning the fans on. Even a Raspberry Pi 2 outperforms a late-'90s PC handily and doesn't even have a heatsink (let alone a fan) on the SoC and can run happily from a battery.
Why do you think the power supply wattage keeps going up?
It doesn't, unless you're talking about high-end workstation machines (or gamer rigs, which are a similar and small market segment). The reason that I brought up the Alpha is because that's what people who had high-end workstations used and those things had 500W+ PSUs. Pentium-class machines had 230W PSUs at the entry level. Now, for basic office use, an Atom or similar with embedded Intel graphics and a small SSD will happily do what you need with a 30W total system power budget.
My laptop has a quad-core i7 (4+4 with hyperthreading), an nVidia GPU, and a 1TB SSD. The power supply is rated at 85W and when I'm using all of the cores, and the GPU, and hitting the SSD hard, and have the screen brightness turned to maximum, it's still charging the battery at a reasonable rate, so the total draw is a lot less than 85W in normal use. A Pentium from the early '90s wouldn't even turn on with an 85W PSU (don't forget, that Pentium had a load of logic in the north and southbridge chips that each drained power and a load of discrete ICs for various controllers that are now integrated into a single chip, plus a hard disk that drew a reasonable amount of power).
Those data points that you're picking are completely irrelevant for office machines. No one needs a 400W GPU for office work. You might need them for scientific computing, but there that 400W GPU is often replacing a 10kW cluster from a decade or so ago. Haswell-E is an 'enthusiast-class desktop' chip - i.e. a thing that idiot gamers with more money than sense buy so that they can feel 'leet. You won't find them in workstations or in office desktops.
Fact is a computer is today a major power hog in a regular house
In a regular house, there are no desktops. There are laptops, tablets, and smartphones. And, increasingly, only tablets and smartphones.
How about large screen LCDs? 245W for a 55".
So, about the same as a 24" CRT. Which do you think are more common: 24" CRTs 10 years ago, or 55" LCDs now?
Back when we used CRTs we also used smaller screens. 160W for a 36".
That's 160W for a new CRT, which is a lot more energy efficient than the ones we were using a decade ago (less loss, better phosphor). Even then, 30" CRTs were pretty rare a decade ago - I only knew a couple of people who had them, I don't know anyone who has a 55" LCD. You're more likely to have a projector for that size, and modern LED / laser projectors are even more power efficient for the same brightness.
Slashdot Mirror
The main issue for Microsoft was putting Windows-specific APIs in the java.* namespace. This broke the 'if you only use java.* stuff then your app will run anywhere' guarantee for Java developers and was in direct violation of the Java license (which included patent and copyright grants). Dalvik's register-based VM, which doesn't use the .class files at all, is partly a way of getting around the JVM patents and meaning that copyright is the only thing that they can infringe. As they're not using any code licensed from Oracle, the only argument left is that they're using the same interfaces.
Or you're doing something right. Good API design is good UI design. If your UI sucks in most pieces of software, your software is a lot less valuable. Most programmers are far too tolerant of crappy APIs and will happily use a poorly designed UI and blame other programmers who struggle.
Some bits are easy (for example, don't be the idiot LLVM contributor who thought that having isBundle() and isBundled() methods on the MachineInstr class that do completely different things was a good idea). Some bits are harder - making sure that you have consistent abstractions that you use across entire frameworks, making sure that you use consistent naming everywhere.
A good API is a considerable engineering effort. It's not excluded from copyright because it's not creative, it's excluded because interoperability is considered more important. The trend in copyright law has been removing exemptions that benefit society as a whole in favour of total control by the originator, so it's not a surprise that this is being weakened.
Rolex makes some relatively cheap watches. The ones I've seen in shops (and therefore probably cheaper online) start at around £250. They are, however, monumentally ugly. They're part of the trend in mens watches that say 'I need to assert my masculinity by showing that I can lug a big lump of metal around on my wrist all day'. The only watchmaker that I know of that makes watches that are aimed at people who appreciate good industrial design and want a watch that is easy to ready but very light is Skagen (they're also a fraction of the price of even a cheap Rolex). I've had one of their watches for around 8 years and not seen anything comparable from other manufacturers.
I suspect that's a big part of the reason that watch wearing has declined. Most of the watchmakers cater exclusively for the market segment that wants to make a statement (and that statement is: I have lots of money but no taste) and not for those that want something functional and aesthetically pleasing.
For quickly checking the time without having to pull something out of your pocket? And so you can still tell the time when you don't take your phone with you (a watch is a lot more portable than even a small phone)? I have a Skagen watch (which I've had for about 7 years now) which has a thin titanium mesh strap and is so thin that I can forget that I'm wearing it. No phone can replace that.
I guess you've never been to anything where the invitation says black tie as the dress code then? I have a few everyday wear shirts that I wear with cufflinks too, because the button fell off on one cuff and it was less effort to cut the other one off and wear cufflinks than sew on a replacement.
There are no essential features in any word processor that aren't covered by a linotype machine. That doesn't mean that you'd expect people to be equally productive with both.
LibreOffice has a less permissive license than OpenOffice, so can't be folded back in. LibreOffice's origins are Novell's Go-OO project, which included stuff that they refused to license under the upstream license and so could not be contributed back and stuff covered by the MS-Novell patent license that upstream wouldn't accept because it wasn't clear that the patent license applied to anyone distributing derived works.
The O'Reilly books that I've read look as if they've been skim-read by someone and then sent to the printer.
Exactly. I don't block ads. I do block tracking JavaScript. Anything that uses Flash / HTML5 video / audio needs me to click on it before I see it. The result? I very rarely see ads. Put plain-text ads that are relevant to the content of the page, and I might click on them. I used to click on Google ads periodically back when they did this, but they gradually went down the route of trying to profile me and find things that I was interested in and replaced all of the ads that were relevant to the stuff I was looking at now with ads for things that I bought last month and won't need to buy again for a long time.
The Chrome UI sucks on OS X, as does the lack of Keychain integration. You can fix the latter in Firefox with a plugin, but its UI is also decidedly non-native (thought a lot better than it was even 5 years ago).
Qt is a great way of writing Mac applications if your goal is to piss off your users. If you want an app that looks sort-of vaguely like a Mac app and doesn't behave at all like one, then use Qt.
If you have to ask that question, either you have never used git on the command line, or you should be permanently banned from ever designing user interfaces.
I do incremental LLVM builds on my laptop quite often. Unless I've changed a header that's included by a lot of things, they're quick, but the LLVM codebase has around 2200 C++ files, many of which are a few thousand lines long. If I'm making invasive changes, testing them on the bigger machine is a lot more pleasant - recompiling 2200 files on 32 cores is a lot faster than on 4+4 (and the Xeon cores are faster than the mobile i7 ones).
As for the RAM, FreeBSD make universe (which builds the base system for all supported target architectures) produces around 50GB of object code (which all wants to stay in the buffer cache so that the linker can read it quickly). Even LLVM by itself produces around 12GB when you do a debug build (which I don't as part of the FreeBSD build, but I do as part of regular LLVM development) and linking that really wants the linker to be pulling in the files from RAM for best performance.
The big machines have a few TBs of spinning rust, a 512GB SSD split between L2ARC and log device, and 256GB of RAM. The log device on the SSD makes a big difference because writes run at linear write to SSD speed, not random write to HDD speed (eventually it gets full if you keep doing it, but there's enough SSD that you rarely see that with out workloads). The big amount of RAM means that most reads are serviced from the OS buffer cache. The L2ARC means that most of the rest come from there.
I should mention that these are multi-user systems, though usually we're doing big compile jobs at random times (unlike on the CI systems, with similar specs, where we're doing them solidly round the clock). We turn on dedup for all home directories, which makes a big difference: everyone can have checkouts of the same source trees without using more disk / L2ARC / ARC space and object code is often deduplicated too. You do notice when more than one person is doing a big build though - the time increase is noticeable, even with enough RAM that neither of you is likely to be touching the disk.
Talk to some Netflix employees some time. You might be surprised.
My last two laptops have had SSDs. For big compile jobs, use a machine with an SSD and 256GB of RAM. Most of the I/O is serviced entirely from the buffer cache and never even goes to the SSD. It's CPU bound.
You might be surprised. Netflix currently supports around 80 different clients for their service (apps for various platforms, different technologies for the web interface, and embedded things). Codecs are a big issue for them.
That one has a 48 hour half-life and is a gas.
And is a gas that is so much lighter than air that it's hard to find on Earth because any released into the atmosphere floats quickly to the top and is skimmed off by solar wind. If you release a load of radioactive helium isotopes into the air, then anyone breathing in as they're released is likely to have problems, but the molecules that are not inhaled will be gone from the site within a few minutes. Not sure what isotope of Helium you're thinking of though - I'm not aware of any unstable isotopes that have a half life of over a second. If you meant Hydrogen, then deuterium is fairly stable and tritium has a half life of around 12 years. Tritium is a beta emitter (and glows - lots of key fobs and so on have tritium in them). It will dissipate in a similar way, though unlike helium it is likely to react with oxygen and fall as heavy water rain (not very dangerous - it's only a beta emitter, but it's not a great idea to inhale or drink it).
I'm not sure if they ever prototyped it (I don't think they did, but I wouldn't be entirely surprised), but there was a design that involved dropping a fusion warhead to the bottom of a mine shaft filled with water and then driving a geothermal-style power plant from the resulting steam.
It depends. Building a wood-fired steam engine is pretty easy: the amount of heat is fairly small and a slow trickle of water can take it away (turned into steam, driven past turbines or used to power pistons), keeping the boiler at an equilibrium temperature. Move up to a denser fuel and the engineering becomes harder - you need higher water pressure and to get the steam out faster. Move up to fission and the coolant cycle can get quite large - remember, if you're moving the water past the nuclear reaction then stray neutrons are going to turn it into heavy water and you're not going to want to just dump it (though you might want to extract the tritium for other uses), so you need a closed cycle where you can cool the water down enough that you can feed it back over the reactor in a loop, taking the energy out in the turbines somewhere. You often do this with a couple of loops of coolant, where the coolant that's run over the reactor heats something else which then drives the turbines, so your turbines are not having to pass irradiated coolant.
Scale it up more and it becomes an even more difficult engineering challenge. For comparison, look at a 100W lightbulb and a 100W Pentium 4. Both need to dissipate 100W, but one is doing it over the surface of a large bulb, the other over about a square centimetre on the top of the package - the total heat is the same, but it's a lot harder to keep the P4 cool than it is to cool the lightbulb.
From the first source I found, nuclear deaths per TWh are 0.04 (coal is 15-170, depending on the statistics you pick). While 0.04 is not quite zero, that's where it would end up if you did any rounding...
The real problem is the cost to fight them. In your example, two people invent at the same time, both have evidence that they invented prior to the filing. That's a clear cut case of prior art and the patent would be invalid. The only requirement is that the person who lost the race has about $1M to spend on legal fees to take it to court. Now multiply that by the number of invalid patents that a video codec might infringe...
Really, Google is the only company that matters. And maybe Netflix.
You might have those the wrong way around, at least for the US market. I didn't find newer figures in a quick search, but in 2013 YouTube consumed 18.69% of downstream bandwidth in the USA, Netflix consumed 31.62%. Netflix passed one third a little while ago, I'm not sure how YouTube has grown in that period, but I suspect it's still around 2/3 of the use of Netflix.
Slashdot: Where a thread about Thor goes from Marvel to Stargate SG-1, without ever going near norse mythology.
Cisco has a vested interest in things that use more bandwidth because it makes people buy more routers, but don't forget that Cisco also sells a load of high-end video conferencing systems. They're not just doing this to get other people to use it, they're doing it because they want to use it in their own stuff. If it's widely adopted by others, then this will mean that people will produce hardware implementations and that will reduce the CPU requirements for the products Cisco sells, making them cheaper to produce (Cisco's video conferencing stuff doesn't sell enough units to be worth an ASIC just for them - a fast enough DSP or CPU is cheaper than a custom ASIC). If it ends up in most smartphones, then that means that Cisco will be able to sell client software for their systems that runs on every phone your employees have.
I used to be able to put my hand on the CPU of my PC in the early 1990s while the thing was on. Good luck doing that now
And my laptop can do everything that the PC from the early '90s could do without even turning the fans on. Even a Raspberry Pi 2 outperforms a late-'90s PC handily and doesn't even have a heatsink (let alone a fan) on the SoC and can run happily from a battery.
Why do you think the power supply wattage keeps going up?
It doesn't, unless you're talking about high-end workstation machines (or gamer rigs, which are a similar and small market segment). The reason that I brought up the Alpha is because that's what people who had high-end workstations used and those things had 500W+ PSUs. Pentium-class machines had 230W PSUs at the entry level. Now, for basic office use, an Atom or similar with embedded Intel graphics and a small SSD will happily do what you need with a 30W total system power budget.
My laptop has a quad-core i7 (4+4 with hyperthreading), an nVidia GPU, and a 1TB SSD. The power supply is rated at 85W and when I'm using all of the cores, and the GPU, and hitting the SSD hard, and have the screen brightness turned to maximum, it's still charging the battery at a reasonable rate, so the total draw is a lot less than 85W in normal use. A Pentium from the early '90s wouldn't even turn on with an 85W PSU (don't forget, that Pentium had a load of logic in the north and southbridge chips that each drained power and a load of discrete ICs for various controllers that are now integrated into a single chip, plus a hard disk that drew a reasonable amount of power).
Those data points that you're picking are completely irrelevant for office machines. No one needs a 400W GPU for office work. You might need them for scientific computing, but there that 400W GPU is often replacing a 10kW cluster from a decade or so ago. Haswell-E is an 'enthusiast-class desktop' chip - i.e. a thing that idiot gamers with more money than sense buy so that they can feel 'leet. You won't find them in workstations or in office desktops.
Fact is a computer is today a major power hog in a regular house
In a regular house, there are no desktops. There are laptops, tablets, and smartphones. And, increasingly, only tablets and smartphones.
How about large screen LCDs? 245W for a 55".
So, about the same as a 24" CRT. Which do you think are more common: 24" CRTs 10 years ago, or 55" LCDs now?
Back when we used CRTs we also used smaller screens. 160W for a 36".
That's 160W for a new CRT, which is a lot more energy efficient than the ones we were using a decade ago (less loss, better phosphor). Even then, 30" CRTs were pretty rare a decade ago - I only knew a couple of people who had them, I don't know anyone who has a 55" LCD. You're more likely to have a projector for that size, and modern LED / laser projectors are even more power efficient for the same brightness.