Before Google Apps Engine had an edge with its free plans, but why would anyone seriously use it now when there are much more capable Amazon cloud and Microsoft Azure available?
What Google offers with App Engine (which still has the same distinction between free apps and apps with billing enabled as it has since billable features were first introduced) is not really directly competing with EC2, its more directly competing with services like Heroku that are built on top of EC2.
Compared to EC2, there's a lot lower barrier to use in terms of what you need to implement yourself (or get from somewhere other than the vendor).
The App Engine Python Runtime is one of the dead-simplest ways to get a cloud application up (Heroku with Ruby is roughly comparable in ease, there used to be a roughly comparable JavaScript-based option that has since shifted its focus and dropped the comparable service.)
For example, Azure integrates beautifully with Visual Studio, Eclipse and other development tools so that platform is just great to develop with.
Google has fairly extensive Eclipse tooling which supports Google technologies including, but not limited to, the App Engine Java runtime.
The Python and Go runtimes don't have specific IDE tooling, but IME Python, at least, doesn't need the tooling to start with.
Amazon on the other hand offers different services for different needs - you get the file hosting platform that scales extremely well, and then there's the traditional platform with databases, ability to run code and so on..
Google also provides a number of cloud services for different needs. Its a radically different set than what Amazon offers, so the needs each fulfill are quite different.
There's just nothing that Google Apps Engine offers
That's true, there is no such product as "Google Apps Engine". OTOH, the product "Google App Engine" offers a number of things (including integration with other Google cloud services.)
There are people who are reluctant to put effort into a project, which can be just taken by a company and put into a closed source product. And looking at the size of GNU/Linux world, compared to xBSD world, I'd say there are more of these people, than people who'd rather contribute to BSD licensed project.
Looking at Postgres (or, at least from its activity, SQLite) vs. any GPL-licensed RDBMS project, I'd say the reverse -- looser license are better at attracting effort.
OTOH, its more likely that the important distinctions on either the OS side or the RDBMS side aren't the licenses at all.
I personally have, and quite like, Designing Interfaces: Patterns for Effective Interactions Design, 2nd Edition (by Jenifer Tidwell, 2010, O'Reilly), which I think is very helpful for UI design.
Usability, of course, goes beyond just the design of the UI; the design of the actual workflow is important, for that good process analysis skills and tools (mostly not automated) are needed.
And for all aspects of usability, involving users early, getting them using the system early, and getting -- and using -- feedback is the most important thing.
It strikes me that during the first two centuries of this country's existence the people's representatives tried to guarantee and assure the people's liberty and for the last few decades they've been doing their best to undo all that fine work.
It strikes me that people tend to romanticize the past, but that if you really look into any of the history the factional struggles of the past (and the jaded pox-on-all-your-houses critics that charged all leaders with general ill-motive) in this country look remarkably similar to those today.
There is no evidence to support that the ratifiers of the 14th amendment desired it to affect the bill of rights.
Even if that were true, there's considerable evidence that the framers of the Constitution wanted ambiguities in the text to be resolved through the institutions created under the Constitution -- including, but not limited to, the federal judiciary -- in light of specific circumstances, rather than being limited to specific inquiry as to what the authors and ratifiers thought at the time of ratification.
But your claim isn't true; there's considerable evidence that providing guarantees againt State violations of some of the protections existing in the Bill of Rights was an integral part of the intent of the proposers and ratifiers of the 14th Amendment.
One argument made in the House of Representatives in favor of (and by the primary author of) what was adopted and proposed as the Privileges and Immunities Clause of the 14th Amendment was this:
Many instances of State injustice and oppression have already occurred in the State legislation of this Union, of flagrant violations of the guarantied privileges of citizens of the United States, for which the national Government furnished and could furnish by law no remedy whatever. Contrary to the express letter of your Constitution, "cruel and unusual punishments" have been inflicted under State laws within this Union upon citizens, not only for crimes committed, but for sacred duty done, for which and against which the Government of the United States had provided no remedy and could provide none.
That is, the specific problem that the Federal Constitution failed to protect against State violations of protections in the Bill of Rights like the protection against cruel and unusual punishments was part of the problem that the 14th Amendment, and specifically the Privileges and Immunities Clause, was directly designed to address.
(It's true that the case law of the 14th Amendment has drawn incorporation more from the Due Process Clause of the 14th Amendment, so certainly one can credibly argue, and many have, that the cases are technically wrong in drawing incorporation from this point, but its simply indefensible to claim that there is no evidence that incorporation was intended with the adoption of the 14th Amendment.)
Why not just bank with a better institution. I just read earlier today that BofA is going to institute a $5/month fee for the "privilege" of using your debit card (which of course is on top of the 3% fee they charge to the merchant).
At least some speculation in the media has been that some or all of BofA's system problems may be due to self-inflicted system load increase in the form of large number of online account inquiries and cancellations prompted by the debit card service fee.
The "tiny" part is key. Smaller countries are more homogeneous (even if there are dozens of dialects of the same language), and being surrounded by countries speaking those other languages, there's political and economic advantages to speaking them all.
Canada is officially bilingual English-French, but only one province is and it isn't Quebec.
Quebec is French-only and there is a lot of resentment over many federal jobs with a bilingual requirement even when the job itself doesn't need it. The feeling is exacerbated by Quebec not reciprocating the effort by neighbouring provinces to use bilingual signs even in key areas, e.g. for road and construction detour signs.
OTOH, India, which is the world's largest democracy and second largest country, with a population a little less than twice that of Europe as w hole, has two official languages at the national level (but explicitly not national languages), and its states and territories can define their own official and recognized languages and have designated (in total) many more.
There would still be a million different languages. As much as some might want to ignore that, it's a massive barrier to very close European union. Until there is a 'European' language, it aint gonna happen.
India at least suggests that the barrier you point to isn't as insurmountable as all that, though it is a big issue.
If that were the case people in Italy administering or writing on the English version of Wikipedia would be faced with the same problem...
In theory, though people who have recourse to the Italian legal system in the first place are probably more likely to target Italian-language Wikipedia first and foremost. The risk extends beyond that particular site, but it is greatest there.
I suggest the best thing to do if this law comes in, go to one of the governments own web sites, find something that mentions two people, and get them to edit war over it continuously as fast as they can, until this law is repealed, or the Government pays them the fines... win-win..
I suspect that, as is the case with most laws of this type in every jurisdiction, the government is either explicitly immune from the text of the law, or immune as a result of a pre-existing categorical immunity to the type of law that it is.
While it's true that INTEGER in Oracle is treated as NUMBER(38), from a programming standpoint (and DDL standpoint) INTEGER is what one would use. Incidentally, NUMBER(38) doesn't mean that Oracle is allocating storage for 38 digits.
No, but it does mean that it is possible for values that won't fit in a 32-bit integer to be stored in that value, which means that the database type doesn't match the intent, and you can't rely on the database enforcement of its type system to keep values compatible with the application using a 32-bit integer, so you need some additional checking somewhere to keep things safe (assuming that there are other ways than the application at issue to interact with the database.)
Procedural programming is easier for humans to understand: most of us do no not think in a way that maps easily to functional programming.
I think procedural programming is easier for humans who have spent prior time studying procedural and/or imperative programming to understand. I'm not convinced its any easier to understand starting from scratch, though.
Re:haskell for the masses? sure, but only...
on
OCaml For the Masses
·
· Score: 1
Remember Pascal? You had "procedure" and "function", both of which map to functions in C. The idea was in Pascal to use "function" for computations which doesn't change state, and use "procedure" for things that alter state.
Do you have a reference for this? As far as I've ever heard, the idea was to use "function" for computations which return a value and "procedure" for computations which don't return a value (equivalent to void functions in C), and the distinction wasn't intended to have anything to do with side effects. (Obviously, a procedure would only be useful if it had side effects, while a function could be useful without them, but that wasn't a side effect of the returns-a-value distinction, not the primary intended distinction.)
But the compiler doesn't actually enforced that statelessness for "function", it trusted you, and handled both the practically the same way.
No, functions and procedures were treated differently by Pascal compilers. Procedure calls, since they did not return a value, could not be used where a value was expected, and function calls, which did return a value, could only be used where a value (specifically, an rvalue) was expected.
Exactly! Encrypting tape backups is required by HIPAA anymore.
No, its not. Under the HIPAA Security Rule, Encryption and Decryption is an "addressable" rather than a "required" specification of the Access Control standard mandated under HIPAA (see, 45 CFR Sec. 164.312(a).)
So, in fact, entities holding PHI are required to either implement encryption or document why it isn't "reasonable and appropriate" for them to do so. (see 45 CFR Sec. 164.306(d)(3).)
Encrypting data, whether at rest or in motion,is necessary for the data to be considered "secured", but there is no general prohibition on holding or transmitting unsecured PHI. However, there are all kinds of rules regarding notification and other actions that have to happen in the event that anyone who isn't supposed to have access to particular PHI gets, or might have, their hands on unsecured PHI, so the policy of most institutions that hold PHI is to make sure that it is secured both in rest and in motion.
My "unless the contract with your hosting provider is due for renewal very soon" referred to migration, your #3: transition costs become more bearable near the end of the contract.
Right, but its not impossible, as you presented it originally, its an option with costs (just like choosing a less-suitable backed database is an option with costs), which have to be weighed against its benefits.
I think that it's absolutely stupid that Verizon had to wait until the rules went into effect before they could sue over them.
Verizon has already sued over them, and the rules go into effect on November 20, so its obvious that Verizon did not have to wait until the rules went into effect before they could sue.
What they had to do was wait until the rules were published in the Federal Register which is the thing that makes them an official rule.
Just think for a moment how much cost and trouble these rules will cause if they're overturned months, or years, after they went into effect when all of this could have been avoided by testing them in court first.
That's a valid concern, which is why the law requires regulations like this to be published in the Federal Register for a certain length of time before they go into effect, and courts have the power when a challenge is made, if certain criteria are met, to prevent the regulation from going into effect until the challenge is resolved.
Yes, they could. Similarly, a shopkeeper could look at you're clothes and tell you "that'll be an extra $5, Mr Fancy Pants". Do you think that would be smart business practice? Maybe somewhere in a backstreet in Hong Kong.
Actually, segmenting your market by ability to pay is, assuming you can find a way to do it that works tolerably well, a pretty effective way of maximizing income, and is used by basically every vendor that can find a way to do it, not just in the backstreets of Hong Kong.
One of the problems in avoiding the blocking that has been practiced by both fixed and mobile internet providers in the past is that neither has announced what they were blocking, making it unnecessarily difficult for consumers to make purchasing decisions informed by accurate facts. So, I'm going to say lots of people probably care about being able to get accurate information on the services actually provided.
Further, requiring accurate reports of what is being blocked, as long as requiring providers to publicize their justification, makes it a lot easier for public entities like the FCC to weigh future restrictions on blocking as the market for mobile internet provisions becomes more mature.
I don't even understand why they're blocking it...honestly.
As noted in GGP, the Open Internet Report and Order adopted by the FCC will require mobile broadband providers to identify why they are blocking it.
From a network management stand point, why would you block IRC?
Who said that they are blocking it for network management purposes?
That's fine if you know you'll be installing a particular web application on your hosting plan from day one. But if you're adding an application to an existing hosting plan, you have to use what you have unless the contract with your hosting provider is due for renewal very soon.
No, if you are adding an application to an existing hosting plan, you have to use what you have by definition, regardless of contract terms (because if you switch plans, then you aren't adding the application to the existing hosting plan.)
If you are adding an application to a business with has an existing shared hosting plan, which is more likely the right way to consider things, then you have several options, including: 1. Use something that works with the existing plan, 2. Host the new application separately from the existing applications, 3. Migrate the existing services to a new host which will also host the old one.
None of these are absolutely constrained by the existing contract, though #3 might have additional one-time transition costs due to the provisions of the contract.
Except there are still a lot of shared web hosts that don't offer PostgreSQL; they offer only Oracle MySQL.
While its true that there are lots of shared hosting providers that don't offer PostgreSQL, there are also lots that do offer PostgreSQL. So if you want PostgreSQL you have options.
Can Verizon still block my access to getting on IRC networks without me having to mess around with a bunch of different servers?
Insofar as IRC is neither a website nor a competing voice or video application, Verizon (when acting as a mobile broadband provider; they also provide fixed services) could block it, though under the transparency rules they would have to disclose details about how and what they were blocking that would take much of the guesswork out of dealing with the blocking.
If someone is trying to tell me I can use AIM, GTalk, MSN, and Yahoo but not log onto IRC, I'd LOVE to hear why.
The transparency rules require them to identify both what they are blocking and why, among other things.
For instance, there's nothing keeping them from saying "streaming video via our paid app doesn't count towards your tiny data caps". This is in fact reasonable for them since it means that they don't need to increase their upstream connections.
Given the rule in paragraph 66 of the Report and Order which equates rendering content unusable with blocking it, establishing very low caps in general or specific to competing voice or video service which acted to render competing voice and video services unusable in practice and then exempting the providers own voice and video services from those caps would seem to fit squarely in the definition of "blocking". And, while you assert that it is "in fact reasonable" for them, it does not appear to be clearly within the scope of "reasonable network management" as defined in the Report and Order (it isn't unquestionably outside of it, either, the definition is explicitly designed to be refined through case-by-case analysis.)
It kind of sucks for the end user though since if everyone in a given area does it the effect is chilling.
Which, given the principles established in the Report and Order, would seem to be a factor weighing against the validity of the practice if it were to be adopted and subsequently challenged under the Order.
Microsoft will NEVER detail what patents that they believe Linux infringes on. Folks have been begging them to do so for years
Begging is the wrong approach.
If some company with a monetary interest in Linux, Android, or anything else that MS has threatened wants to get MS to reveal the patents that it believes are violated, what they need to do is: 1. Ask MS to identify the patents it holds that it believes are violated by the vendor's product so that vendor can review the product and remove any components that violate the patents identified, 2. If MS declines to do so, file suit for trade defamation; the public statements and the harm prongs are fairly easily satisfied, and the failure to respond should be sufficient evidence to raise a legitimate controversy of fact on the falsity clause.
Slashdot Mirror
What Google offers with App Engine (which still has the same distinction between free apps and apps with billing enabled as it has since billable features were first introduced) is not really directly competing with EC2, its more directly competing with services like Heroku that are built on top of EC2.
Compared to EC2, there's a lot lower barrier to use in terms of what you need to implement yourself (or get from somewhere other than the vendor).
The App Engine Python Runtime is one of the dead-simplest ways to get a cloud application up (Heroku with Ruby is roughly comparable in ease, there used to be a roughly comparable JavaScript-based option that has since shifted its focus and dropped the comparable service.)
Google has fairly extensive Eclipse tooling which supports Google technologies including, but not limited to, the App Engine Java runtime.
The Python and Go runtimes don't have specific IDE tooling, but IME Python, at least, doesn't need the tooling to start with.
Google also provides a number of cloud services for different needs. Its a radically different set than what Amazon offers, so the needs each fulfill are quite different.
That's true, there is no such product as "Google Apps Engine". OTOH, the product "Google App Engine" offers a number of things (including integration with other Google cloud services.)
Looking at Postgres (or, at least from its activity, SQLite) vs. any GPL-licensed RDBMS project, I'd say the reverse -- looser license are better at attracting effort.
OTOH, its more likely that the important distinctions on either the OS side or the RDBMS side aren't the licenses at all.
I personally have, and quite like, Designing Interfaces: Patterns for Effective Interactions Design, 2nd Edition (by Jenifer Tidwell, 2010, O'Reilly), which I think is very helpful for UI design.
Usability, of course, goes beyond just the design of the UI; the design of the actual workflow is important, for that good process analysis skills and tools (mostly not automated) are needed.
And for all aspects of usability, involving users early, getting them using the system early, and getting -- and using -- feedback is the most important thing.
It strikes me that people tend to romanticize the past, but that if you really look into any of the history the factional struggles of the past (and the jaded pox-on-all-your-houses critics that charged all leaders with general ill-motive) in this country look remarkably similar to those today.
Even if that were true, there's considerable evidence that the framers of the Constitution wanted ambiguities in the text to be resolved through the institutions created under the Constitution -- including, but not limited to, the federal judiciary -- in light of specific circumstances, rather than being limited to specific inquiry as to what the authors and ratifiers thought at the time of ratification.
But your claim isn't true; there's considerable evidence that providing guarantees againt State violations of some of the protections existing in the Bill of Rights was an integral part of the intent of the proposers and ratifiers of the 14th Amendment.
One argument made in the House of Representatives in favor of (and by the primary author of) what was adopted and proposed as the Privileges and Immunities Clause of the 14th Amendment was this:
That is, the specific problem that the Federal Constitution failed to protect against State violations of protections in the Bill of Rights like the protection against cruel and unusual punishments was part of the problem that the 14th Amendment, and specifically the Privileges and Immunities Clause, was directly designed to address.
(It's true that the case law of the 14th Amendment has drawn incorporation more from the Due Process Clause of the 14th Amendment, so certainly one can credibly argue, and many have, that the cases are technically wrong in drawing incorporation from this point, but its simply indefensible to claim that there is no evidence that incorporation was intended with the adoption of the 14th Amendment.)
At least some speculation in the media has been that some or all of BofA's system problems may be due to self-inflicted system load increase in the form of large number of online account inquiries and cancellations prompted by the debit card service fee.
OTOH, India, which is the world's largest democracy and second largest country, with a population a little less than twice that of Europe as w hole, has two official languages at the national level (but explicitly not national languages), and its states and territories can define their own official and recognized languages and have designated (in total) many more.
India at least suggests that the barrier you point to isn't as insurmountable as all that, though it is a big issue.
In theory, though people who have recourse to the Italian legal system in the first place are probably more likely to target Italian-language Wikipedia first and foremost. The risk extends beyond that particular site, but it is greatest there.
I suspect that, as is the case with most laws of this type in every jurisdiction, the government is either explicitly immune from the text of the law, or immune as a result of a pre-existing categorical immunity to the type of law that it is.
No, but it does mean that it is possible for values that won't fit in a 32-bit integer to be stored in that value, which means that the database type doesn't match the intent, and you can't rely on the database enforcement of its type system to keep values compatible with the application using a 32-bit integer, so you need some additional checking somewhere to keep things safe (assuming that there are other ways than the application at issue to interact with the database.)
You'd think so, but no; "INTEGER", "INT", and "SMALLINT" all are, in Oracle, converted to NUMBER(38).
In Postgres, though, "INTEGER" will get you a 32-bit signed integer.
I think procedural programming is easier for humans who have spent prior time studying procedural and/or imperative programming to understand. I'm not convinced its any easier to understand starting from scratch, though.
Do you have a reference for this? As far as I've ever heard, the idea was to use "function" for computations which return a value and "procedure" for computations which don't return a value (equivalent to void functions in C), and the distinction wasn't intended to have anything to do with side effects. (Obviously, a procedure would only be useful if it had side effects, while a function could be useful without them, but that wasn't a side effect of the returns-a-value distinction, not the primary intended distinction.)
No, functions and procedures were treated differently by Pascal compilers. Procedure calls, since they did not return a value, could not be used where a value was expected, and function calls, which did return a value, could only be used where a value (specifically, an rvalue) was expected.
No, its not. Under the HIPAA Security Rule, Encryption and Decryption is an "addressable" rather than a "required" specification of the Access Control standard mandated under HIPAA (see, 45 CFR Sec. 164.312(a).)
So, in fact, entities holding PHI are required to either implement encryption or document why it isn't "reasonable and appropriate" for them to do so. (see 45 CFR Sec. 164.306(d)(3).)
Encrypting data, whether at rest or in motion,is necessary for the data to be considered "secured", but there is no general prohibition on holding or transmitting unsecured PHI. However, there are all kinds of rules regarding notification and other actions that have to happen in the event that anyone who isn't supposed to have access to particular PHI gets, or might have, their hands on unsecured PHI, so the policy of most institutions that hold PHI is to make sure that it is secured both in rest and in motion.
Just out of curiosity, did you mean "one of my by wife's cousins" or "one my wives' cousins"?
Right, but its not impossible, as you presented it originally, its an option with costs (just like choosing a less-suitable backed database is an option with costs), which have to be weighed against its benefits.
Verizon has already sued over them, and the rules go into effect on November 20, so its obvious that Verizon did not have to wait until the rules went into effect before they could sue.
What they had to do was wait until the rules were published in the Federal Register which is the thing that makes them an official rule.
That's a valid concern, which is why the law requires regulations like this to be published in the Federal Register for a certain length of time before they go into effect, and courts have the power when a challenge is made, if certain criteria are met, to prevent the regulation from going into effect until the challenge is resolved.
Actually, segmenting your market by ability to pay is, assuming you can find a way to do it that works tolerably well, a pretty effective way of maximizing income, and is used by basically every vendor that can find a way to do it, not just in the backstreets of Hong Kong.
One of the problems in avoiding the blocking that has been practiced by both fixed and mobile internet providers in the past is that neither has announced what they were blocking, making it unnecessarily difficult for consumers to make purchasing decisions informed by accurate facts. So, I'm going to say lots of people probably care about being able to get accurate information on the services actually provided.
Further, requiring accurate reports of what is being blocked, as long as requiring providers to publicize their justification, makes it a lot easier for public entities like the FCC to weigh future restrictions on blocking as the market for mobile internet provisions becomes more mature.
As noted in GGP, the Open Internet Report and Order adopted by the FCC will require mobile broadband providers to identify why they are blocking it.
Who said that they are blocking it for network management purposes?
No, if you are adding an application to an existing hosting plan, you have to use what you have by definition, regardless of contract terms (because if you switch plans, then you aren't adding the application to the existing hosting plan.)
If you are adding an application to a business with has an existing shared hosting plan, which is more likely the right way to consider things, then you have several options, including:
1. Use something that works with the existing plan,
2. Host the new application separately from the existing applications,
3. Migrate the existing services to a new host which will also host the old one.
None of these are absolutely constrained by the existing contract, though #3 might have additional one-time transition costs due to the provisions of the contract.
While its true that there are lots of shared hosting providers that don't offer PostgreSQL, there are also lots that do offer PostgreSQL. So if you want PostgreSQL you have options.
Insofar as IRC is neither a website nor a competing voice or video application, Verizon (when acting as a mobile broadband provider; they also provide fixed services) could block it, though under the transparency rules they would have to disclose details about how and what they were blocking that would take much of the guesswork out of dealing with the blocking.
The transparency rules require them to identify both what they are blocking and why, among other things.
Given the rule in paragraph 66 of the Report and Order which equates rendering content unusable with blocking it, establishing very low caps in general or specific to competing voice or video service which acted to render competing voice and video services unusable in practice and then exempting the providers own voice and video services from those caps would seem to fit squarely in the definition of "blocking". And, while you assert that it is "in fact reasonable" for them, it does not appear to be clearly within the scope of "reasonable network management" as defined in the Report and Order (it isn't unquestionably outside of it, either, the definition is explicitly designed to be refined through case-by-case analysis.)
Which, given the principles established in the Report and Order, would seem to be a factor weighing against the validity of the practice if it were to be adopted and subsequently challenged under the Order.
Begging is the wrong approach.
If some company with a monetary interest in Linux, Android, or anything else that MS has threatened wants to get MS to reveal the patents that it believes are violated, what they need to do is:
1. Ask MS to identify the patents it holds that it believes are violated by the vendor's product so that vendor can review the product and remove any components that violate the patents identified,
2. If MS declines to do so, file suit for trade defamation; the public statements and the harm prongs are fairly easily satisfied, and the failure to respond should be sufficient evidence to raise a legitimate controversy of fact on the falsity clause.