Money is power, and there's no other way to regulate that kind of power besides taking some of it away.
Well, that's kind of an involved solution that will trigger nasty culture war battles. On a smaller scale we can tax lobbying money heavily and better enforce anti-trust.
We cannot ban lobbying money outright because the GOP-heavy Supreme Court ruled more or less that money is free speech, and thus we have legalized bribery. But, maybe we can at least tax the hell out of lobbying and campaign donations.
Someone please explain in a few words, what kind of "sector" that is supposed to be.
It's a synergized working environment to achieve advanced cyber results while optimizing office space to achieve maximum just-in-time productivity curves and dynamic staff allocation that adjusts to holistically fit customer-adaptable technology with cutting edge business needs. The future is in human clouds and your staff can be cloud-ready today!
The trick is how to profit from a bubble. If the big co's buy up all the AI co's, then you cannot put stock "puts" on them to gain when they crash. An AI crash won't affect the big co's that much.
So if I see a desk lamp in an antique store with bulbous "on" switch, and another antique lamp in a different store with a leopard pattern, and I combine the ideas to make and sell a leopard pattern lamp with a bulbous switch, I'd be infringing on another (non-antique) lamp that happened to do the same? Just about every fricken product in existence is a combination of at least 2 existing design ideas.
Now, I have seen examples where Samsung copied other ideas like the edge bevel style, black background (wallpaper), bottom grayish tray, etc. I will agree that if the quantity of elements copied reaches around 5 or so, then they've probably gone too far. The quantity and strength of similarities matter.
The three Apple patents covered design elements of the iPhone such as its black rectangular front face, rounded corners, and colorful grid of icons for programs and apps.
All of these existed in other prior products, just not together. In my opinion, there should be more than just 3 (potentially existing) concepts to be considered a valid design patent. Three is weak.
What about mixing cremated ash into cement and concrete? One can then literally become "one with the city". Soylent Cement Co.? Corporations ARE people? Let the jokes roll...
Isn't this how shady marketing co's generate click-bait? They use AI-ish techniques and/or humans to generate semi-random headlines from existing popular headlines and then test click responses online by embedding them in B-grade sites. Those headlines with the most clicks are fed back into the cycle to improve their click-rate.
You have old-style techniques like Markov chains to generate candidates headlines and Genetic Algorithms to cross-breed and test the candidates. Newer techniques can be added into the mix to improve the grammar and give it more options.
Hey, how about a "Slashdot Onion" section be created where readers contribute fake stories, and the most funny and/or interesting ones are voted to the top. Top reader comments and suggestions can be added to the final version. It could be a source of profits for Slashdot via ads. (Just make it clear it's satire.)
quote from Wikipedia "Singapore is a unitary multiparty parliamentary republic, with a Westminster system of unicameral parliamentary government." I'm sure there is someone out there with a higher intelligence that might be able to explain that.
In short, they are a totalitarian gov't, or what Americans often colloquially call "commies".
Singapore more or less pioneered the concept of what some call "capitalistic communism", and China shortly followed. Basically the centralized government allows a degree of capitalism, but keeps a close watch on it and meddles with companies from time to time as it sees fit.
The country has elections, but they are mostly for show: the candidates are pre-selected by the central party and are just figure-heads with no real power. Plus, there's no free-press nor free-speech. It's a fake democracy. (Some argue USA is drifting that way also as a plutocracy.)
Back-end tech changes slower. Anything geared toward front-end (UI) changes too fast. Unless you like learning 50 Shades of UX/UI every 50 days to keep up with the Joneses', hide from screens as you approach 50. PHB's and marketers will forever want the latest fashion.
If I'm developing a microservice, I don't need a database at all.
That depends on the service. If it's non-trivial it will probably need at least some database work such that putting non-UI-related algorithms on the database can simplify life.
And if it is trivial, wait UNTIL there's an actual microservice need before adding a microservice. YAGNI.
nodes running Python code are inherently making the same trade-offs without running a database at all.
Well, if your Python apps or libraries are doing enough database-y things like coordinating and managing shared and concurrent info, then congratulations! You've just reinvented a database! -- That future maintainers will know nothing about. RDBMS standardize storage, sharing, and concurrency issues so that each app writer doesn't have to make or learn a new and different wheel. They are not perfect (nothing is), but so far there's no competitor strong enough to unseat them. The declarative nature of SQL allows the server to automatically distribute the load of the processing and replication (if used) to multiple processors and/or servers so that app coders don't have to micromanage such. Python doesn't.
Even a simple select will bog down performance if you're using a disk-backed database
Who said databases have to use disks? Anyhow, again, one would have to know the specifics of this hypothetical app to propose a design and scaling path.
Because application state exists even if the microservice itself is stateless.
I thought you proposed using a microservice to manage session state backups, failover, and replication.
This is much more common than using a database due to performance.
Again, newer versions of RDBMS have better distributed processing options. They were not common before because most co's didn't want to sacrifice reliability or timeliness of the data, not because RDBMS are inherently wimpy. Per CAP theorem, there are trade-offs to consider. The newer RDBMS versions are offering the full gamut of CAP tradeoffs to compete with Hadoop etc.: you want distributed, you can get distributed, but have to still live with limits of the speed of light and the CAP-related tradeoffs it imposes. Python cannot go faster than the speed of light despite what some fanboyz may claim.
So when the active count goes to zero, it's safe to shut down the node.
There will be a small sliver of time between the time the algorithm checks the count (A) and the time it issues the shut-down command (B). It's possible another process could put items in the cart between A and B, and thus B can get shut down even though the cart is no longer empty. It may not be likely on a small scale, but for a high-volume system, the type where microservices are often looked at, those chance incidences grow more likely and can do bigger damage. Coordinating it properly takes us right back technologies such as ACID and dealing with CAP tradeoffs.
You'd be surprised just how small your application can be while benefiting from these kinds of technologies. Automated failover and true zero-downtime deploys are large benefits even if your application is tiny.
Claims are easy to make. I've heard those before from other Thing of the Month technologies. Justifying them with details, specifics, realistic test cases, and science is another matter.
I can only run PL/SQL in Oracle, and in most development environments, only on a very small number of servers.
Pick a different database. You are probably going to need one anyhow for direct databasey things even if you personally prefer writing as much as possible in a "flat" app language.
Most RDBMS require a single master node to do any writes, which means you can't scale the database out to additional nodes to gain write performance.
Newer RDBMS allow you to choose which letter to sacrifice per CAP theorem. Python can't do that without becoming a database.
Validating login tokens. You might start by using one database for all your data because "hey, I got a database and it works". But you'll quickly have pretty bad performance because you're constantly validating login tokens. So now you want to move the tokens to another database, most likely moving to a different technology like Redis.
The devil's in the details of how such tokens are validated, such as whether associated data and/or history is needed. A lot of services in practice are rarely an island and/or don't stay an island.
You usually write your microservices as stateless and either hand state around in the microservice calls. So now if the instance of the microservice processing your transaction dies, your application can re-submit the request and it will go to another instance.
If it's stateless why are you worried about state? It seems a contradiction. If you want server-side replication or backup of session state, then you either use a database or reinvent databasish needs.
If (version < current) and (active_carts <= 0) shut_down_service();
This can lead to race conditions and/or deadlocks if not handled carefully. Time to maybe consider ACID?
And you don't have to write or maintain it.
Companies package and sell software, that's not news.
Anyhow, when our org or apps grow to Netflix or Amazon size, I'll consider it. For now there's still plenty of options to scale regular web apps and RDBMSs between such time. We are good ways to go before we exhaust them.
Now I do agree it may be nice to have a transmission standard that blurs the line between web services, file systems, and databases to make it easier to switch and swap. But that's mostly a different problem than when and where to use a database.
The web needs a common client side computing platform, and I don't see where any useful alternative is going to come from right now.
The alternative is to move and do most of the layout and processing on the server side so that we don't have to reinvent a GUI OS inside JS libraries. And we'd get more consistent UI's so that we don't have to test 500 browser brand/version/OS-settings combos. Make the client as dumb as practically possible to keep it simple and from being a maintenance and testing bottleneck.
It could be somewhat like X-Windows, but be mostly vector based instead of pixel based, and have better input field buffering for slow or delayed connections. The client would basically be a dumb vector plotter. Layout engine(s) would be on the server (including the option of WYSIWYG if you don't want to use a layout engine.)
You may still need a small amount of client-side-scripting in some cases, but this would greatly reduce the need for and reliance on it.
There's nothing that says a microservice architecture has to communicate via direct network calls. In fact, using some sort of database as a messaging system is one extremely common way microservices are implemented.
It sounds like you are stretching the definition such that anything that communicates over the network is a "microservice".
Putting the logic in the database ties you to that particular data store
You have to tie it to SOME language. If you write it in Python then you tie it to Python. At least databases are designed to handle database-ish things: large scale data chomping. If you use the query language right, you can automatically get parallelism and scaling. Python doesn't have that, and if it did it would be reinventing a database and then just be competing as yet another database.
good DBAs that can properly optimize that SQL logic are harder to find than good coders.
Skill shortage/availability profiles change over time. If you are saying microservices are about reinventing/replacing the DB, well, that's kind of big and different topic.
My observation is that database platforms outlast "in" programming languages.
You draw the lines where they make sense.
No disagreement there. Just make sure there is a real need rather than "everyone else cool is doing it". Or "big co's are doing it so our Mom-and-Pop shop should do it also."
For example, query tuning and DB indexing can only get you so far. Sometimes you just have to make another database. Having a "data" microservice gives you the option to do that without changing everything else.
Make another database? Can you provide a specific example scenario?
To do it properly, you're talking about a complete refactor of the application.
Again, I'm skeptical. I'd like to see a specific scenario. An "application" is largely a series of conventions. Changing conventions for overhauls requires changing interfaces, regardless of what the interfaces are written in. If a prior 1-to-1 relationships become 1-to-many, related INTERFACES will probably have to change regardless of whether that interface is language API's, JSON, XML, CSV, SQL, etc. Semantics have changed.
Web servers can't really provide zero-downtime deployments. Sure, the http requests have somewhere to go, but you typically lose state since the web server is not aware of state within the application.
You mean session data? If the machine the session data is on dies, it dies. Micrososervices won't save you. It's possible to have some kind of replication of session data, but Microservices don't provide that out-of-the-box, and don't necessarily do it better than alternatives, such as an RDBMS.
Eventually the old service's metrics indicate it can shut itself off (0 open carts in this contrived example).... In a microservice architecture the migration happens automatically.
Please clarify how an "open cart" is defined and "the services metrics". An "open cart" is a business domain object/thing. Again, that doesn't appear to be something out of the box, but biz logic created specifically for the shopping cart system (or specific components selected for it).
Maybe for large and distributed non-financial systems like Netflix, gajillion little network services may make sense. But that's only like one out of every 10000 applications.
The service registry is a key part of service discovery. It is a database containing the network locations of service instances. A service registry needs to be highly available and up to date. Clients can cache network
That it was successful doesn't necessarily mean it's better than the alternatives, such as direct API's and/or stored procedures. One would have to do a side-by-side comparison and/or be given sufficient specific scenarios where one clearly does worse and can't be tuned. Now I do agree that microservices may be better in a mixed language/tool environment for such security management.
Slashdot Mirror
Well, that's kind of an involved solution that will trigger nasty culture war battles. On a smaller scale we can tax lobbying money heavily and better enforce anti-trust.
We cannot ban lobbying money outright because the GOP-heavy Supreme Court ruled more or less that money is free speech, and thus we have legalized bribery. But, maybe we can at least tax the hell out of lobbying and campaign donations.
We are working on AI translators that convert back and forth between English and MBA.
Example:
MBA: "Our organization has adamantly decided not to tolerate any memos, emails, or documents which reduce our reputation among potential clients."
English: "Bash us and you're fired!"
It's a synergized working environment to achieve advanced cyber results while optimizing office space to achieve maximum just-in-time productivity curves and dynamic staff allocation that adjusts to holistically fit customer-adaptable technology with cutting edge business needs. The future is in human clouds and your staff can be cloud-ready today!
The trick is how to profit from a bubble. If the big co's buy up all the AI co's, then you cannot put stock "puts" on them to gain when they crash. An AI crash won't affect the big co's that much.
When are F-Cigarettes coming out?
Are they compatible with all those ET game cartridges in landfill?
Are you saying this all basically comes down to a paper-work snafu?
So if I see a desk lamp in an antique store with bulbous "on" switch, and another antique lamp in a different store with a leopard pattern, and I combine the ideas to make and sell a leopard pattern lamp with a bulbous switch, I'd be infringing on another (non-antique) lamp that happened to do the same? Just about every fricken product in existence is a combination of at least 2 existing design ideas.
Now, I have seen examples where Samsung copied other ideas like the edge bevel style, black background (wallpaper), bottom grayish tray, etc. I will agree that if the quantity of elements copied reaches around 5 or so, then they've probably gone too far. The quantity and strength of similarities matter.
4) Full of crap.
All of these existed in other prior products, just not together. In my opinion, there should be more than just 3 (potentially existing) concepts to be considered a valid design patent. Three is weak.
What about mixing cremated ash into cement and concrete? One can then literally become "one with the city". Soylent Cement Co.? Corporations ARE people? Let the jokes roll...
Isn't this how shady marketing co's generate click-bait? They use AI-ish techniques and/or humans to generate semi-random headlines from existing popular headlines and then test click responses online by embedding them in B-grade sites. Those headlines with the most clicks are fed back into the cycle to improve their click-rate.
You have old-style techniques like Markov chains to generate candidates headlines and Genetic Algorithms to cross-breed and test the candidates. Newer techniques can be added into the mix to improve the grammar and give it more options.
Hey, how about a "Slashdot Onion" section be created where readers contribute fake stories, and the most funny and/or interesting ones are voted to the top. Top reader comments and suggestions can be added to the final version. It could be a source of profits for Slashdot via ads. (Just make it clear it's satire.)
Any holidays in Clippitober?
That sounds like him. [paraphrased]
Next up, Trump patents chaos.
In short, they are a totalitarian gov't, or what Americans often colloquially call "commies".
Singapore more or less pioneered the concept of what some call "capitalistic communism", and China shortly followed. Basically the centralized government allows a degree of capitalism, but keeps a close watch on it and meddles with companies from time to time as it sees fit.
The country has elections, but they are mostly for show: the candidates are pre-selected by the central party and are just figure-heads with no real power. Plus, there's no free-press nor free-speech. It's a fake democracy. (Some argue USA is drifting that way also as a plutocracy.)
Back-end tech changes slower. Anything geared toward front-end (UI) changes too fast. Unless you like learning 50 Shades of UX/UI every 50 days to keep up with the Joneses', hide from screens as you approach 50. PHB's and marketers will forever want the latest fashion.
That depends on the service. If it's non-trivial it will probably need at least some database work such that putting non-UI-related algorithms on the database can simplify life.
And if it is trivial, wait UNTIL there's an actual microservice need before adding a microservice. YAGNI.
Well, if your Python apps or libraries are doing enough database-y things like coordinating and managing shared and concurrent info, then congratulations! You've just reinvented a database! -- That future maintainers will know nothing about. RDBMS standardize storage, sharing, and concurrency issues so that each app writer doesn't have to make or learn a new and different wheel. They are not perfect (nothing is), but so far there's no competitor strong enough to unseat them. The declarative nature of SQL allows the server to automatically distribute the load of the processing and replication (if used) to multiple processors and/or servers so that app coders don't have to micromanage such. Python doesn't.
Who said databases have to use disks? Anyhow, again, one would have to know the specifics of this hypothetical app to propose a design and scaling path.
I thought you proposed using a microservice to manage session state backups, failover, and replication.
Again, newer versions of RDBMS have better distributed processing options. They were not common before because most co's didn't want to sacrifice reliability or timeliness of the data, not because RDBMS are inherently wimpy. Per CAP theorem, there are trade-offs to consider. The newer RDBMS versions are offering the full gamut of CAP tradeoffs to compete with Hadoop etc.: you want distributed, you can get distributed, but have to still live with limits of the speed of light and the CAP-related tradeoffs it imposes. Python cannot go faster than the speed of light despite what some fanboyz may claim.
There will be a small sliver of time between the time the algorithm checks the count (A) and the time it issues the shut-down command (B). It's possible another process could put items in the cart between A and B, and thus B can get shut down even though the cart is no longer empty. It may not be likely on a small scale, but for a high-volume system, the type where microservices are often looked at, those chance incidences grow more likely and can do bigger damage. Coordinating it properly takes us right back technologies such as ACID and dealing with CAP tradeoffs.
Claims are easy to make. I've heard those before from other Thing of the Month technologies. Justifying them with details, specifics, realistic test cases, and science is another matter.
Pick a different database. You are probably going to need one anyhow for direct databasey things even if you personally prefer writing as much as possible in a "flat" app language.
Newer RDBMS allow you to choose which letter to sacrifice per CAP theorem. Python can't do that without becoming a database.
The devil's in the details of how such tokens are validated, such as whether associated data and/or history is needed. A lot of services in practice are rarely an island and/or don't stay an island.
If it's stateless why are you worried about state? It seems a contradiction. If you want server-side replication or backup of session state, then you either use a database or reinvent databasish needs.
This can lead to race conditions and/or deadlocks if not handled carefully. Time to maybe consider ACID?
Companies package and sell software, that's not news.
Anyhow, when our org or apps grow to Netflix or Amazon size, I'll consider it. For now there's still plenty of options to scale regular web apps and RDBMSs between such time. We are good ways to go before we exhaust them.
Now I do agree it may be nice to have a transmission standard that blurs the line between web services, file systems, and databases to make it easier to switch and swap. But that's mostly a different problem than when and where to use a database.
The alternative is to move and do most of the layout and processing on the server side so that we don't have to reinvent a GUI OS inside JS libraries. And we'd get more consistent UI's so that we don't have to test 500 browser brand/version/OS-settings combos. Make the client as dumb as practically possible to keep it simple and from being a maintenance and testing bottleneck.
It could be somewhat like X-Windows, but be mostly vector based instead of pixel based, and have better input field buffering for slow or delayed connections. The client would basically be a dumb vector plotter. Layout engine(s) would be on the server (including the option of WYSIWYG if you don't want to use a layout engine.)
You may still need a small amount of client-side-scripting in some cases, but this would greatly reduce the need for and reliance on it.
It sounds like you are stretching the definition such that anything that communicates over the network is a "microservice".
You have to tie it to SOME language. If you write it in Python then you tie it to Python. At least databases are designed to handle database-ish things: large scale data chomping. If you use the query language right, you can automatically get parallelism and scaling. Python doesn't have that, and if it did it would be reinventing a database and then just be competing as yet another database.
Skill shortage/availability profiles change over time. If you are saying microservices are about reinventing/replacing the DB, well, that's kind of big and different topic.
My observation is that database platforms outlast "in" programming languages.
No disagreement there. Just make sure there is a real need rather than "everyone else cool is doing it". Or "big co's are doing it so our Mom-and-Pop shop should do it also."
Make another database? Can you provide a specific example scenario?
Again, I'm skeptical. I'd like to see a specific scenario. An "application" is largely a series of conventions. Changing conventions for overhauls requires changing interfaces, regardless of what the interfaces are written in. If a prior 1-to-1 relationships become 1-to-many, related INTERFACES will probably have to change regardless of whether that interface is language API's, JSON, XML, CSV, SQL, etc. Semantics have changed.
You mean session data? If the machine the session data is on dies, it dies. Micrososervices won't save you. It's possible to have some kind of replication of session data, but Microservices don't provide that out-of-the-box, and don't necessarily do it better than alternatives, such as an RDBMS.
Please clarify how an "open cart" is defined and "the services metrics". An "open cart" is a business domain object/thing. Again, that doesn't appear to be something out of the box, but biz logic created specifically for the shopping cart system (or specific components selected for it).
Maybe for large and distributed non-financial systems like Netflix, gajillion little network services may make sense. But that's only like one out of every 10000 applications.
Note this from https://www.nginx.com/blog/ser...
You're dusting it wrong.
-S. Jobs
That it was successful doesn't necessarily mean it's better than the alternatives, such as direct API's and/or stored procedures. One would have to do a side-by-side comparison and/or be given sufficient specific scenarios where one clearly does worse and can't be tuned. Now I do agree that microservices may be better in a mixed language/tool environment for such security management.
I have a relatively big brain, but I'm socially clueless.
What, they outbid Israel?
Some co's fire the bottom of the stack, others fire the top. This suggests a madness to the method.