Just curious, has anyone done a gpu power/performance comparison of Imagination Technology's powervr and Nvidia's tegra platforms recently? I don't know that they would clean up by licensing their IP out; it seems to me Nvidia stuff has always been more performance focused than power conscious which is something that is extremely hard to sell in the mobile segment.
I am not a lawyer, but I find it hard to believe Samsung is violating any of Nvidia's patents directly by using Qualcomm's Snapdragon 801 and 805 in a product. They received the part and associated driver software from QCOM as a final product and all components and features therein are protected from patent violations. Just like you can't be sued for violating Nvidia's patents by using an AMD GPU which has Nvidia-patented features in your PC, Samsung is protected by purchasing the part from QCOM. Nvidia could block further sales of the Snapdragon CPU to Samsung, but not sales of derived products; even though to to the end consumer it amounts to the same thing. So unless Samsung is violating their agreement with QCOM by enabling features they didn't license from QCOM, NV can't touch them here.
Similar deal with Exynos (Samsung's SOC) since it licenses the IP involved directly from ARM and Imagination Technologies (Mali and PowerVR GPUs respectively). Unless Samsung's legal team is collectively idiots and/or assholes, they should be protected by their upstream licensing agreements.
Then again, NV is never going to sue ARM because they would be in a seriously shitty position to renew *their* ARM licenses (if ARM didn't just terminate them on the spot) and then ARM would laugh all the way to the bank about who isn't shipping products.
Based on that, it's my opinion that Samsung shouldn't be involved in this lawsuit and Nvidia just pulled them in because that's where the money is.
FMIQ (as implemented in the imgSeek server) is pretty good at detecting everything but crops, and that was 5-6 years ago when I last played with it. It likely has no problems with them now. This is a reasonably well solved problem.
The only part I care about is being able to take the interchangeable radio/baseband unit out of model A on carrier X and put it in model B and continue my service on X with them none the wiser, or even remove the radio entirely and operate without cellular features. Maybe even swap in a part97 radio instead. Ok, that's asking for the moon, but I can dream.
From the way the article reads, it's more like everyone else made their save vs spell... Or perhaps that he lost his save vs PPDM. Seems like after he made his initial critical mistake (allowing investment options to bypass his majority ownership), he couldn't recover without just divesting himself from TSR and starting over before the flagship D&D product was born, which, as a primary creator, he might have been able to pull off.
The behind closed doors shenanigans, manipulations and backstabbery are about right for any D&D game I've ever been in.
Or more established/full featured, openvz, xen pv, lxc, cgroups/namespaces, and friends. I think linux (the kernel) already has the tools necessary to do task prioritization like the article requests.
I can design a shed and oversee or perform its construction. That does not make me an architect.
I can design and build a model car with a little spring-and-gear engine. That does not make me a mechanical engineer.
I can design and build a little circuit "piano" with pushbuttons and a 555 timer. That does not make me an electrical engineer.
I can lead a team to build proposals; reasonably accurately gauge task complexity; predict completion dates and manpower requirements; define deliverables and release criteria; control defect introduction through manual and automated unit and system tasting; build accurate development, maintenance, and operation documentation; and actually write, debug, and review efficient, best-practices-compliant code for custom software exceeding 100k LOC of new code or modifications per contract, not counting software packages integrated from other ISVs, capable of reliably processing millions of financial and medical transactions per day. Does that make me a software engineer?
Your cellphone is just a brick without software and firmware designed by thousands of developers with millions of hours of dev time, a significant portion of it in critical areas where flaws can result in physical damage, horrible performance or just plain crashing. Your car engine is controlled by a PCM driven by software, weighing in with probably multiple megabytes of code and lookup tables, designed to increase your fuel efficiency beyond what you could get with a mechanical system alone, where flaws will very likely cause serious mechanical and safety problems. The ridiculously convoluted system of wires, routers, switches, and servers that got this message from me to you is all dependent on software largely written by some team or other of developers in a controlled and systematic process and certainly not a million monkeys at random.
Software engineering is real. Many of them are even licensed as professional engineers now. Your conception of who they are, what they do, and their importance to your way of life appears to be flawed.
Of all the explanations given so far, AC is the only one that has hit the crux of the matter. I don't agree with his assessment of runtime/tooling as there is middleware which will enable porting with relative ease between platforms. But it's absolutely true that if the garden owner tosses you out, your options are few in number, especially as a small developer and they can do so for any reason they want. If the platform owner changes the way part of their platform works and it completely breaks your application (android 4.4.2 anyone?) you must quickly adapt or (get bad reviews and) die--hobbiests don't have time to drop everything and fix their app and if my understanding is correct, there is no expectation of long term (>2 yr) platform API stability (in specific example, push notifications on android).
Mobile devs are stuck with three evil giants who are conflicted on whether they want you to fill their garden with useful tools or toss you because you've stepped into their safety zone.
As far as development costs go, that is absolutely rock-bottom cheap. Indy mobile developers don't pay 1.5k+ USD for a development-only unit with in-system debugging capability. They don't pay 1k+ per year, per seat for the tool suite. They don't pay 10k+ for external auditing and verification for major releases. It costs nothing to load unsigned apks on android. It costs nothing to load a binary from Xcode onto a target iOS device. The only thing that costs money is development equipment, which is less than 600 USD each for all major mobile platforms, and distribution, the 100$/yr being discussed.
500 per year for an entire team is laughable if you produce one good app with 500 sales (or donations) per year at a dollar each. Get four friends with the same hobby as you. Buy your release licenses as a club. Hell, go to your mom with the app you wrote and have her play around with it. I bet if she likes it she'll just give you the 100 USD to buy an iOS distribution license.
The article would classify sandboxing as one of the many layers that the industry has added on instead of fixing the fundamental problem with software development culture that values minimizing time-to-market significantly over security.
Not to branch too far off topic here, but this sounds like a pretty ideal use-case for microkernels allowing developers to slowly squash features into the trusted memory spaces after they've proven themselves in untrusted memory spaces while still bringing new features in regularly. The security vs performance tradeoff seems pretty reasonable.
If you made a general-purpose pocket computer that has a LTE addon module (which you license as a single unit), how much of that royalty pool just melts away?
Even for domain experts, we're talking about hard problems; problems hard enough that we've only recently been able to apply them reliably in the field. This is definitely a nascent technology, and while I think it will be a societal net positive (decreased accident rate, increased fuel economy), there's still a lot of room to grow and improve. I know I personally won't be getting one until the cost is near parity with manual vehicles, whether that be through insurance incentives or vehicle time sharing; or I become a bit too old to drive myself around reliably.
Is it feasible to legally obligate all entities operating in the USA to abide by all safeguards and regulations required of HIPAA data if the data they have could be so classified?
Despite being in the running for the worst analogy ever, let's go with this.
You own the gun. Blizzard mails you bullets and invites you to their shooting range. You take the bullets and gun to the range and shoot them however you please as long as you follow the range rules. You bring sandbags and a bench to shoot straighter in competition without telling Blizzard. Blizzard sues the sandbag and bench makers because you cheated.
Fortran is a Paper-Handled Plastic Shovel +4 of SCIENCE, forged in the early days when the world was young upon the ancient IBM 704. A keen observer might still find where John Backus himself scrawled "F*@# ASM!" in the crossword puzzle, its margins filled with arcane formulae from which the secrets of missile guidance emerged. It has fought and won many battles as an agent of the Holy Maths against the forces of nature, problems inscrutable, and libelous apocrypha. In its wake are the algorithms and research papers which lay the foundations of our modern tools, many of which are still used behind the scenes today. It is a thing of great purity, not tainted by the crude indelicacies of ui design or text processing; these tasks it leaves to other tools. Numbers go in, solutions come out, transformed by algorithms proven true over so many years.
Do not so lightly cast aside a tool which has proven its worth many times over.
Of the people I know who own high end timepieces, returning them to their holder at night where they rest consistently in nearly exactly the same spot is not a problem. It's just like handling jewelry; everything has its place.
To hyperbolically extend your argument, pretend you looking for an embedded systems kernel developer. Applicant A has worked on projects with hundreds of thousands of lines of PHP, so you should hire A because she can google it. Having direct knowledge is sometimes helpful.
There are several Satoshi Nakamotos living in North America and beyond - both dead and alive - including a Ralph Lauren menswear designer in New York and another who died in Honolulu in 2008, according to the Social Security Index's Death Master File. There's even one on LinkedIn who claims to have started Bitcoin and is based in Japan. But none of these profiles seem to fit other known details and few of the leads proved credible. Of course, there is also the chance "Satoshi Nakamoto" is a pseudonym, but that raises the question why someone who wishes to remain anonymous would choose such a distinctive name. It was only while scouring a database that contained the registration cards of naturalized U.S. citizens that a Satoshi Nakamoto turned up whose profile and background offered a potential match. But it was not until after ordering his records from the National Archives and conducting many more interviews that a cohesive picture began to take shape.
Late readers will note that the paragraph wiredog is quoting has been completely removed from the original Newsweek source, but it appears in quotation by other articles, for example, this washington post blog article:
http://www.washingtonpost.com/...
The original paragraph was as parent quoted:
It was only while scouring a database that contained the registration cards of naturalized U.S. citizens that a Satoshi Nakamoto turned up whose profile and background offered a potential match. But it was not until after ordering his records from the National Archives and conducting many more interviews that a cohesive picture began to take shape.
The idea that anybody can search databases of federal government-curated vital records for a specific profile to identify any given person without proof of relationship or a court order is more than a little horrifying.
Slashdot Mirror
I'm specifically referencing exhaustion/first sale doctrine. I believe that should apply, but as you pointed out, I could be wrong.
Just curious, has anyone done a gpu power/performance comparison of Imagination Technology's powervr and Nvidia's tegra platforms recently? I don't know that they would clean up by licensing their IP out; it seems to me Nvidia stuff has always been more performance focused than power conscious which is something that is extremely hard to sell in the mobile segment.
I am not a lawyer, but I find it hard to believe Samsung is violating any of Nvidia's patents directly by using Qualcomm's Snapdragon 801 and 805 in a product. They received the part and associated driver software from QCOM as a final product and all components and features therein are protected from patent violations. Just like you can't be sued for violating Nvidia's patents by using an AMD GPU which has Nvidia-patented features in your PC, Samsung is protected by purchasing the part from QCOM. Nvidia could block further sales of the Snapdragon CPU to Samsung, but not sales of derived products; even though to to the end consumer it amounts to the same thing. So unless Samsung is violating their agreement with QCOM by enabling features they didn't license from QCOM, NV can't touch them here.
Similar deal with Exynos (Samsung's SOC) since it licenses the IP involved directly from ARM and Imagination Technologies (Mali and PowerVR GPUs respectively). Unless Samsung's legal team is collectively idiots and/or assholes, they should be protected by their upstream licensing agreements.
Then again, NV is never going to sue ARM because they would be in a seriously shitty position to renew *their* ARM licenses (if ARM didn't just terminate them on the spot) and then ARM would laugh all the way to the bank about who isn't shipping products.
Based on that, it's my opinion that Samsung shouldn't be involved in this lawsuit and Nvidia just pulled them in because that's where the money is.
FMIQ (as implemented in the imgSeek server) is pretty good at detecting everything but crops, and that was 5-6 years ago when I last played with it. It likely has no problems with them now. This is a reasonably well solved problem.
The only part I care about is being able to take the interchangeable radio/baseband unit out of model A on carrier X and put it in model B and continue my service on X with them none the wiser, or even remove the radio entirely and operate without cellular features. Maybe even swap in a part97 radio instead. Ok, that's asking for the moon, but I can dream.
From the way the article reads, it's more like everyone else made their save vs spell... Or perhaps that he lost his save vs PPDM. Seems like after he made his initial critical mistake (allowing investment options to bypass his majority ownership), he couldn't recover without just divesting himself from TSR and starting over before the flagship D&D product was born, which, as a primary creator, he might have been able to pull off.
The behind closed doors shenanigans, manipulations and backstabbery are about right for any D&D game I've ever been in.
They probably have regression test cases to make sure bugs in the source are preserved. Wouldn't want to spoil the original experience...
Or more established/full featured, openvz, xen pv, lxc, cgroups/namespaces, and friends. I think linux (the kernel) already has the tools necessary to do task prioritization like the article requests.
Maybe.
I can design a shed and oversee or perform its construction. That does not make me an architect.
I can design and build a model car with a little spring-and-gear engine. That does not make me a mechanical engineer.
I can design and build a little circuit "piano" with pushbuttons and a 555 timer. That does not make me an electrical engineer.
I can lead a team to build proposals; reasonably accurately gauge task complexity; predict completion dates and manpower requirements; define deliverables and release criteria; control defect introduction through manual and automated unit and system tasting; build accurate development, maintenance, and operation documentation; and actually write, debug, and review efficient, best-practices-compliant code for custom software exceeding 100k LOC of new code or modifications per contract, not counting software packages integrated from other ISVs, capable of reliably processing millions of financial and medical transactions per day. Does that make me a software engineer?
Your cellphone is just a brick without software and firmware designed by thousands of developers with millions of hours of dev time, a significant portion of it in critical areas where flaws can result in physical damage, horrible performance or just plain crashing. Your car engine is controlled by a PCM driven by software, weighing in with probably multiple megabytes of code and lookup tables, designed to increase your fuel efficiency beyond what you could get with a mechanical system alone, where flaws will very likely cause serious mechanical and safety problems. The ridiculously convoluted system of wires, routers, switches, and servers that got this message from me to you is all dependent on software largely written by some team or other of developers in a controlled and systematic process and certainly not a million monkeys at random.
Software engineering is real. Many of them are even licensed as professional engineers now. Your conception of who they are, what they do, and their importance to your way of life appears to be flawed.
Of all the explanations given so far, AC is the only one that has hit the crux of the matter. I don't agree with his assessment of runtime/tooling as there is middleware which will enable porting with relative ease between platforms. But it's absolutely true that if the garden owner tosses you out, your options are few in number, especially as a small developer and they can do so for any reason they want. If the platform owner changes the way part of their platform works and it completely breaks your application (android 4.4.2 anyone?) you must quickly adapt or (get bad reviews and) die--hobbiests don't have time to drop everything and fix their app and if my understanding is correct, there is no expectation of long term (>2 yr) platform API stability (in specific example, push notifications on android).
Mobile devs are stuck with three evil giants who are conflicted on whether they want you to fill their garden with useful tools or toss you because you've stepped into their safety zone.
As far as development costs go, that is absolutely rock-bottom cheap. Indy mobile developers don't pay 1.5k+ USD for a development-only unit with in-system debugging capability. They don't pay 1k+ per year, per seat for the tool suite. They don't pay 10k+ for external auditing and verification for major releases. It costs nothing to load unsigned apks on android. It costs nothing to load a binary from Xcode onto a target iOS device. The only thing that costs money is development equipment, which is less than 600 USD each for all major mobile platforms, and distribution, the 100$/yr being discussed.
500 per year for an entire team is laughable if you produce one good app with 500 sales (or donations) per year at a dollar each. Get four friends with the same hobby as you. Buy your release licenses as a club. Hell, go to your mom with the app you wrote and have her play around with it. I bet if she likes it she'll just give you the 100 USD to buy an iOS distribution license.
The article would classify sandboxing as one of the many layers that the industry has added on instead of fixing the fundamental problem with software development culture that values minimizing time-to-market significantly over security.
Or maybe I'm putting words in their mouth.
Not to branch too far off topic here, but this sounds like a pretty ideal use-case for microkernels allowing developers to slowly squash features into the trusted memory spaces after they've proven themselves in untrusted memory spaces while still bringing new features in regularly. The security vs performance tradeoff seems pretty reasonable.
So small, there's no room for mounting holes, aside from the through-hole vias. Is that normal for COMs?
If you made a general-purpose pocket computer that has a LTE addon module (which you license as a single unit), how much of that royalty pool just melts away?
Even for domain experts, we're talking about hard problems; problems hard enough that we've only recently been able to apply them reliably in the field. This is definitely a nascent technology, and while I think it will be a societal net positive (decreased accident rate, increased fuel economy), there's still a lot of room to grow and improve. I know I personally won't be getting one until the cost is near parity with manual vehicles, whether that be through insurance incentives or vehicle time sharing; or I become a bit too old to drive myself around reliably.
Is it feasible to legally obligate all entities operating in the USA to abide by all safeguards and regulations required of HIPAA data if the data they have could be so classified?
Despite being in the running for the worst analogy ever, let's go with this.
You own the gun. Blizzard mails you bullets and invites you to their shooting range. You take the bullets and gun to the range and shoot them however you please as long as you follow the range rules. You bring sandbags and a bench to shoot straighter in competition without telling Blizzard. Blizzard sues the sandbag and bench makers because you cheated.
I only want the mod that disables reporting to external entities. Real safety features can stay in.
Mom uses skype to talk to her friends. Mom asks why I'm not on skype because she wants to talk to me. Thus I'm running skype again.
.PRECIOUS: theprecious %.gpg
.PHONY: hobbitses /root/pocket.tar {} +
But that's OK, she doesn't have my retroshare pgp pubkey. Nobody has the precious retroshare pgp pubkey. Trust no-one. My precious.
--
hobbitses:
find $(HOME) -name '*.gpg' -exec sudo tar --remove-files rf
Fortran is a Paper-Handled Plastic Shovel +4 of SCIENCE, forged in the early days when the world was young upon the ancient IBM 704. A keen observer might still find where John Backus himself scrawled "F*@# ASM!" in the crossword puzzle, its margins filled with arcane formulae from which the secrets of missile guidance emerged. It has fought and won many battles as an agent of the Holy Maths against the forces of nature, problems inscrutable, and libelous apocrypha. In its wake are the algorithms and research papers which lay the foundations of our modern tools, many of which are still used behind the scenes today. It is a thing of great purity, not tainted by the crude indelicacies of ui design or text processing; these tasks it leaves to other tools. Numbers go in, solutions come out, transformed by algorithms proven true over so many years.
Do not so lightly cast aside a tool which has proven its worth many times over.
Of the people I know who own high end timepieces, returning them to their holder at night where they rest consistently in nearly exactly the same spot is not a problem. It's just like handling jewelry; everything has its place.
To hyperbolically extend your argument, pretend you looking for an embedded systems kernel developer. Applicant A has worked on projects with hundreds of thousands of lines of PHP, so you should hire A because she can google it. Having direct knowledge is sometimes helpful.
Here is an archive link to the article as originally printed: http://archive.is/wbw97
The original paragraph was as parent quoted:
The idea that anybody can search databases of federal government-curated vital records for a specific profile to identify any given person without proof of relationship or a court order is more than a little horrifying.