Open source is a licensing model. Taking responsibility is part of the contract. The difference between open source and proprietary code is that you have the option of going to more than one company to get it audited or get bugs fixed with open source. You can negotiate a better support contract because there are multiple companies willing to take your money. If you're buying software without a support contract then you're in a similar boat with open source or proprietary software: with open source you either fix it yourself (or pay someone else to fix it for you) or wait for the next version, with proprietary software you buy the next version, and in both cases you hope that the next version fixes it.
Don't conflate community supported with open source. Just because you have a license that grants you the ability to redistribute and modify the code does not mean that you aren't handing over a big pile of money to have someone willing to fix bugs on short notice.
And ARM has one huge advantage over Intel - everybody else except Intel has their own ARM SOC these days, so designers can shop around to get the chip they want, from the supplier they want. And they can easily switch to a different supplier without having to throw out their entire investment into the architecture.
Not really. The ARM part is pretty similar currently between all of them. With the exception of Marvell's line, they're all either stock ARM designs or slight tweaks (e.g. the improved floating point pipeline on Qualcomm's offerings). If one SoC vendor offers something better than another, it will typically be in terms of other cores on the SoC, and these are generally not compatible between vendors.
This is something that ARM is trying to fix with ARMv8. They intentionally delayed the release of the ARM-designed cores to allow a few other companies to have independent implementations arrive on the market at about the same time. This means that integrators will be able to shop around for ARMv8 cores that match their exact requirements.
Intel does currently have two big advantages over ARM. The first is that they are typically a generation (or, at least, half a generation) ahead of other fab owners. This is the same advantage that allowed them to compete with superior designs from AMD for the late '90s: they could get higher clocks at the same power, and more chips per wafer (meaning lower cost). The other advantage is that they are a much larger company and so can afford to make half a dozen guesses about the state of the market at the end of the five-year chip design cycle. They can then have different teams working on chips for those market predictions and only actually ship one or two of the final microarchitectures. In contrast, every ARM chip has to be a success, often for several generations (for example, the new A7 is an A8 with a number of refinements and a lot of tweaking for optimisation and some slight ISA tweaks to make it instruction-set compatible with the A15).
The odd thing is, what you've described is how unions work in much of the world. For example, in the UK if a union negotiates a better compensation deal for its members, then this deal must also be offered to all non-union staff. Companies are not allowed to discriminate either for or against union members, which means that you can't be required to join a union to work somewhere and unions can't enforce union-only shops. In many professions, there are multiple unions that compete for members.
The slowest PowerPC Apple sold was about 50% faster than the fastest m68K they sold. The slowest x86 chip the sold was slower than the fastest PowerPC, but most of their sales at that time were laptops and the Core 2 that they introduced in the second generation (when it actually made sense to by an Intel Mac) was around 2GHz and dual core, replacing a 1.5GHz (1.67GHz on the really top end) PowerPC G4 (which, clock for clock, was slower than the Core 2 and was crippled by poor memory bandwidth). When I switched, I forgot that I was running a PowerPC build of VLC: it was using about 80% of one core when running emulated, where previously it had been using about 50% when running native on PowerPC - it was slower, but not enough that it was noticeable. And when I installed a native version, the CPU load dropped to about 20%, making it much faster than it had ever been on PowerPC.
Switching on mobile chips would not give them anything like this level of performance differential, and so emulated code would be slower. It might not be noticeably slower, if the performance-critical parts are all in CoreAnimation or OpenCL / GLSL, but slower in a mobile device means lower battery life, and that's a much more serious constraint.
The summary made me laugh. 'scientists says it has verified that quantum effects are indeed at work in the D-Wave processor'. Exactly the same claim could be made about pretty much any vaguely computer: how do they think transistors work?
With the exception of a very few fairly simple algorithms, anything that you can do in the cloud using homomorphic encryption, you can also do on your laptop without it...
Pretty much all of it. I don't know what a good business model for a FOSS game would be. Probably the same one that the TV studios use: provide a partial implementation (a pilot) for free and charge people for you to finish it. Once you've got enough funding, finish the game and release it. TV studios use channels as middle men in this situation, but there's no reason that it wouldn't work without the middle men.
The vast majority of software companies sell Free Software. Free Software just means that the person receiving the code has a set of rights to use, modify, and redistribute it, which is the case for most bespoke software, which is what most software companies (and, indeed, most software developers) sell.
It is difficult trying to combine selling commodity off the shelf (COTS) software with Free Software, but fortunately for 'FOSS Shills' COTS software has never been more than about 10% of the total software market.
Forking does that, because the GPL doesn't require that you contribute your changes back only forwards: you must give the code to the people you give binaries to, nothing more. It's easy to fork a project, make some structural changes, and then release your version that has all of the code that isn't necessary for your use removed and other things that are annoying for anyone who doesn't have access to the rest of your system added. The code is still available, but the cost of merging changes back upstream is often greater than the cost of rewriting them from scratch.
This is fine according to RMS, because the GPL is not meant to protect the authors of the original code, it's meant to protect the users who receive products based on it.
Add to that: speed doesn't matter to commercial transports nearly as much as reliability. There are a lot more people who are willing to accept shipment in 3 weeks from today than in 2-4 weeks from today. 5 knots is probably a little bit too slow, but 10-15 knots is a very respectable speed for a large cargo ship. It doesn't seem like much, but you cover a lot of distance doing 10 knots 24 hours a day...
Most of the more distant islands were colonised during small ice ages, when it was possible to walk much of the distance and people had to move a lot because food was scarce. There was thought to be a land bridge from South-East Asia to South America well after homo sapiens came along, and getting from Europe to North America via Iceland and Greenland wasn't such a massive journey for a lost Viking ship aiming for the islands around the north of Scotland.
For a long time, the limiting factor was the amount of food and water that you could carry. The reason that Columbus couldn't get funding for so long was that intelligent people did the calculations of his journey time and worked out that he'd run out of food about half way to India. Fortunately for him, there was a convenient continent a bit less than half way there for him to stop and resupply...
Sailing ships can be becalmed for days or even weeks. This is more of a problem the bigger the ship, as the more wind you need to start it moving again. Even at the best of times, their speed is highly variable, depending on wind speed and direction - if it's a head wind then they need to tack, which can significantly reduce their maximum straight-line speed, if it's a run or a reach then they can go faster. This makes them tricky from an economic perspective, where you need to book dock time well in advance to get goods loaded and unloaded and where your customers typically require things delivered within a fairly narrow window. For low-priority goods, it might be fine, as long as you were willing to wait at the far end for a few days for a free slot in the unloading dock.
There have been some attempts to address this, by flying kits up in the jetstream and using their rotation to drive a screw. This has a lot of potential, but the last demo I saw was only generating 20% of the energy required to propel the craft - the rest came from burning oil.
Sure, that's why, in the past year, we've had a load of network stack improvements contributed back by NetFlix and Juniper, a new flash filesystem and NAND layer by a company building embedded systems, a load of storage stack improvements contributed by iX Systems and NetApp, HyperV support contributed by Microsoft, sandboxing support funded by Google...
I read a different book, in the '80s about things that you could do with a BBC Micro. One of them was a sound recogniser, which worked in a similar way with a 1MHz 6502. Most of this kind of book seemed to disappear in the '90s though, and didn't really start to reappear until recently.
No, if you don't distribute the binary then you still have no obligation to distribute the code under GPLv3. Similarly, if you only use a program via file descriptors then GPLv3 doesn't require you to do anything except point your customers at an upstream URL.
The OS X kernel includes a lot of code from FreeBSD, including most of the process management code, the MAC framework, much of the VM subsystem, and so on. The userland includes FreeBSD libc and mostly FreeBSD utilities (the NetBSD code was largely gone by Rhapsody DR2). Check the license files on opensource.apple.com sometime...
It's not that clear cut. Sony is actually distributing the binaries, but for a lot of potential contributors the GPL doesn't force anything: they use their derived work internally, never distribute it, so don't need to share any changes. One the other hand, they will often avoid GPL'd code because of the potential for it to affect their ability to turn something into a product later. In this case, they'll either develop their own or, more likely, license a proprietary version.
Without the legal constraint, there are still reasons to push changes upstream. Maintaining a fork is expensive. Bugs get fixed and new features introduced upstream and the more you've diverged, the harder it is to pull the changes. This is why Juniper has recently been pushing a lot of things to FreeBSD - they've realised how much it was costing them for JunOS to be significantly different to a modern FreeBSD.
Even with the GPL's constraint, there are lots of ways around it. Companies ship mobile phones with Linux kernels and binary display drivers, by only using the public kernel interfaces and loading the driver late in the boot process, with most of it running in userspace. At worst, they're required to release the code for their shim that exports the hardware registers directly to userspace. For other code, you can run it in a separate process and the GPL doesn't apply.
We've ported Dalvik to FreeBSD. The Binder IPC stuff also needs porting, however having done this the isolation between applications could be much better enforced using Capsicum. For real-world usage, you'd also need to port the GPU drivers, because Android has its own graphics stack.
I asked that would he be so kind and tell me who they hired. He said that he couldn't tell me details.
This is annoying, but it's something that legal tells most companies. If you were not hired for some reason that is not directly related to your ability to perform the job, then you might have grounds for a lawsuit. It's best not to give out any information.
I'd agree with the other poster. This kind of question is intended to see how you approach a problem. Can you think about intelligent solutions to a problem that you haven't seen before? The answer doesn't matter, the process of getting to it does. If they asked you to in-person interview, it means you passed the phone screening, which then isn't counted for the rest of the hiring process. The in-person interviews are fun. I turned down a job at Google, but I found the interviews fun - they ask you to think about things that you haven't thought about before (well, in theory - one of my interviewers hadn't done her homework and asked me a question about a subject I'd published papers on, expecting me to have no background knowledge). Whether you take the job or not, the experience is enjoyable (and you get to visit somewhere fun at their expense).
If you only got a free lunch, then you did the interview wrong. The trick with Google interviews is to make sure they take place in a country you want to visit. They'll pay for your flight, meals, and one night in a 4* hotel, and then you can tack on extra time if you want. If you visit somewhere where you have friends and can get free accommodation, then it's a good idea to go through it fairly frequently. Interestingly, even if you turn them down, their recruiters will start sending you emails about six months later about coming back to see if they have more interesting jobs for you.
Slashdot Mirror
Open source is a licensing model. Taking responsibility is part of the contract. The difference between open source and proprietary code is that you have the option of going to more than one company to get it audited or get bugs fixed with open source. You can negotiate a better support contract because there are multiple companies willing to take your money. If you're buying software without a support contract then you're in a similar boat with open source or proprietary software: with open source you either fix it yourself (or pay someone else to fix it for you) or wait for the next version, with proprietary software you buy the next version, and in both cases you hope that the next version fixes it.
Don't conflate community supported with open source. Just because you have a license that grants you the ability to redistribute and modify the code does not mean that you aren't handing over a big pile of money to have someone willing to fix bugs on short notice.
And ARM has one huge advantage over Intel - everybody else except Intel has their own ARM SOC these days, so designers can shop around to get the chip they want, from the supplier they want. And they can easily switch to a different supplier without having to throw out their entire investment into the architecture.
Not really. The ARM part is pretty similar currently between all of them. With the exception of Marvell's line, they're all either stock ARM designs or slight tweaks (e.g. the improved floating point pipeline on Qualcomm's offerings). If one SoC vendor offers something better than another, it will typically be in terms of other cores on the SoC, and these are generally not compatible between vendors.
This is something that ARM is trying to fix with ARMv8. They intentionally delayed the release of the ARM-designed cores to allow a few other companies to have independent implementations arrive on the market at about the same time. This means that integrators will be able to shop around for ARMv8 cores that match their exact requirements.
Intel does currently have two big advantages over ARM. The first is that they are typically a generation (or, at least, half a generation) ahead of other fab owners. This is the same advantage that allowed them to compete with superior designs from AMD for the late '90s: they could get higher clocks at the same power, and more chips per wafer (meaning lower cost). The other advantage is that they are a much larger company and so can afford to make half a dozen guesses about the state of the market at the end of the five-year chip design cycle. They can then have different teams working on chips for those market predictions and only actually ship one or two of the final microarchitectures. In contrast, every ARM chip has to be a success, often for several generations (for example, the new A7 is an A8 with a number of refinements and a lot of tweaking for optimisation and some slight ISA tweaks to make it instruction-set compatible with the A15).
The odd thing is, what you've described is how unions work in much of the world. For example, in the UK if a union negotiates a better compensation deal for its members, then this deal must also be offered to all non-union staff. Companies are not allowed to discriminate either for or against union members, which means that you can't be required to join a union to work somewhere and unions can't enforce union-only shops. In many professions, there are multiple unions that compete for members.
Is it just me, or did Intel's revenue graph look like the Moore's Law graph when Gordon Moore was CEO?
The slowest PowerPC Apple sold was about 50% faster than the fastest m68K they sold. The slowest x86 chip the sold was slower than the fastest PowerPC, but most of their sales at that time were laptops and the Core 2 that they introduced in the second generation (when it actually made sense to by an Intel Mac) was around 2GHz and dual core, replacing a 1.5GHz (1.67GHz on the really top end) PowerPC G4 (which, clock for clock, was slower than the Core 2 and was crippled by poor memory bandwidth). When I switched, I forgot that I was running a PowerPC build of VLC: it was using about 80% of one core when running emulated, where previously it had been using about 50% when running native on PowerPC - it was slower, but not enough that it was noticeable. And when I installed a native version, the CPU load dropped to about 20%, making it much faster than it had ever been on PowerPC.
Switching on mobile chips would not give them anything like this level of performance differential, and so emulated code would be slower. It might not be noticeably slower, if the performance-critical parts are all in CoreAnimation or OpenCL / GLSL, but slower in a mobile device means lower battery life, and that's a much more serious constraint.
The summary made me laugh. 'scientists says it has verified that quantum effects are indeed at work in the D-Wave processor'. Exactly the same claim could be made about pretty much any vaguely computer: how do they think transistors work?
With the exception of a very few fairly simple algorithms, anything that you can do in the cloud using homomorphic encryption, you can also do on your laptop without it...
Pretty much all of it. I don't know what a good business model for a FOSS game would be. Probably the same one that the TV studios use: provide a partial implementation (a pilot) for free and charge people for you to finish it. Once you've got enough funding, finish the game and release it. TV studios use channels as middle men in this situation, but there's no reason that it wouldn't work without the middle men.
The vast majority of software companies sell Free Software. Free Software just means that the person receiving the code has a set of rights to use, modify, and redistribute it, which is the case for most bespoke software, which is what most software companies (and, indeed, most software developers) sell.
It is difficult trying to combine selling commodity off the shelf (COTS) software with Free Software, but fortunately for 'FOSS Shills' COTS software has never been more than about 10% of the total software market.
Forking does that, because the GPL doesn't require that you contribute your changes back only forwards: you must give the code to the people you give binaries to, nothing more. It's easy to fork a project, make some structural changes, and then release your version that has all of the code that isn't necessary for your use removed and other things that are annoying for anyone who doesn't have access to the rest of your system added. The code is still available, but the cost of merging changes back upstream is often greater than the cost of rewriting them from scratch.
This is fine according to RMS, because the GPL is not meant to protect the authors of the original code, it's meant to protect the users who receive products based on it.
Add to that: speed doesn't matter to commercial transports nearly as much as reliability. There are a lot more people who are willing to accept shipment in 3 weeks from today than in 2-4 weeks from today. 5 knots is probably a little bit too slow, but 10-15 knots is a very respectable speed for a large cargo ship. It doesn't seem like much, but you cover a lot of distance doing 10 knots 24 hours a day...
Most of the more distant islands were colonised during small ice ages, when it was possible to walk much of the distance and people had to move a lot because food was scarce. There was thought to be a land bridge from South-East Asia to South America well after homo sapiens came along, and getting from Europe to North America via Iceland and Greenland wasn't such a massive journey for a lost Viking ship aiming for the islands around the north of Scotland.
For a long time, the limiting factor was the amount of food and water that you could carry. The reason that Columbus couldn't get funding for so long was that intelligent people did the calculations of his journey time and worked out that he'd run out of food about half way to India. Fortunately for him, there was a convenient continent a bit less than half way there for him to stop and resupply...
Sailing ships can be becalmed for days or even weeks. This is more of a problem the bigger the ship, as the more wind you need to start it moving again. Even at the best of times, their speed is highly variable, depending on wind speed and direction - if it's a head wind then they need to tack, which can significantly reduce their maximum straight-line speed, if it's a run or a reach then they can go faster. This makes them tricky from an economic perspective, where you need to book dock time well in advance to get goods loaded and unloaded and where your customers typically require things delivered within a fairly narrow window. For low-priority goods, it might be fine, as long as you were willing to wait at the far end for a few days for a free slot in the unloading dock.
There have been some attempts to address this, by flying kits up in the jetstream and using their rotation to drive a screw. This has a lot of potential, but the last demo I saw was only generating 20% of the energy required to propel the craft - the rest came from burning oil.
Sure, that's why, in the past year, we've had a load of network stack improvements contributed back by NetFlix and Juniper, a new flash filesystem and NAND layer by a company building embedded systems, a load of storage stack improvements contributed by iX Systems and NetApp, HyperV support contributed by Microsoft, sandboxing support funded by Google...
I don't, I'm afraid. My school had a book shelf full of books of fun projects involving the BBC, and this was one entry in one of them.
I read a different book, in the '80s about things that you could do with a BBC Micro. One of them was a sound recogniser, which worked in a similar way with a 1MHz 6502. Most of this kind of book seemed to disappear in the '90s though, and didn't really start to reappear until recently.
No, if you don't distribute the binary then you still have no obligation to distribute the code under GPLv3. Similarly, if you only use a program via file descriptors then GPLv3 doesn't require you to do anything except point your customers at an upstream URL.
The OS X kernel includes a lot of code from FreeBSD, including most of the process management code, the MAC framework, much of the VM subsystem, and so on. The userland includes FreeBSD libc and mostly FreeBSD utilities (the NetBSD code was largely gone by Rhapsody DR2). Check the license files on opensource.apple.com sometime...
It's not that clear cut. Sony is actually distributing the binaries, but for a lot of potential contributors the GPL doesn't force anything: they use their derived work internally, never distribute it, so don't need to share any changes. One the other hand, they will often avoid GPL'd code because of the potential for it to affect their ability to turn something into a product later. In this case, they'll either develop their own or, more likely, license a proprietary version.
Without the legal constraint, there are still reasons to push changes upstream. Maintaining a fork is expensive. Bugs get fixed and new features introduced upstream and the more you've diverged, the harder it is to pull the changes. This is why Juniper has recently been pushing a lot of things to FreeBSD - they've realised how much it was costing them for JunOS to be significantly different to a modern FreeBSD.
Even with the GPL's constraint, there are lots of ways around it. Companies ship mobile phones with Linux kernels and binary display drivers, by only using the public kernel interfaces and loading the driver late in the boot process, with most of it running in userspace. At worst, they're required to release the code for their shim that exports the hardware registers directly to userspace. For other code, you can run it in a separate process and the GPL doesn't apply.
We've ported Dalvik to FreeBSD. The Binder IPC stuff also needs porting, however having done this the isolation between applications could be much better enforced using Capsicum. For real-world usage, you'd also need to port the GPU drivers, because Android has its own graphics stack.
Try again.
I asked that would he be so kind and tell me who they hired. He said that he couldn't tell me details.
This is annoying, but it's something that legal tells most companies. If you were not hired for some reason that is not directly related to your ability to perform the job, then you might have grounds for a lawsuit. It's best not to give out any information.
I'd agree with the other poster. This kind of question is intended to see how you approach a problem. Can you think about intelligent solutions to a problem that you haven't seen before? The answer doesn't matter, the process of getting to it does. If they asked you to in-person interview, it means you passed the phone screening, which then isn't counted for the rest of the hiring process. The in-person interviews are fun. I turned down a job at Google, but I found the interviews fun - they ask you to think about things that you haven't thought about before (well, in theory - one of my interviewers hadn't done her homework and asked me a question about a subject I'd published papers on, expecting me to have no background knowledge). Whether you take the job or not, the experience is enjoyable (and you get to visit somewhere fun at their expense).
If you only got a free lunch, then you did the interview wrong. The trick with Google interviews is to make sure they take place in a country you want to visit. They'll pay for your flight, meals, and one night in a 4* hotel, and then you can tack on extra time if you want. If you visit somewhere where you have friends and can get free accommodation, then it's a good idea to go through it fairly frequently. Interestingly, even if you turn them down, their recruiters will start sending you emails about six months later about coming back to see if they have more interesting jobs for you.