I tend to agree (as one who started in '99), but another trend has been the type of articles presented. I seem to remember when there were more DIY articles and articles related to science, both complex and basic.
I think the change is best summed up in the fact that there used to be a front-page link to a section called "developers", and now that's gone and there is a link to a section called "cloud".
Yes, and losing some features along the way right? I believe push email will no longer work on gmail for iOS, but please do correct me if I am wrong.
I've heard that the iOS Mail app doesn't support IMAP push, so push email from Gmail to the stock iPhone mail app won't work for new devices (the announcement stated that what is discontinued is the ability for users to add new devices for Google Sync, existing devices will continue to work.)
The existing Gmail app on iOS isn't affected, either, since it isn't limited by the lack of features of the iOS mail app.
Except it's not a legal pastime. Passing state laws to "legalize" something that is still illegal under federal law is counterproductive.
It may not be a complete solution, but it certainly deals with one of the major problems with having state laws against something that you don't actually want to be banned: specifically, the expenditure of state taxpayer funds in policing, prosecuting, and incarcerating people for doing something that you don't actually want to be prohibited.
So, incomplete solution I can see. Counterproductive? I don't see that.
Much better is to send representatives to Washington who will change the federal laws.
Repealing the state laws against something and electing federal representatives who will work to do so with the federal laws in the same area are not mutually exclusive approaches. In fact, state law changes often are an important part of the way that political pressure gets created to change federal law.
California officials have no desire to confront their fiscal problems.
Uh, well, except that they just presented a plan to voters that pretty much completely solves the fiscal problems for the foreseeable future, and the voters passed it.
They would rather add to them by doing things such as building high-speed rail to nowhere
The termini of the proposed high speed rail systems are the most populous areas of the state (and the project also includes upgrades for existing conventional intercity and commuter rail systems.) Its hardly "to nowhere".
and a football stadium in LA for a team they don't have using money they don't have.
State officials aren't building a stadium in LA, and the people that have expressed interest in doing that aren't building anything until a team agrees to come, so this one is doubly wrong.
Cities are going bankrupt in California and they just had to raise taxes to help met a budget shortfall. Shouldn't the State of California focus on solving its internal problems managing money
Cities are separate governments from the State, and, as you note, the State already largely addressed its budget shortfall, because in a surprising outbreak of common sense, voters voted to raise taxes to pay for the services they've demanded. There's still a small projected deficit under current policy for the next fiscal year, and then projected surpluses for the foreseeable future.
Or, the Mann Act if you transported the virgin child from another state (although I think Mann only applies to transport for immoral purposes)?
Under any reasonable standard "to throw the child into a volcano" is an immoral purpose.
So, while I think you are correct about the limitation, I don't think it makes the Mann Act inapplicable.
Maybe that's what you were thinking about.. the only active volcanoes in the US are in Hawaii, and in Volcanoes National Park
Say I have a user called "WebClient" for my DB back-end. I can give that user execute permissions on specific stored procedures and allow access only to the schema of "web".
I can do exactly the same thing using views in place of stored procs.
The web server does not have access to anything except to execute sprocs. This means if that user is compromised, the most they can do is call sprocs that hopefully have some basic business logic.
I can do exactly the same thing with views in place of stored procs for the exposed access; in fact, I can -- transparently to any interfacing application -- use stored procs to implement any of the the operations on the views where the imperative functionality provided by stored procs is beneficial, while letting the rest be handled by SQL which the DMBS's optimizer can optimize.
Letting a user have direct access to entire views/tables allows for a compromised user account to dump entire tables.
Obviously, letting a user have direct SELECT access to base tables allows them to dump the contents of the entire table. Equally obviously, allowing them to have similar access to a view doesn't allow them to do that unless the view is defined by something like SELECT * FROM base_table. But, if you are worried about preventing that kind of dumping, you won't define a view available to the user that way.
You can go so far as to have the sprocs accept a token as a parameter, which the token maps to a given user account. The sprocs can enforce basic user permissions this way. Unless the the hacker has access to read/write to the token table, it will be very hard for them to get any data out of the system.
This bit of extra work is theoretically useful, I suppose, in that it could protect against the situation where the application's database user account is compromised, but neither the database superuser account nor the application itself (or the OS account it is running under) is compromised (if the application is compromised as well, it can simply collect valid user credentials to use); sane database security practices (e.g., not allowing the applications database user to logon with a simple username/password logon from arbitrary IP addresses) make it impractical to compromise the database user account of the application without, as a prequisite, compromising the application or its OS account or the database superuser account, so its less work to just use the database correctly.
You can build your input sanitization directly into the stored procedure
The stored proc in the example doesn't get called until the query dynamically built from the input is parsed and evaluated, so the stored proc is exactly as vulnerable to SQL injection as the SELECT query. Which is true in the general case. SQL injection isn't a result of using select queries over using stored procs, its a result of using dynamically generated SQL using untrusted (or improperly-trusted) input.
Using prepared parameterized queries avoids SQL injection, using stored procs, in and of itself, does not. (Certainly, most database interface libraries except very-low-level ones hide parameterization behind a function that also encapsulates generating the SQL for a stored proc calls, but that's also the case for most libraries when it comes to SELECT queries. The SQL injection problem comes into play when application developers don't use these functions -- either parameterizing themselves with a low-level library or using a higher-level library correctly -- and insist on generating their own SQL dynamically.)
And MySQL still lacks a lot of features that PostgreSQL has had for years (including SQL standard features like CTEs), many of which (CTEs included) are (at least, IMO) more generally useful than automatically updateable views.
Google makes money from iOS because they're the default search engine. Not because of Android.
Actually, it makes money from iOS largely because of AdMob, but the need to compete with other platforms is why Apple doesn't capture more than it already does of the revenue generated by any vector through iOS, including mobile advertising and search.
This is a nice feature for standardization (and thus, compatibility and portability with other SQL systems) but it's also important to know that PostgreSQL also has a "rules" system that allows for much more complicated view/table relationships.
This is better than rules (or triggers), where it works not only because it is standard (which triggers are, as well), but also because it doesn't require explict definition of the actions.
this is a general failure of the evolved SQL semantics.
Some of it certainly is; in a perfect relational system, the boundaries on automatically updatable views would be broader and include any view where every possible row in the view had a 1:1 relationship with a possible row in each of the tables the view was based on (which is the same as saying that the view includes a candidate key for every base table.)
But even in an ideal system there are plenty of conceivable views which don't have a natural insert/update interpretation, and if you wanted to make them "updatable", you'd need to define for your system what that even means.
The "all application code should go through stored procedures" is recommended because you parametrize all user input
"You parameterize all user input" doesn't require use of stored procedures, or even views, it just requires not dynamically creating SQL by string concatenation/interpolation, and instead using the functions available in every database interface library that allow you to parameterize queries.
Obviously, not using user input it to dynamically create SQL is a fundamentally essential security practice for most applications (there are some exceptions, such as if you are trying to build something equivalent to a web-based SQL console), but it has nothing to do with using stored procedures. In fact, its quite possible to use stored procs (which can, after all, be called directly from SQL) using dynamically-generated SQL and make all the same mistakes that are possible with doing the same thing with regular DML queries against views or tables. Sure, your database library make provide a method to call a stored proc that automatically parameterizes arguments rather than forcing you to dynamically generated SQL -- but it also almost certainly has the same thing for regular queries.
There may have been a time when this wasn't true of some popular database libraries, which may have also contributed to the popularity of the "use stored procs for everything" approach, but if there was such a time, it wasn't recently.
Why would you want to wrap every table in your database in boilerplate?
Other than in the case of a single-application database (and, even then, only in fairly simple cases), using views rather than base tables for application isn't wrapping the tables in boilerplate.
All application code is going to be going through stored procedures anyway
The "all application code should go through stored procedures" rule is, as I understand it, a pragmatic rule that was recommended largely because most actual database systems at the time that rule became popular had view support that fell far enough short of the ideal in the relational model that the better and older "all application code should run against views" approach was generally impractical (helped by the fact that it let you have application programmers that didn't understand anything about relational databases.)
But nevertheless quite interesting. The idea of updatable views is certainly a good one, but it seems that the current limitations make this feature more or less useless for now
Its not really so much a matter of "current limitations". You can go beyond it a little bit, maybe, but there is a limit not far from the current documented limits beyond which you lose logical clarity as to the semantics of what an update to a view means, so updatable views either need explicit definition (which you can already do) or end up with automatic-but-not-obvious behavior.
I'd rather lose UPDATEable views and finally get materialized views
There is quite a bit work going on on an initial implementation of matviews targetted for 9.3; losing updatable views wouldn't be likely to help you get matviews any sooner.
Do any slashdotters know of a situation where an update-able view would be handy/ideal?
Every case where you are using a relational database with an application, since ideally every application should have its own set of views that form the application's interface to the database rather than using base tables. Having simple views (which usually will be fairly common if you are doing this) automatically updatable lowers the barriers to doing it.
If indie developers working out of their bedroom can take the 30% so can they.
I don't think Microsoft would mind if Apple addressed their concerns by lowering the prices for everyone selling goods or services that aren't exclusively tied to an iOS app through an iOS app to some rate lower than the rate for app-functionality or app-exclusive-content sold through an app (which obviously has to be equal to the rate charged for apps themselves, otherwise in-app purchase becomes a tool for bypassing the charge on apps), or allowed such goods and services that aren't exclusively tied to a store-purchased app to be purchased through an app without using Apple's payment processing system at all the way the Google Play store does on Android.
That doesn't seem fair at all. Why should I pay more than you when we receive exactly the same government services?
Money is a government service. So, if you receive more money than someone else, you, ipso facto, do not receive "exactly the same government services" as they do.
Apple's approach is also considerably more sustainable, as it pays for itself, and can therefore last.
The Play store model pays for what costs Google money. It may not subsidize OS development, but all the rest of Google's services do that.
What happens when Google decides to stop spending billions on Android because they still make more money on iOS?
Google makes money from iOS use because iOS hasn't managed to monopolize the mobile OS market allowing Apple to prevent Google from being able to make money from it. Why is that? In large part, because of Android. While the long-term goal for products like Chrome (via ChromeOS) and Android is, of course, for them to become profitable in their own right, a major part of the value of both lines (Android and Chrome as Chrome-the-browser) has been in shaping what other people do in the mobile OS and browser space and in preventing/disrupting dominance of either space by a non-Google party, and thereby protecting Google's ability to continue to make revenue from its core business.
You might want to go look at the economics of Android, including how much Google has spent on it. What happens when Google decides to stop spending billions on Android because they still make more money on iOS?
Most likely, Google stops making money on iOS in fairly short order (and quite likely, much of the money they make outside of iOS), unless someone else with the will, resources, and ability steps in to prevent iOS dominance followed by Apple leveraging that dominance to take away Google's best revenue opportunities on the platform (and some that extend beyond the platform.) Chrome and Android serve in no small part to preventing a dominant browser or mobile OS vendor from leveraging that dominance to threaten Google's advertising and search business.
Slashdot Mirror
I think the change is best summed up in the fact that there used to be a front-page link to a section called "developers", and now that's gone and there is a link to a section called "cloud".
I've heard that the iOS Mail app doesn't support IMAP push, so push email from Gmail to the stock iPhone mail app won't work for new devices (the announcement stated that what is discontinued is the ability for users to add new devices for Google Sync, existing devices will continue to work.) The existing Gmail app on iOS isn't affected, either, since it isn't limited by the lack of features of the iOS mail app.
None of the discontinued features or services would make you use the GMail app. You can use any IMAP mail reader.
President Obama doesn't have any DAs, because District Attorneys work for local government (in California, specifically, county government.)
It may not be a complete solution, but it certainly deals with one of the major problems with having state laws against something that you don't actually want to be banned: specifically, the expenditure of state taxpayer funds in policing, prosecuting, and incarcerating people for doing something that you don't actually want to be prohibited. So, incomplete solution I can see. Counterproductive? I don't see that.
Repealing the state laws against something and electing federal representatives who will work to do so with the federal laws in the same area are not mutually exclusive approaches. In fact, state law changes often are an important part of the way that political pressure gets created to change federal law.
Uh, well, except that they just presented a plan to voters that pretty much completely solves the fiscal problems for the foreseeable future, and the voters passed it.
The termini of the proposed high speed rail systems are the most populous areas of the state (and the project also includes upgrades for existing conventional intercity and commuter rail systems.) Its hardly "to nowhere".
State officials aren't building a stadium in LA, and the people that have expressed interest in doing that aren't building anything until a team agrees to come, so this one is doubly wrong.
Cities are separate governments from the State, and, as you note, the State already largely addressed its budget shortfall, because in a surprising outbreak of common sense, voters voted to raise taxes to pay for the services they've demanded. There's still a small projected deficit under current policy for the next fiscal year, and then projected surpluses for the foreseeable future.
Delta has considerable physical business presence in California. Why wouldn't they be subject to California law?
Under any reasonable standard "to throw the child into a volcano" is an immoral purpose. So, while I think you are correct about the limitation, I don't think it makes the Mann Act inapplicable.
"Active" volcano has a lot of different definitions, but by any of the usual ones that's not true. See, e.g., this page on USGS volcano monitoring priorities.
I can do exactly the same thing using views in place of stored procs.
I can do exactly the same thing with views in place of stored procs for the exposed access; in fact, I can -- transparently to any interfacing application -- use stored procs to implement any of the the operations on the views where the imperative functionality provided by stored procs is beneficial, while letting the rest be handled by SQL which the DMBS's optimizer can optimize.
Obviously, letting a user have direct SELECT access to base tables allows them to dump the contents of the entire table. Equally obviously, allowing them to have similar access to a view doesn't allow them to do that unless the view is defined by something like SELECT * FROM base_table. But, if you are worried about preventing that kind of dumping, you won't define a view available to the user that way.
This bit of extra work is theoretically useful, I suppose, in that it could protect against the situation where the application's database user account is compromised, but neither the database superuser account nor the application itself (or the OS account it is running under) is compromised (if the application is compromised as well, it can simply collect valid user credentials to use); sane database security practices (e.g., not allowing the applications database user to logon with a simple username/password logon from arbitrary IP addresses) make it impractical to compromise the database user account of the application without, as a prequisite, compromising the application or its OS account or the database superuser account, so its less work to just use the database correctly.
The stored proc in the example doesn't get called until the query dynamically built from the input is parsed and evaluated, so the stored proc is exactly as vulnerable to SQL injection as the SELECT query. Which is true in the general case. SQL injection isn't a result of using select queries over using stored procs, its a result of using dynamically generated SQL using untrusted (or improperly-trusted) input. Using prepared parameterized queries avoids SQL injection, using stored procs, in and of itself, does not. (Certainly, most database interface libraries except very-low-level ones hide parameterization behind a function that also encapsulates generating the SQL for a stored proc calls, but that's also the case for most libraries when it comes to SELECT queries. The SQL injection problem comes into play when application developers don't use these functions -- either parameterizing themselves with a low-level library or using a higher-level library correctly -- and insist on generating their own SQL dynamically.)
He was, in fact, seeking asylum, which was denied.
And MySQL still lacks a lot of features that PostgreSQL has had for years (including SQL standard features like CTEs), many of which (CTEs included) are (at least, IMO) more generally useful than automatically updateable views.
Actually, it makes money from iOS largely because of AdMob, but the need to compete with other platforms is why Apple doesn't capture more than it already does of the revenue generated by any vector through iOS, including mobile advertising and search.
If you don't, you shouldn't hire them to work on an application that interfaces directly with your database.
This is better than rules (or triggers), where it works not only because it is standard (which triggers are, as well), but also because it doesn't require explict definition of the actions.
Some of it certainly is; in a perfect relational system, the boundaries on automatically updatable views would be broader and include any view where every possible row in the view had a 1:1 relationship with a possible row in each of the tables the view was based on (which is the same as saying that the view includes a candidate key for every base table.)
But even in an ideal system there are plenty of conceivable views which don't have a natural insert/update interpretation, and if you wanted to make them "updatable", you'd need to define for your system what that even means.
"You parameterize all user input" doesn't require use of stored procedures, or even views, it just requires not dynamically creating SQL by string concatenation/interpolation, and instead using the functions available in every database interface library that allow you to parameterize queries.
Obviously, not using user input it to dynamically create SQL is a fundamentally essential security practice for most applications (there are some exceptions, such as if you are trying to build something equivalent to a web-based SQL console), but it has nothing to do with using stored procedures. In fact, its quite possible to use stored procs (which can, after all, be called directly from SQL) using dynamically-generated SQL and make all the same mistakes that are possible with doing the same thing with regular DML queries against views or tables. Sure, your database library make provide a method to call a stored proc that automatically parameterizes arguments rather than forcing you to dynamically generated SQL -- but it also almost certainly has the same thing for regular queries.
There may have been a time when this wasn't true of some popular database libraries, which may have also contributed to the popularity of the "use stored procs for everything" approach, but if there was such a time, it wasn't recently.
Other than in the case of a single-application database (and, even then, only in fairly simple cases), using views rather than base tables for application isn't wrapping the tables in boilerplate.
The "all application code should go through stored procedures" rule is, as I understand it, a pragmatic rule that was recommended largely because most actual database systems at the time that rule became popular had view support that fell far enough short of the ideal in the relational model that the better and older "all application code should run against views" approach was generally impractical (helped by the fact that it let you have application programmers that didn't understand anything about relational databases.)
Its not really so much a matter of "current limitations". You can go beyond it a little bit, maybe, but there is a limit not far from the current documented limits beyond which you lose logical clarity as to the semantics of what an update to a view means, so updatable views either need explicit definition (which you can already do) or end up with automatic-but-not-obvious behavior.
There is quite a bit work going on on an initial implementation of matviews targetted for 9.3; losing updatable views wouldn't be likely to help you get matviews any sooner.
Every case where you are using a relational database with an application, since ideally every application should have its own set of views that form the application's interface to the database rather than using base tables. Having simple views (which usually will be fairly common if you are doing this) automatically updatable lowers the barriers to doing it.
I don't think Microsoft would mind if Apple addressed their concerns by lowering the prices for everyone selling goods or services that aren't exclusively tied to an iOS app through an iOS app to some rate lower than the rate for app-functionality or app-exclusive-content sold through an app (which obviously has to be equal to the rate charged for apps themselves, otherwise in-app purchase becomes a tool for bypassing the charge on apps), or allowed such goods and services that aren't exclusively tied to a store-purchased app to be purchased through an app without using Apple's payment processing system at all the way the Google Play store does on Android.
Money is a government service. So, if you receive more money than someone else, you, ipso facto, do not receive "exactly the same government services" as they do.
The Play store model pays for what costs Google money. It may not subsidize OS development, but all the rest of Google's services do that.
Google makes money from iOS use because iOS hasn't managed to monopolize the mobile OS market allowing Apple to prevent Google from being able to make money from it. Why is that? In large part, because of Android. While the long-term goal for products like Chrome (via ChromeOS) and Android is, of course, for them to become profitable in their own right, a major part of the value of both lines (Android and Chrome as Chrome-the-browser) has been in shaping what other people do in the mobile OS and browser space and in preventing/disrupting dominance of either space by a non-Google party, and thereby protecting Google's ability to continue to make revenue from its core business.
Most likely, Google stops making money on iOS in fairly short order (and quite likely, much of the money they make outside of iOS), unless someone else with the will, resources, and ability steps in to prevent iOS dominance followed by Apple leveraging that dominance to take away Google's best revenue opportunities on the platform (and some that extend beyond the platform.) Chrome and Android serve in no small part to preventing a dominant browser or mobile OS vendor from leveraging that dominance to threaten Google's advertising and search business.