It is just the customization and vendor disinterest that prevents updates. It is as if Dell, Lenovo, HP, etc added their crapware so deeply into the Windows infrasture that Microsoft's security updates could not be applied and the vendors were not interested in creating or distributing adapted versions.
On the contrary, it is vendor interest that prevents updates.
The first thing to know is that Google does not create Android releases. Google does continuous Android development, and any time after release N.M, but before N.(M+1), or (N+1).0, for new major releases, the code base is called after the current tree version number. When a vendor wants to release a new Android cell phone, there may be parts of the code base they've contributed back for specific chip and peripheral support, but what they do is take a cut of the code base and freeze it. Then they apply patches and finishing touches which don't get integrated back to the main Android code base as part of taking it from the raw, unproductized Android code base to a productized version which can be shipped to customers.
The dirty little secret here is that all productization is done by the device vendors, and not by Google, and that Google itself is basically incapable of productizing an operating system like Android. Instead, they rely on the device vendor to do this, and the device vendor, wanting product differentiation, willingly cooperates, or even insists, on this happening outside of Google.
What that means is that "Android version 4.1" is a meaningless way to compare Android devices with one another, since Samsung's version of 4.1 may not have identical bits with Sony's version of 4.1, since they were most likely cut from different development versions of the source tree, even if they were cut only hours apart.
The bottom line here is that, even with a working security fix back-ported to "Android 4.1" is most likely going to result in a product reintegration, since the patch(es) will have to be rolled forward from the Google release branch of 4.1 (which has no additional changes past the Google release date) to the vendor's version of 4.1, which is a set of patches and productization on top of some code branch somewhere between Google's 4.1 and their 4.2. This is nearly as much effort as developing a new "model 720" phone with COGS-reduced parts, and based on the original "model 710" phone from that same vendor. The team which works on this "improved Android 4.1 for the 710" is a set of people who isn't working on the "model 730". As far as a vendor is concerned, that's spending good money to update a product for previous customers who aren't paying them money for the new improved version of the product, because "the old version is good enough".
The second thing to know is that the carrier marketing model in the U.S. effectively discourages the carrier from updating the OS, even if the handset/tablet manufacturer were willing to integrate the bug fix and provide an update.
In the U.S., a carrier locks you into a 2 year contract, and then offers you a 6 month "early update" to lock you into that carrier again for another two years after 18 months. The upshot of this is that they get to keep the captive user as a subscriber, in trade for a new handset, which is subsidized by the carrier, and the old handset has been fully paid for (and then some) by the monthly bill portion which pays for the "free" handsets in the first place.
The net effect of this is that, if they update an old phone, unless they have a new phone with some compelling new feature(s), the customer is more likely to "ride out" the remaining six months on their contract, and then just switch carriers. The only real compelling features that differentiate one Android phone from another these days are the version of Android they are running. Sometimes there are minor changes in hardware, but frankly, there's usually no hardware change that's compelling enough to get someone to NOT
I have seen it go the other way, and it's a much easier transition. Examples include Android and OS X, where the code is only Open Sourced after release, since the license does not require development to occur in the open, it only requires the code be handed over on release, and then only if it's requested, in most cases. Other examples include WINE, which begat Crossover Office, which has proprietary chunks, and MySQL, which has proprietary back ends available, if you want actual transactions instead of pretend ones.
If you GPL the entire product, someone will start nightly builds outside your organization; this happens today with both Android and ChromeOS, and there's no way you can control this to the point of preventing it, at least without going to a secureboot option, and keeping the binary signing keeys internal to your organization.
Given the above, there is almost not a chance in hell of you getting as much income from an Open Source model as you will get from a closed source model, unless your closed source version isn't really in demand anyway, or unless you intentionally leave features out of the Open Source version, as has happened with both WINE and MySQL.
The best you can hope for is to Open Source the tactical portions of your product in a way that's (A) useful enough to third parties that they are willing to commit some development resources to maintaining the code, and (B) that it's still useless enough that you don't end up with some zealot coming up with a fully Open Source version of the product you are attempting to sell based on its strategic values (something BitKeeper failed to do successfully).
There have been several posts over the past couple of days complaining about not being able to use derivative works of proprietary (copyrighted) data files for things like Windows registry/crapware cleaners, etc., all of which are complaining about the inability to lock down the strategic value (or, contrarily, complaining about companies attempting to lock down their strategic value).
In general, the Open Source model is not a good match for vertical markets. E.g. if I owned a moving company, there'd be no way I'd want a competing moving company getting out from under their moving software license fees (which are onerous) because of software that I funded development on in order to get myself out from under those same fees -- the entire application has strategic competitive value for my company.
The Open Source model is also not a good model for projects where the strategic value is in the glue code between Open Source modules -- as stated previously, this allows someone to compete by stringing the parts together using their own business logic, at a very low cost, and my margins are completely dependent on barriers to entry for third parties. To go back to the moving company example, with heavy fluctuations in consumables, like truck fuel, my company is already at a heavy disadvantage compared to large companies, since it's a cash flow business for smaller companies, and the larger companies can make capitol investments in long term fuel pricing contracts, which can get them steep discounts.
I have also seen the "Give away the software, well service/support" model blow up on people; perhaps the most spectacular example of that would be Cygnus Software, which has become a shell housing something totally different than compiler development.
My general sense of things is that if you are a programmer, there are companies who will pay you to work on Open Source; Google is a good example, since they have more money than God from advertising revenue, and are willing to spend it on buying street cred/prestiege by hiring prominent Open Source people. If you want to found a company on it, you are going to be hard put to make it pay off.
Part of the problem is that the 1st class mail is being used to subsidize bulk mail and as a result as 1st class mail gets sent less and less the subsidy has become insufficient to cover the cost.
Ooops, you got that backwards. Bulk Mail prices subsidize first class delivery. But other than that, yes I agree that the prices on bulk mail should go up.
I'm going to doubt that they "make it up in volume"; for one thing, bulk mail is pre-sorted and bar-coded, and so has a lot less humans and sorting equipment involved in its delivery. Bulk rates can be as low as 3.1 cents per piece, which is less than 1/10th the cost of first class mail. Raise the bulk rate by half a cent per piece, and you've solved the "losing money" problem completely.
[...]then in Sept 1997 Games Workshop filed for "SPACE MARINE" again (SN 75010236), which covered video computer games; computer software for playing games.
So, they don't even own a trademark on the term for any books at all.
The problem here being that what was taken down was an eBook, which is considered to be software, which is why they are permitted to licene the things, rather than you being able to own them outright, since you have purchased a physical artifact. For the same reasons, first use law doesn't apply, and therefore you can be prohibited from resale of eBooks.
This crap is out of hand, and in sore need of some reform; After 400 years, we are back to book licenses; we came up with copyright in the first place to stop this crap.
What you are asking for is a computer vision system. Typically there are parts, but no complete Open Source implementation of what you want, unless you are willing to assemble them yourself, and accept somewhat less than commercial quality.
Movid is the part you want for human tracking; typically these systems are going to require parallax cameras, meaning binocular vision, for some of the recognition.
It's arguable that winapp2.ini is a derivative work of winapp.ini, given that they go out of their way to indicate that the format is derived. If so, then they have a legal leg from a copyright perspective, although it's not a strong one, given that it's aggregate data.
They also have a patent filed and assigned to the company by the CEO, although 20120290530 wasn't published until 2012-11-15, which means that the use of the file predates the patent by some years.
What other legitimate uses does a gun have besides killing someone or something? Why would you buy a gun if not for that?
As a deterrent against criminal activities, and a deterrent against government oppression.
If I lived in Waco, Texas, I'd probably own one in case Janet Reno or one of her replacements sent an M1-Abrams Main Battle Tank against civilian children. Again.
People who were not born in U.S. often fail to realize that the U.S. is separate from the British empire in large part due to private ownership of weapons by a populace which was willing to use them to overthrow an oppressive government. Some people in the U.S. are either poorly enough educated on the U.S. Revolutionary War that they don't understand the need, or they feel that the time has past where individuals provide their own security, and instead rely on the continued benevolence of their government.
There are a large number of places in the world where Police services are being outsourced to private security firms; this is happening a lot in the UK, with G4S and similar private security firms running the Lincolnshire Police starting with a contract in Feb 2012. SAPS (the South African Police Service) is also largely outsourced to private security firms. This has been happening in the U.S. in Atlanta, Detroit, and Philadelphia, among other locales, since mid 2012. Millbrae, Pacifica, Oakland, and Milpitas have all at least partially outsourced police services, and that's in the San Francisco Bay Area alone. San Bernardino has been negotiating similar steps since Nov 2012.
Personally, I do not trust private security firms such as Academi (the former Blackwater) to run my local police services. They are mercenaries, and they can, and have been, bought, and there is no indication that, once bought, they will stay bought.
Until this type of practice ends, I'm actually glad that there are weapons comparable to those used by and/or available to these private security organizations remaining in private hands. I trust my neighbors more than I trust some third party. I have a big enough problem already with police officers in the Bay Area being prohibited from living in the towns and cities where they serve, since it means they people they enforce against are not member of their community. God help us if they persons are from halfway across the country.
NetronCowboy is right. You cannot read the militia part as being superfluous; it must mean something.
It does. It's clearly called out in the Militia Acts of 1792, 1795, 1862, and 1903: Everyone who can get their hands on weapons. Just as in the American Revolutionary War agains the British, "arms" was interpreted to mean "any weapon", and included the finest cannons of the time, which were the most destructive weapons of the time, as well as warships and privateers, all privately owned, and generally better than those weapons owned by the governments of the time.
Justice Scalia in DC v. Heller laid out the current interpretation of the 2nd Amendment. He explicitly states that although gun ownership does not have to be related to militia service the feds can infringe on rights in accordance with ensuring a well-regulated militia. He said that 1) denying the right to felons is constitutional, 2) denying the right to the mentally ill is constitutional,
These both are restrictions of liberty falling under the due process clause of the 5th amendment.
and 3) an assault weapon ban is constitutional.
This, however, does not, unless we are talking about convicted felons here. The second amendment acknowledges an inalienable right, it does not grant said right.
That's just off the top of my head. Anyway, the founders embued the power of constituional interpretation on the Supreme Court (Marbury v. Madison; Federalist Paper 78) and so it's word goes. You are not the arbiter of constitutionality. It is. And it says those are OK. Go back to Con Law 101.
Actually, the Federalist papers were mere rhetoric, and do not have force of law, any more than the statements in the Declaration of Independence have force of law, or we'd have a state religion demanding a creator who endows men with inalienable rights.
Actually, even plants don't do it efficiently enough to replace the stored energy in oil, gas and coal. At least, they couldn't replace it without horrendous ecological consequences. We can't "grow, baby, grow" our way out of our energy trap any more than we can "drill, baby, drill." We either go nuclear and hope for at least adequate battery technology, or we forget about industrial scale civilization and starve and die on a massive scale come 2100 or thereabouts.
Uranium: The other fossil fuel Plutonium: The other renewable energy Breeder reactors: The other recycling program Central United States: The other location safe from tsunami
I didn't come out of a CS program, and I don't think I misunderstand the halting problem. I simply didn't add "or are shaders not turing complete?" What sort of trade offs are there in disallowing shaders that are too complex to prove that they halt?
Trade off A: Allow them to run, and have your graphics stack crash in user space or have it crash the kernel in Mac OS X because the graphics stack appears unresponsive to the keep-alive requests which are periodically sent by the system watchdogs to verify that the graphics stack is prepared to handle more work items to permit the applications to make forward progress.
Trade off B: Don't allow the shader to run; you lose some effect from the shader, but your system remains stable and your application makes forward progress, as intended. Since this is the default for Windows, your game looks more like a Windows game than it would have otherwise.
when you hear old Jazz musicians talk about New York, they frequently reminisce about the day they got their Union card.
You know that the reason you got your union card was so you could play clubs, right? It wasn't so you could play your song once in a studio, and then kick back and collect a monthly royalty check for the rest of your life.
With Spotify, you can hear the same song over and over without buying it. And you don't have to listen to the rest of the album.
It's the same with broadcast radio, only you don't get to pick the song. Broadcast radio plays what Clearchannel has been bribed to play because that's what they want in the top 40. They want specific songs in the top 40 because they come from bands which, while mediocre, are capable of churning out nearly identical songs periodically to keep the pipeline full.
The big problem with OpenGL is that the shaders are not guaranteed to run in bounded time. DirectX doesn't have that problem, and the OpenGL emulation layer on top of DirectX unrolls the shaders, and for the ones which won't run in bounded time, just throws them away.
When Chrome implements OpenGL on Windows, it runs it through its own code which does the same thing and preflights it, then renders the OpenGL which will run linearly and in bounded time via DirectX.
The Linux and Mac OS X versions hand the OpenGL to the user space renderer or to the kernel-based renderer, respectively -- there are significant performance advantages to OpenGL on Mac OS X compared to Linux because of this; this ends up being most apparent on portable devices, which have a limited memory copy bandwidth (read: ARM devices), which is why Android doesn't directly use the Linux graphics model, apart from the inability to use binary drivers in kernel space due to EXPORT_SYMBOL_GPL().
But both the Linux and Mac OS X OpenGL renderers take the shaders without preflighting them, as is done on Windows when converting to DirectX calls, and so it's possible to crash the user space driver on Linux, or crash the Mac OS X kernel, on Mac OS (the disadvantage you get in exchange for the reduced copy overhead relative to Linux).
I tried unsuccessfully for several months to try and convince the Chrome graphics guys to run the preflight portion of the Direct X converter on Linux and Mac OS to prevent these crashes on these platforms, to no avail. It'd be more processing, but no more than is already done on Windows, in exchange for a significant improvement in stability for OpenGL/OpenGL ES/WebGL/NaCl on both platforms, which is probably worth the additional processing cost, given that the bottleneck is copying, not processing, on the portable platforms. There are cycles to burn on the desktop systems, even if you'd prefer not to burn them, it's probably worth it for the stability.
In any case, a lot of game developers try for a lot of effects with shaders, and most of them are more concerned with the visual appeal, rather than in running in bounded time and not eventually crashing the system. DirectX protects them where OpenGL doesn't -- except on the Windows platforms they use for development, and that doesn't help get these games stable and running on Mac OS X or Linux, which is what you'd hoe the portability of OpenGL code would have bought you.
U.S. Universities have stopped being about education, and are now about profit. Nothing else explains turning away students who want to pay for their education, and then complaining about having so few students demanding a course that they must cancel it, and it "happens" to result in stretching a 4 year degree into a 5 year one, adding 25% tuition and fees per student who is allowed to attend.
Obama bemoaning the foreign students getting their education in the U.S. and taking their knowledge elsewhere is missing the point: Admissions are preferential towards those students who pay the most, and it tiers as: (1) International, (2) Out of State, (3) local. There have been numerous investigative articles about this fact: http://www.schools.com/articles/are-finances-a-factor-in-college-admissions.html
Some universities go so far as to spell it out explicitly; here's what Vanderbilt has to say:
The degree stretching activity speaks most loudly to the fact that tuition is a minor factor in the financial gains a university makes per student; there are also fees, but they would be the same as a first year student in their first year vs. a fifth year student in their fifth; instead, the incentives to the university to continue educating a given student go up with the amount of time the student has already attended.
What would be interesting to see is if there is a stretching bias toward "high value" students; in particular, whether stretching happens uniformly across the board, or whether you are most likely to get stretched if you are an international student, and least likely to get stretched if you were an in-state student.
In any case, the fix for what Obama is complaining about isn't to keep the international graduates in the U.S. after graduation, it's fixing the admissions bias towards international students for economic rather than academic reasons, and fix the stretching for economic reasons, which can often make it uneconomical for some locals to attend at all, or cause them to drop out before graduating. If a university exists to educate students first and make profits second, then it will end up making decisions which are in the best interests of the students.
Ignoring your anger issues, They have given *cheap* *open* *hackable* devices, to build platform independent computer *science* skills, which can only be considered wonderful. If they had given out [locked] Chromebooks [or Google Docs] to lock children into their ecosystem, I'd be looking at this the same as the whole Discounted *cough* Apple/Microsoft products for schools we have seen for years, like crack.
There's a switch in all Chromebooks to unlock them. There's a boot warning screen when booting unlocked devices, and a delay while the things actually unlock on first boot after the switch is flipped, but after that, they are fully unlocked. You'll get the boot warning screen each time, but you can hit a key to get around that, or just wait the 30 seconds - either way: the thing's fully unlocked.
One of the OS's that can run on a Raspberry Pi is ChromeOS, sans the hardware key escrow, since a TPM would have made the things non-exportable to 5 countries who restrict their citizens from using strong cryptography (Russia, China, Uzbekistan, etc.).
Which mens that there are no additional import/export issues, if they are sold and distributed in the UK.
If you are in some other location in the world, design your own damn board, or just manufacture the Raspberry Pi boards locally from the UK circuit diagrams and get your local equivalent of UL and FCC certifications, and money might materialize for your local schools as well... or not. This happened in the UK because some UK Googlers were excited enough about it to push up their management chain. You;d also need to get Googlers in your country interested to the same degree, or find some other company you can convince to fund it.
The USB problem is not intrinsic to the chip, it's intrinsic to the board design with a loopback on the power rail. Because of this it wasn't possible to do high speed USB because you couldn't raise the voltage out of the PMU with the other rail effectively holding it to the lower voltage.
You can ECN it yourself, if you have a microscope soldering station and know how to manually solder BGA devices, or you can just damn well by the new revision of the board instead, it's not like they cost that much. I know this because I ECN'ed mine with a microscope soldering station.
Either way, this has been discussed in pretty deep detail in the Raspberry Pi forums, along with the fact that weren't going to change the board design during the production run where the board problem was first root-caused.
"I think this is in error. Perl is less maintainable than other languages, due to the myriad of "correct" was to implement solutions to various problems"
I know myriads of correct wa[y]s to implement solutions in any of the dozen languages I know. Are you saying you know only one?
(this complaint about Perl has never failed to puzzle me)
Here are the attributes of a language which are the most important in a commercial environment:
o Long term maintainability o Ease of debugging o Ability to replace one programmer with another when the first one is hit by a bus o Ability to replace one programmer with another halfway through a project when the first's skills are strongly needed elsewhere o Rapidity of development
Perl is only a win on the last one. This has its place in business:
o Creation of throw-away scripts which will be used once to bootstrap o Creation of very small scripts for data crunching/analysis; small is eventually understandable o Creation of prototypes for the purposes of obtaining initial funding (I'd argue Perl is not the best choice here, but it's viable)
The commonality of all these things is that they are effective when you need a "Mr. Right Now"; when you need a "Mr. Right", then they lose their value. In the interesting case, which is the last one (the other two cases can be handled in any language by any code monkey, and can be thrown away and rewritten id the current implementation is too dense), that's good enough for angel funding. But if you are going for first round funding, there are other things which the investors are going to value more, and that goes back to the first list:
o If six months in the main prima donna throws a hissy fit and leaves, will it be possible to continue? o If six months in, we have to replace parts of the team because they are not product focussed, will it be possible to continue? o If the plane crashes on the way to a trade show taking 3 people with it, will it be possible to continue? o If it's necessary to liquidate the startups assets in order to recoup investment, will there be any value in them to others? o If we need to scale rapidly without incurring huge hardware/rack rental/power expense, can we switch to a compiled language? o If we need to bring in a lot of new coders to achieve scale, while they be able to communicate effectively?
For Perl code, the general answer to these questions is almost uniformly "no", unless you have an extraordinarily disciplined Perl programmer in the first place - in which case, you'd probably be using a more disciplined language. The answer to the last one, even if an extraordinarily disciplined programmer were able to answer "yes" to the other items, has to be a qualified "no", unless you have a readily available (read: not willing to pay above average market rate) talent pool from which to obtain more extraordinarily disciplines Perl programmers.
Perl programmers rarely work in teams; when they do, it's almost unheard of them to work in teams on the same code base -- instead, they interface between chunks of code using system interfaces, rather than perl interfaces.
It's OK to find joy in side effects, and it's OK to find joy in being able to go years without having to invoke system(3) using the same syntax/coding pattern, but in doing do, realize you are only finding joy for yourself, not your employer.
Like I said originally: as long as CPAN is healthy, it's a good canary for Perl; I don't think the language is going away. But I still disagree with the OP as to why the metrics indicate that it's falling into disuse: it has nothing to due with the rapidity of releases or the rapidity of churn in language features, and everything to do with other intrinsic factors which are not as controllable as those.
Speeding and trespassing are interesting issues. Certainly, the government itself is prohibited from either of these acts:
The right of the people to be secure in their persons, houses, papers, and effects, against unreasonable searches and seizures, shall not be violated, and no Warrants shall issue, but upon probable cause, supported by Oath or affirmation, and particularly describing the place to be searched, and the persons or things to be seized.
Speeding, if an accident is involved, has to do with being secure in your person; trespass has to do with being secure in your house, regardless of the incident. But "shall not be violated is a regulation on the action of the government, rather than on one individual against another.
In the case of individuals, it falls to the law of the State, rather than Federal law, to deal with the issue at question, which for most states means code influenced, but not dictated, by English common law.
And yeah, this makes me a strict constitutional constructivist.
As more time goes by, Perl will likely continue to decline in popularity and cement its growing status as a somewhat arcane and archaic language, especially as compared to newer, more lithe options.
It's not failing because it's not changing, it's failing because less people are using it. The lack of it integrating shiny new features may be one of the factors contributing to this.
I agree that that's what the article author is saying; he specifically cites release timeliness and "forward progress", which he goes on to define as additional features.
I think this is in error. Perl is less maintainable than other languages, due to the myriad of "correct" was to implement solutions to various problems, and once the challenger language in question has evolved to the point that it can map a sufficient portion of the problem space mappable by perl, it was inevitable that it be displaced. As the article author states, it's not going anywhere, but, like COBOL, you aren't going to be seeing significant new code bases written in the language.
Python, I think, owes its popularity in no small part to being an official language in places like Facebook and Google; perl is specifically prohibited in all cases in both companies. If one language is used by a company where it's desirable to work, and another is prohibited, which language are you going to learn?
PS: I think the best place to look for perl's health, or lack thereof, is the coverage for systems interface changes in CPAN. If perl get coverage for significant new APIs, but not other APIs, then it's still alive; otherwise, it's on its way to legacy code and/or deprecation. For example, if there's support for membuf, ioevent, and similar interfaces, I'd say perl was far from dead.
There isn't a material known to exist in significant quantities in asteroids (let alone easily accessible to mining) that could possibly repay the cost of getting at it - even if access costs were a tenth of what they are.
If only there were a Socialist State which was also a space-going nation and didn't give a flying crap about cost... they'd be able to do it, wouldn't they?
That is an excellent reply to the posters question wrapped in a snarky response.
Sorry; I've seen too many threads where someone asks for something in Linux and gets a "patches welcome" response, I guess, and so I made the same comment myself with regard to hardware.
Slashdot Mirror
It is just the customization and vendor disinterest that prevents updates. It is as if Dell, Lenovo, HP, etc added their crapware so deeply into the Windows infrasture that Microsoft's security updates could not be applied and the vendors were not interested in creating or distributing adapted versions.
On the contrary, it is vendor interest that prevents updates.
The first thing to know is that Google does not create Android releases. Google does continuous Android development, and any time after release N.M, but before N.(M+1), or (N+1).0, for new major releases, the code base is called after the current tree version number. When a vendor wants to release a new Android cell phone, there may be parts of the code base they've contributed back for specific chip and peripheral support, but what they do is take a cut of the code base and freeze it. Then they apply patches and finishing touches which don't get integrated back to the main Android code base as part of taking it from the raw, unproductized Android code base to a productized version which can be shipped to customers.
The dirty little secret here is that all productization is done by the device vendors, and not by Google, and that Google itself is basically incapable of productizing an operating system like Android. Instead, they rely on the device vendor to do this, and the device vendor, wanting product differentiation, willingly cooperates, or even insists, on this happening outside of Google.
What that means is that "Android version 4.1" is a meaningless way to compare Android devices with one another, since Samsung's version of 4.1 may not have identical bits with Sony's version of 4.1, since they were most likely cut from different development versions of the source tree, even if they were cut only hours apart.
The bottom line here is that, even with a working security fix back-ported to "Android 4.1" is most likely going to result in a product reintegration, since the patch(es) will have to be rolled forward from the Google release branch of 4.1 (which has no additional changes past the Google release date) to the vendor's version of 4.1, which is a set of patches and productization on top of some code branch somewhere between Google's 4.1 and their 4.2. This is nearly as much effort as developing a new "model 720" phone with COGS-reduced parts, and based on the original "model 710" phone from that same vendor. The team which works on this "improved Android 4.1 for the 710" is a set of people who isn't working on the "model 730". As far as a vendor is concerned, that's spending good money to update a product for previous customers who aren't paying them money for the new improved version of the product, because "the old version is good enough".
The second thing to know is that the carrier marketing model in the U.S. effectively discourages the carrier from updating the OS, even if the handset/tablet manufacturer were willing to integrate the bug fix and provide an update.
In the U.S., a carrier locks you into a 2 year contract, and then offers you a 6 month "early update" to lock you into that carrier again for another two years after 18 months. The upshot of this is that they get to keep the captive user as a subscriber, in trade for a new handset, which is subsidized by the carrier, and the old handset has been fully paid for (and then some) by the monthly bill portion which pays for the "free" handsets in the first place.
The net effect of this is that, if they update an old phone, unless they have a new phone with some compelling new feature(s), the customer is more likely to "ride out" the remaining six months on their contract, and then just switch carriers. The only real compelling features that differentiate one Android phone from another these days are the version of Android they are running. Sometimes there are minor changes in hardware, but frankly, there's usually no hardware change that's compelling enough to get someone to NOT
I have seen it go the other way, and it's a much easier transition. Examples include Android and OS X, where the code is only Open Sourced after release, since the license does not require development to occur in the open, it only requires the code be handed over on release, and then only if it's requested, in most cases. Other examples include WINE, which begat Crossover Office, which has proprietary chunks, and MySQL, which has proprietary back ends available, if you want actual transactions instead of pretend ones.
If you GPL the entire product, someone will start nightly builds outside your organization; this happens today with both Android and ChromeOS, and there's no way you can control this to the point of preventing it, at least without going to a secureboot option, and keeping the binary signing keeys internal to your organization.
Given the above, there is almost not a chance in hell of you getting as much income from an Open Source model as you will get from a closed source model, unless your closed source version isn't really in demand anyway, or unless you intentionally leave features out of the Open Source version, as has happened with both WINE and MySQL.
The best you can hope for is to Open Source the tactical portions of your product in a way that's (A) useful enough to third parties that they are willing to commit some development resources to maintaining the code, and (B) that it's still useless enough that you don't end up with some zealot coming up with a fully Open Source version of the product you are attempting to sell based on its strategic values (something BitKeeper failed to do successfully).
There have been several posts over the past couple of days complaining about not being able to use derivative works of proprietary (copyrighted) data files for things like Windows registry/crapware cleaners, etc., all of which are complaining about the inability to lock down the strategic value (or, contrarily, complaining about companies attempting to lock down their strategic value).
In general, the Open Source model is not a good match for vertical markets. E.g. if I owned a moving company, there'd be no way I'd want a competing moving company getting out from under their moving software license fees (which are onerous) because of software that I funded development on in order to get myself out from under those same fees -- the entire application has strategic competitive value for my company.
The Open Source model is also not a good model for projects where the strategic value is in the glue code between Open Source modules -- as stated previously, this allows someone to compete by stringing the parts together using their own business logic, at a very low cost, and my margins are completely dependent on barriers to entry for third parties. To go back to the moving company example, with heavy fluctuations in consumables, like truck fuel, my company is already at a heavy disadvantage compared to large companies, since it's a cash flow business for smaller companies, and the larger companies can make capitol investments in long term fuel pricing contracts, which can get them steep discounts.
I have also seen the "Give away the software, well service/support" model blow up on people; perhaps the most spectacular example of that would be Cygnus Software, which has become a shell housing something totally different than compiler development.
My general sense of things is that if you are a programmer, there are companies who will pay you to work on Open Source; Google is a good example, since they have more money than God from advertising revenue, and are willing to spend it on buying street cred/prestiege by hiring prominent Open Source people. If you want to found a company on it, you are going to be hard put to make it pay off.
Part of the problem is that the 1st class mail is being used to subsidize bulk mail and as a result as 1st class mail gets sent less and less the subsidy has become insufficient to cover the cost.
Ooops, you got that backwards. Bulk Mail prices subsidize first class delivery. But other than that, yes I agree that the prices on bulk mail should go up.
I'm going to doubt that they "make it up in volume"; for one thing, bulk mail is pre-sorted and bar-coded, and so has a lot less humans and sorting equipment involved in its delivery. Bulk rates can be as low as 3.1 cents per piece, which is less than 1/10th the cost of first class mail. Raise the bulk rate by half a cent per piece, and you've solved the "losing money" problem completely.
[...]then in Sept 1997 Games Workshop filed for "SPACE MARINE" again (SN 75010236), which covered video computer games; computer software for playing games.
So, they don't even own a trademark on the term for any books at all.
The problem here being that what was taken down was an eBook, which is considered to be software, which is why they are permitted to licene the things, rather than you being able to own them outright, since you have purchased a physical artifact. For the same reasons, first use law doesn't apply, and therefore you can be prohibited from resale of eBooks.
This crap is out of hand, and in sore need of some reform; After 400 years, we are back to book licenses; we came up with copyright in the first place to stop this crap.
What you are asking for is a computer vision system. Typically there are parts, but no complete Open Source implementation of what you want, unless you are willing to assemble them yourself, and accept somewhat less than commercial quality.
Here's the most comprehensive resource: http://www.roborealm.com/links/vision_software.php
Movid is the part you want for human tracking; typically these systems are going to require parallax cameras, meaning binocular vision, for some of the recognition.
It's arguable that winapp2.ini is a derivative work of winapp.ini, given that they go out of their way to indicate that the format is derived. If so, then they have a legal leg from a copyright perspective, although it's not a strong one, given that it's aggregate data.
They also have a patent filed and assigned to the company by the CEO, although 20120290530 wasn't published until 2012-11-15, which means that the use of the file predates the patent by some years.
What other legitimate uses does a gun have besides killing someone or something? Why would you buy a gun if not for that?
As a deterrent against criminal activities, and a deterrent against government oppression.
If I lived in Waco, Texas, I'd probably own one in case Janet Reno or one of her replacements sent an M1-Abrams Main Battle Tank against civilian children. Again.
People who were not born in U.S. often fail to realize that the U.S. is separate from the British empire in large part due to private ownership of weapons by a populace which was willing to use them to overthrow an oppressive government. Some people in the U.S. are either poorly enough educated on the U.S. Revolutionary War that they don't understand the need, or they feel that the time has past where individuals provide their own security, and instead rely on the continued benevolence of their government.
There are a large number of places in the world where Police services are being outsourced to private security firms; this is happening a lot in the UK, with G4S and similar private security firms running the Lincolnshire Police starting with a contract in Feb 2012. SAPS (the South African Police Service) is also largely outsourced to private security firms. This has been happening in the U.S. in Atlanta, Detroit, and Philadelphia, among other locales, since mid 2012. Millbrae, Pacifica, Oakland, and Milpitas have all at least partially outsourced police services, and that's in the San Francisco Bay Area alone. San Bernardino has been negotiating similar steps since Nov 2012.
Personally, I do not trust private security firms such as Academi (the former Blackwater) to run my local police services. They are mercenaries, and they can, and have been, bought, and there is no indication that, once bought, they will stay bought.
Until this type of practice ends, I'm actually glad that there are weapons comparable to those used by and/or available to these private security organizations remaining in private hands. I trust my neighbors more than I trust some third party. I have a big enough problem already with police officers in the Bay Area being prohibited from living in the towns and cities where they serve, since it means they people they enforce against are not member of their community. God help us if they persons are from halfway across the country.
NetronCowboy is right. You cannot read the militia part as being superfluous; it must mean something.
It does. It's clearly called out in the Militia Acts of 1792, 1795, 1862, and 1903: Everyone who can get their hands on weapons. Just as in the American Revolutionary War agains the British, "arms" was interpreted to mean "any weapon", and included the finest cannons of the time, which were the most destructive weapons of the time, as well as warships and privateers, all privately owned, and generally better than those weapons owned by the governments of the time.
Justice Scalia in DC v. Heller laid out the current interpretation of the 2nd Amendment. He explicitly states that although gun ownership does not have to be related to militia service the feds can infringe on rights in accordance with ensuring a well-regulated militia. He said that 1) denying the right to felons is constitutional, 2) denying the right to the mentally ill is constitutional,
These both are restrictions of liberty falling under the due process clause of the 5th amendment.
and 3) an assault weapon ban is constitutional.
This, however, does not, unless we are talking about convicted felons here. The second amendment acknowledges an inalienable right, it does not grant said right.
That's just off the top of my head. Anyway, the founders embued the power of constituional interpretation on the Supreme Court (Marbury v. Madison; Federalist Paper 78) and so it's word goes. You are not the arbiter of constitutionality. It is. And it says those are OK. Go back to Con Law 101.
Actually, the Federalist papers were mere rhetoric, and do not have force of law, any more than the statements in the Declaration of Independence have force of law, or we'd have a state religion demanding a creator who endows men with inalienable rights.
Actually, even plants don't do it efficiently enough to replace the stored energy in oil, gas and coal. At least, they couldn't replace it without horrendous ecological consequences. We can't "grow, baby, grow" our way out of our energy trap any more than we can "drill, baby, drill." We either go nuclear and hope for at least adequate battery technology, or we forget about industrial scale civilization and starve and die on a massive scale come 2100 or thereabouts.
Uranium: The other fossil fuel
Plutonium: The other renewable energy
Breeder reactors: The other recycling program
Central United States: The other location safe from tsunami
I didn't come out of a CS program, and I don't think I misunderstand the halting problem. I simply didn't add "or are shaders not turing complete?" What sort of trade offs are there in disallowing shaders that are too complex to prove that they halt?
Trade off A: Allow them to run, and have your graphics stack crash in user space or have it crash the kernel in Mac OS X because the graphics stack appears unresponsive to the keep-alive requests which are periodically sent by the system watchdogs to verify that the graphics stack is prepared to handle more work items to permit the applications to make forward progress.
Trade off B: Don't allow the shader to run; you lose some effect from the shader, but your system remains stable and your application makes forward progress, as intended. Since this is the default for Windows, your game looks more like a Windows game than it would have otherwise.
when you hear old Jazz musicians talk about New York, they frequently reminisce about the day they got their Union card.
You know that the reason you got your union card was so you could play clubs, right? It wasn't so you could play your song once in a studio, and then kick back and collect a monthly royalty check for the rest of your life.
With Spotify, you can hear the same song over and over without buying it. And you don't have to listen to the rest of the album.
It's the same with broadcast radio, only you don't get to pick the song. Broadcast radio plays what Clearchannel has been bribed to play because that's what they want in the top 40. They want specific songs in the top 40 because they come from bands which, while mediocre, are capable of churning out nearly identical songs periodically to keep the pipeline full.
The big problem with OpenGL is that the shaders are not guaranteed to run in bounded time. DirectX doesn't have that problem, and the OpenGL emulation layer on top of DirectX unrolls the shaders, and for the ones which won't run in bounded time, just throws them away.
When Chrome implements OpenGL on Windows, it runs it through its own code which does the same thing and preflights it, then renders the OpenGL which will run linearly and in bounded time via DirectX.
The Linux and Mac OS X versions hand the OpenGL to the user space renderer or to the kernel-based renderer, respectively -- there are significant performance advantages to OpenGL on Mac OS X compared to Linux because of this; this ends up being most apparent on portable devices, which have a limited memory copy bandwidth (read: ARM devices), which is why Android doesn't directly use the Linux graphics model, apart from the inability to use binary drivers in kernel space due to EXPORT_SYMBOL_GPL().
But both the Linux and Mac OS X OpenGL renderers take the shaders without preflighting them, as is done on Windows when converting to DirectX calls, and so it's possible to crash the user space driver on Linux, or crash the Mac OS X kernel, on Mac OS (the disadvantage you get in exchange for the reduced copy overhead relative to Linux).
I tried unsuccessfully for several months to try and convince the Chrome graphics guys to run the preflight portion of the Direct X converter on Linux and Mac OS to prevent these crashes on these platforms, to no avail. It'd be more processing, but no more than is already done on Windows, in exchange for a significant improvement in stability for OpenGL/OpenGL ES/WebGL/NaCl on both platforms, which is probably worth the additional processing cost, given that the bottleneck is copying, not processing, on the portable platforms. There are cycles to burn on the desktop systems, even if you'd prefer not to burn them, it's probably worth it for the stability.
In any case, a lot of game developers try for a lot of effects with shaders, and most of them are more concerned with the visual appeal, rather than in running in bounded time and not eventually crashing the system. DirectX protects them where OpenGL doesn't -- except on the Windows platforms they use for development, and that doesn't help get these games stable and running on Mac OS X or Linux, which is what you'd hoe the portability of OpenGL code would have bought you.
The students are there due to preferential policy
U.S. Universities have stopped being about education, and are now about profit. Nothing else explains turning away students who want to pay for their education, and then complaining about having so few students demanding a course that they must cancel it, and it "happens" to result in stretching a 4 year degree into a 5 year one, adding 25% tuition and fees per student who is allowed to attend.
Obama bemoaning the foreign students getting their education in the U.S. and taking their knowledge elsewhere is missing the point: Admissions are preferential towards those students who pay the most, and it tiers as: (1) International, (2) Out of State, (3) local. There have been numerous investigative articles about this fact: http://www.schools.com/articles/are-finances-a-factor-in-college-admissions.html
Some universities go so far as to spell it out explicitly; here's what Vanderbilt has to say:
"Those international students who demonstrate they can afford the cost of attending Vanderbilt will be given preferential treatment in the admission process."
Source: http://www.vanderbilt.edu/financialaid/undergraduate/international.php
The degree stretching activity speaks most loudly to the fact that tuition is a minor factor in the financial gains a university makes per student; there are also fees, but they would be the same as a first year student in their first year vs. a fifth year student in their fifth; instead, the incentives to the university to continue educating a given student go up with the amount of time the student has already attended.
What would be interesting to see is if there is a stretching bias toward "high value" students; in particular, whether stretching happens uniformly across the board, or whether you are most likely to get stretched if you are an international student, and least likely to get stretched if you were an in-state student.
In any case, the fix for what Obama is complaining about isn't to keep the international graduates in the U.S. after graduation, it's fixing the admissions bias towards international students for economic rather than academic reasons, and fix the stretching for economic reasons, which can often make it uneconomical for some locals to attend at all, or cause them to drop out before graduating. If a university exists to educate students first and make profits second, then it will end up making decisions which are in the best interests of the students.
Ignoring your anger issues, They have given *cheap* *open* *hackable* devices, to build platform independent computer *science* skills, which can only be considered wonderful. If they had given out [locked] Chromebooks [or Google Docs] to lock children into their ecosystem, I'd be looking at this the same as the whole Discounted *cough* Apple/Microsoft products for schools we have seen for years, like crack.
There's a switch in all Chromebooks to unlock them. There's a boot warning screen when booting unlocked devices, and a delay while the things actually unlock on first boot after the switch is flipped, but after that, they are fully unlocked. You'll get the boot warning screen each time, but you can hit a key to get around that, or just wait the 30 seconds - either way: the thing's fully unlocked.
One of the OS's that can run on a Raspberry Pi is ChromeOS, sans the hardware key escrow, since a TPM would have made the things non-exportable to 5 countries who restrict their citizens from using strong cryptography (Russia, China, Uzbekistan, etc.).
Which mens that there are no additional import/export issues, if they are sold and distributed in the UK.
If you are in some other location in the world, design your own damn board, or just manufacture the Raspberry Pi boards locally from the UK circuit diagrams and get your local equivalent of UL and FCC certifications, and money might materialize for your local schools as well ... or not. This happened in the UK because some UK Googlers were excited enough about it to push up their management chain. You;d also need to get Googlers in your country interested to the same degree, or find some other company you can convince to fund it.
The USB problem is not intrinsic to the chip, it's intrinsic to the board design with a loopback on the power rail. Because of this it wasn't possible to do high speed USB because you couldn't raise the voltage out of the PMU with the other rail effectively holding it to the lower voltage.
You can ECN it yourself, if you have a microscope soldering station and know how to manually solder BGA devices, or you can just damn well by the new revision of the board instead, it's not like they cost that much. I know this because I ECN'ed mine with a microscope soldering station.
Either way, this has been discussed in pretty deep detail in the Raspberry Pi forums, along with the fact that weren't going to change the board design during the production run where the board problem was first root-caused.
We could have bought 35 cluster bombs at $13,941 each, if this weren't being wasted on education this way.
Honestly, this was initiated by a group at Google UK, and had nothing to do with taxes.
"I think this is in error. Perl is less maintainable than other languages, due to the myriad of "correct" was to implement solutions to various problems"
I know myriads of correct wa[y]s to implement solutions in any of the dozen languages I know. Are you saying you know only one?
(this complaint about Perl has never failed to puzzle me)
Here are the attributes of a language which are the most important in a commercial environment:
o Long term maintainability
o Ease of debugging
o Ability to replace one programmer with another when the first one is hit by a bus
o Ability to replace one programmer with another halfway through a project when the first's skills are strongly needed elsewhere
o Rapidity of development
Perl is only a win on the last one. This has its place in business:
o Creation of throw-away scripts which will be used once to bootstrap
o Creation of very small scripts for data crunching/analysis; small is eventually understandable
o Creation of prototypes for the purposes of obtaining initial funding (I'd argue Perl is not the best choice here, but it's viable)
The commonality of all these things is that they are effective when you need a "Mr. Right Now"; when you need a "Mr. Right", then they lose their value. In the interesting case, which is the last one (the other two cases can be handled in any language by any code monkey, and can be thrown away and rewritten id the current implementation is too dense), that's good enough for angel funding. But if you are going for first round funding, there are other things which the investors are going to value more, and that goes back to the first list:
o If six months in the main prima donna throws a hissy fit and leaves, will it be possible to continue?
o If six months in, we have to replace parts of the team because they are not product focussed, will it be possible to continue?
o If the plane crashes on the way to a trade show taking 3 people with it, will it be possible to continue?
o If it's necessary to liquidate the startups assets in order to recoup investment, will there be any value in them to others?
o If we need to scale rapidly without incurring huge hardware/rack rental/power expense, can we switch to a compiled language?
o If we need to bring in a lot of new coders to achieve scale, while they be able to communicate effectively?
For Perl code, the general answer to these questions is almost uniformly "no", unless you have an extraordinarily disciplined Perl programmer in the first place - in which case, you'd probably be using a more disciplined language. The answer to the last one, even if an extraordinarily disciplined programmer were able to answer "yes" to the other items, has to be a qualified "no", unless you have a readily available (read: not willing to pay above average market rate) talent pool from which to obtain more extraordinarily disciplines Perl programmers.
Perl programmers rarely work in teams; when they do, it's almost unheard of them to work in teams on the same code base -- instead, they interface between chunks of code using system interfaces, rather than perl interfaces.
It's OK to find joy in side effects, and it's OK to find joy in being able to go years without having to invoke system(3) using the same syntax/coding pattern, but in doing do, realize you are only finding joy for yourself, not your employer.
Like I said originally: as long as CPAN is healthy, it's a good canary for Perl; I don't think the language is going away. But I still disagree with the OP as to why the metrics indicate that it's falling into disuse: it has nothing to due with the rapidity of releases or the rapidity of churn in language features, and everything to do with other intrinsic factors which are not as controllable as those.
Official languages are:
- C/C++, considered one language
- Python
- JavaScript
- Go, or whatever the internally developed flavor of the month is
If you are going to try to target your skills, stick to the first three.
Speeding and trespassing are interesting issues. Certainly, the government itself is prohibited from either of these acts:
The right of the people to be secure in their persons, houses, papers, and effects, against unreasonable searches and seizures, shall not be violated, and no Warrants shall issue, but upon probable cause, supported by Oath or affirmation, and particularly describing the place to be searched, and the persons or things to be seized.
Speeding, if an accident is involved, has to do with being secure in your person; trespass has to do with being secure in your house, regardless of the incident. But "shall not be violated is a regulation on the action of the government, rather than on one individual against another.
In the case of individuals, it falls to the law of the State, rather than Federal law, to deal with the issue at question, which for most states means code influenced, but not dictated, by English common law.
And yeah, this makes me a strict constitutional constructivist.
As more time goes by, Perl will likely continue to decline in popularity and cement its growing status as a somewhat arcane and archaic language, especially as compared to newer, more lithe options.
It's not failing because it's not changing, it's failing because less people are using it. The lack of it integrating shiny new features may be one of the factors contributing to this.
I agree that that's what the article author is saying; he specifically cites release timeliness and "forward progress", which he goes on to define as additional features.
I think this is in error. Perl is less maintainable than other languages, due to the myriad of "correct" was to implement solutions to various problems, and once the challenger language in question has evolved to the point that it can map a sufficient portion of the problem space mappable by perl, it was inevitable that it be displaced. As the article author states, it's not going anywhere, but, like COBOL, you aren't going to be seeing significant new code bases written in the language.
Python, I think, owes its popularity in no small part to being an official language in places like Facebook and Google; perl is specifically prohibited in all cases in both companies. If one language is used by a company where it's desirable to work, and another is prohibited, which language are you going to learn?
PS: I think the best place to look for perl's health, or lack thereof, is the coverage for systems interface changes in CPAN. If perl get coverage for significant new APIs, but not other APIs, then it's still alive; otherwise, it's on its way to legacy code and/or deprecation. For example, if there's support for membuf, ioevent, and similar interfaces, I'd say perl was far from dead.
"Can you please recommend some new apps for me to trojan that won't be pulled as quickly? KTHX."
There isn't a material known to exist in significant quantities in asteroids (let alone easily accessible to mining) that could possibly repay the cost of getting at it - even if access costs were a tenth of what they are.
If only there were a Socialist State which was also a space-going nation and didn't give a flying crap about cost... they'd be able to do it, wouldn't they?
That is an excellent reply to the posters question wrapped in a snarky response.
Sorry; I've seen too many threads where someone asks for something in Linux and gets a "patches welcome" response, I guess, and so I made the same comment myself with regard to hardware.