try this:
curl https://example.com/file.sh | bash
If your shell script needs sudo access, just:
curl https://example.com/file.sh | sudo bash
479 karma · joined June 10, 2015
curl https://example.com/file.sh | bash
If your shell script needs sudo access, just:
curl https://example.com/file.sh | sudo bash
Gonna be a bad day for a lot of folks if that goes down too.
I can't imagine calling retail "middle class" since it pays so little.
I talked to them twice on two separate occasions, different people and got asked the exact same questions.
This was over one year ago and things may have changed since then.
Performance suffers, and transactionality is a non-starter.
Best to forego this style and instead go with more of an RPC system.
Hope to look at this on my laptop later.
Thanks for sharing!
++Lack of Consistency in Project Structure:++
* The Django way of "several applications are in your application" creates many folders, each with either a models/ folder or models.py.
++Django ORM:++
* Writing a model which generates a migration, prefixes table names based on the "sub-application" name in my application is just awful. The default names for these tables is just another layer of cognitive load to bear.
* Implicit relationships between tables, vs allowing me to specify has_one/has_many/belongs_to/has_many_through/etc relationships.
* I miss FactoryGirl. Specifically I miss FactoryGirl's feature of allowing me to declare associations between my factories, then creating upstream objects in the proper order. Without this feature, I get a lot of repeated 'setup' code in my unit tests, which makes my tests brittle, and lowers their value.
++Django Testing:++
* Writing unit tests without the describe/context/it style feels like I just took a bus back to 1998. Combined with the lack of FactoryGirl, I see test suites that barely test the "happy path", let alone any "sad path" cases.
* Due to the brittle boilerplate setup code in unit tests, minor changes to the code tend to break tests badly, further slowing down the pace of development.
* The alternative to constantly fixing broken tests is to have fewer tests (or no tests) which is even worse IMO, since only your customers will test code code.
* The Rails way of writing a migration, making factories, making model specs, then controller specs (and finally features for end-user acceptance tests) seems to have gone completely off into an unknown future from the perspective of Django, who was left behind, frozen in time at the end of Bill Clinton's last term in office.
Is the scripting language in the gif example Ruby?
Consider running your authentication service as a separate node server so it can scale independent of the rest of your application.
If your org only has one project, then "OrgName/Docs" is great.
I have questions:
1) I have a 2-person startup and would like to use Scup instead of Olark. How to proceed?
2) I have a 80-200 person company. We use OTRS for customer issues. How to migrate to Scup?
3) I have a SaaS offering. How to integrate it with Scup? (like I can with Slack)
Interesting to think it goes in both directions!
Also, (spoiler alert) -- Man in the High Castle.
No, they track everyone, not just criminals.
Simply by saying "hey you may not have noticed X but when you do Y then this happens..." it can help the author(s) know:
* that a problem might exist in the code.
* that there's no problem but the docs made something unclear which led to the problem I reported.
* how others are actually using their software.
These are worth paying for on their own.
This de facto criminalization ad then licensing the privilege (nay right) to utilize these tools is a step in the wrong direction.
* docker build -t whatever -f some/Dockerfile .
* aws cloudformation update-stack ...