"This order is not intended to, and does not, create any right or benefit, substantive or procedural, enforceable at law or in equity by any party against the United States, its departments, agencies, or entities, its officers, employees, or agents, or any other person."
In practical terms, this means:
1. Private parties (like TikTok or its users) cannot sue to enforce this EO
2. If the government doesn't follow the EO, you can't take them to court over it
3. Companies can't use this EO as a legal defense if they're sued
For example, if app stores keep hosting TikTok and get sued, they can't point to this EO as legal protection
This is important because while the EO tells app stores and other companies they won't be prosecuted, this disclaimer means they can't legally rely on that promise. If the EO is later found invalid or a new administration changes course, they could still face liability for actions taken during this period.
This creates a risky situation for companies trying to decide whether to comply with the law or follow the EO's guidance. A $5,000 fine per user of a 170M user platform means financial ruin for even Google and Apple if enforced. Larry Ellison (Oracle) might be willing to take that risk, and as a controlling founder he can do so without risk of being fired, but I don't think Tim Cook or Sundar Pichai are going to stick out their neck on this one.
That only applies if it happened before January 19th. That's why his 75 day EO just says they won't go after companies who violate the law, rather than say he's using the 90 day extension provided in the law (because it's too late to use that).
Some of the media isn't picking up on this nuance, but it's clear that's why it's a 75 day lack of enforcement, not a 90 day extension.
Bribes are generally illegal. This should be "compensates," not "bribes." "Bribes" is just hyperbole. This is standard practice for a lot of businesses in a similar space.
The central problem with SQL is a lack of modularity and reusability. The syntax is easy to learn, it's just onerous to do complex things.
Dev teams and analysts use text files, Gists, and emails to save hundreds of useful queries containing similar patterns, subqueries, and clauses that could easily be repurposed if the language had any reusability features. There's a lot of waste and it can feel like a big task to ask a simple question.
That said, it's very easy to learn SQL and the author's suggestions don't seem to maintain that learning curve. I disagree that "human language mimicking" is a problem -- SQL syntax actually makes a lot of sense (I'm "SELECTing FROM a table and ORDERing the results" etc).
What we need is a higher level language or tool to describe relations in a database -- something like an ORM or XML used in legacy BI tools. SQL still lives underneath. IBM Cognos, SAP Business Objects, Microstrategy, and others tried this to varying levels of success. Another commenter (siganakis) gets it right: "I would prefer a syntax layer that can be compiled / transformed back to SQL."
We're actually working on something very similar to that at Looker (http://looker.com) if anyone is interested in hearing more about it, but we aren't quite at the point where we can release the language spec to the world yet.
A data ETL tool. Now that lots of companies are moving to MPP databases like Vertica, Redshift, Teradata, and Netezza, it's incredible that there is still no straighforward way to do so without extensive systems and data engineering experience.
Every time a customer asks us to recommend a tool to do this, we are baffled that nobody has taken this on yet (and wonder if we should do it ourselves).
The opportunity to build the Stripe for ETL is only going to get bigger.
yep, mine is keetsa as well. keetsa = warby parker without the hype or e-commerce focus (but maybe there's opportunity there). the salesman actually suggested i should get a lower end mattress than the one i thought i was going to buy. great company.