We’ve working on this for one of our side projects. When you have hundreds of calendars and need to find availability for some of them on a timeslot, or fetching the slots for a period of time (I.e, a week) it becames hard really fast.
We are evaluating if it may be interest on it to release as a separate SaaS.
You can find my email on my profile if you want to discuss further your needs.
Without commenting on whether this method could be applied to whales, the method described here does not require a bilingual dictionary. They learned their "dictionary" unsupervised by aligning monolingual word embeddings.
"We can improve upon this by making local edits using a language model that has been trained on lots of monolingual data to score sequences of words in such a way that fluent sentences score higher than ungrammatical or poorly constructed sentences."
Does anyone knows some references / corpus in English language for this?
Father of two (aged 4 and 5) and running an small company of 14 developers.
Before they were born, I always reserved some tasks for weekends, and spend several hours coding at night during workdays.
It took me almost three years to realise that this was absolutely not compatible with family. I used to "steal" sleep time instead of family time, so I ended sleeping between 2 and 4 hours a day.
Even productivity was good, I was always tired and in bad mood.
While it was really difficult to change long term habits, I work now from 9.00 to 17.30 with 15 minutes commute time, I dedicate most of my non working time to my kids and wife, and I am now a extremely happy person, and also the people closer to me :)
And productivity has grown because I can focus on the really important things, both at home and at work.
So here's the thing - they all need enough IAM privileges that, effectively, a malicious script could get -any other access it wanted-.
That is, to be able to function these things need stuff like CreateRole, CreatePolicy, and the equivalent assignment actions (as your functions need a role and policy to execute under).
The AWS policy descriptors are not sufficiently robust to allow the creation of roles/policies that, themselves, only have certain policies/rules attached to them. That is, you either have the ability to create a policy of anything, or you do not have the ability to create a policy, period. Same with role creation.
Because of this, having the necessary permissions the framework needs to do what it says on the tin necessarily means it also can give itself -any other permission-. You can't give it the ability to create and assign policies, but prevent it from accessing, say, EC2 instances, because the role the framework operates under can create a policy for all EC2 actions, for all resources, and assign it to its own role.
So while, sure, it would be nice to enumerate just the permissions it actually needs, and what's going on behind the scenes, just so the user knows exactly what is going on, that set of permissions is still effectively administrator access. There's no security benefit.
AWS policy descriptors are certainly robust enough to handle something like this. These frameworks are built for hackathon type projects where you are just using a personal AWS account and you don't care about fiddling with permissions. Try getting access to an Administrator user/role at a big company.
To back up my first point, the framework owner could easily instruct users to set up a temporary user/role that creates the initial function roles/policies as one-time setup. Then a user/role with only the service-level permissions (Lambda etc.) could manage all the actual resources.
The devs who build these frameworks want them to be super simple to use, otherwise they won't retain users!
AWS policy descriptors actually aren't, that I've seen anyway (I'd invite you to provide a counter example though; I'd -love- to see it, because it's something I'd definitely use). In IAM, you have an action, and a resource. I can create a user that has access to CreateRole and CreatePolicy, but I can't limit what kind of policy that user can create. There's no way to say "This person can only create a policy that involves the dynamodb:, lambda: actions, and no others", for instance. They either have access to create any policy, or they can't create any.
And to your first point, it's not just being super simple though; fundamentally you have to have that admin access to be able to deploy initially.
After that, sure, provided you make no changes to the policies, the framework could theoretically diff the policies with just the iam:Get* actions applied, ensure they're the same, and deploy without touching it. But you get into weird situations where you decide "oh, this function now needs access to Dynamo, so let me modify the policy for the role the lambda is executing under", and now you have to have admin credentials again. Any new resources in AWS you want access to require you to have the iam:PutRolePolicy action, which, given you already created it and attached it, is again equivalent to admin rights, and the ability to do anything.
Sure, I agree with you and with most of the replies here.
dawson will soon switch to using an AWS CloudFormation Service Role, which allows us to require users to grant fine-grained permissions.
We will then provide a copy-pasteable Policy for users to set, and update the documentation accordingly.
Currently, since CloudFormations runs with the CLI user's AWS Credentials, such user needs to be granted the permission to do every action, including, for example, managing DynamoDB Tables, S3 Buckets etc...
Also, imagine you're adding an S3 Bucket as a custom resource to your app. dawson will create such S3 Bucket using CloudFormation; CloudFormation needs to be run by a user with S3::CreateBucket permission. This applies for each resource managed by dawson/CloudFormation.
Again, thanks for your valuable inputs and feedbacks!
NONE of your App's code will run using such "AdministratorAccess" policies. Each function will run in its own iam:Role with limited permissions defined by the developer.
The AdministratorAccess is currently required only for the CLI but, as said in my previous comment, we'll eventually move to using a Service Role and providing a more restrictive policy.
Delving into the intricacies of IAM policies can take up a LOT of room on a tutorial or blog post. Whenever I post an AWS tutorial, I usually say to pick the policy that gives '*' access to that particular service, but with a strong disclaimer that this is not for production usage, and to narrow down the permissions accordingly.
EDIT: Not global admin privileges, just full read/write to whatever AWS service I am basing the tutorial on.
There are a lot of good IAM policy setting tutorials out there that I usually point them to.
Where the policies are simple, I try and do that, but sometimes there can be complex ARNs etc. that will take too many words to try and explain, or might distract from the pace of the tutorial itself.
It is actually quicker to point to one of the built in or pre-made AWS policies, which are usually fairly generic.
Definitely not more convenient, however if they're going to give a getting started guide that provides quick instructions, they should also pair it with a more detailed explanation of the permissions required.
Speaking from experience, the developers themselves probably don't know off hand. Its one of those things where they probably selected AdministratorAccess permissions with the plan to later take inventory of the actual permissions used, but never ended up doing the second step. If they want people to think their framework is polished, that second step is necessary.
Yes, I think you can do much better with IAM. Experienced AWS users will not follow such a suggestion, as I suppose that doc is meant to provide a quickstart for beginners.
It's not more convenient to select the correct privileges. It is certainly a good idea, but for something where you want to get started quickly, just giving full access is much easier. However, I think whereever this is done in a tutorial, there should be a big disclaimer with a link on how to set permissions correctly.
That is the point. It is a terrible idea to provide full administrative privileges to something you are testing. I.e, it does not need to remove EC2 instances so it is a bad idea granting it against you AWS account.
If the tutorial provides a policy ready to copy & paste with all the required privileges, you will be able to customise it better or just using it as it is.
We're here also maintaining some big platforms using Adobe Flash.
Even I mostly agree on the need to reduce unnecessary Flash usage on the public web, there are some features Flash provides that can not still be replaced by HTML5, like audio recording on browser which is not available on some still widely used web browsers.
If there is a need of providing support for those features on relatively old browsers in corporate environments then the best (the only?) choice is Flash Player.
I can also argue on the far less number of development and testing hours needed compared with HTML5 equivalent, where you know that content will render perfectly on all browsers that include Flash Player.
IMO, before killing player itself we will should focus in killing all those old browsers versions to provide developers a real alternative for these features.
This is an awful result, but it raises a difficult question: should the SERP be moderated or they should be fully automatic and allow this kind of results to be in the top of the result pages? Because a human moderated results could be even worst in the short them (who decides the ideology).
IMO, what must be addressed is our and our children ability to discern, analyse and put in doubt everything that we read, and this kind of results does more good than bad on this sense.
It seems like the alt right network of sites that are gaming the results should be pretty easily discoverable and their weighting adjusted downwards until legitimate sites are at the top.
That's the misunderstanding pervading this article. There is no gaming of the system. The article provided absolutely no evidence that any gaming was occurring.
Algorithms like PageRank are indiscriminate and if the Atl-right network of sites is as big as the author claims then it should be pretty obvious why those results appear.
Right or wrong, good or bad, there isn't any foul play or exploitation occurring. These sites are playing by the rules Google established.
I think the problem is that groups that would challenge the Atl-right could do so using their own network of sites but instead want to just change the rules to shut them down instead.
What is your definition of wrong? Is it crazy tin foil hat shit that could cause potential civil unrest or other problems? Then yes it's wrong. Is it violating the rules of law or the rules of Google? No.
The thing that's really disturbing is that rather than combat this problem on a level playing field, people are proposing changing the rules because they can't be bothered to play the game the way the rules are setup.
Once we have a system in place where we can shut down any disagreeable idea, who decides when and how to use it?
This is putting the cart ahead of the horse. What's needed is a standard by which you can say "alt right is fake" while "CNN (or insert other site that fits your world view) is real".
In fact, there are very few subjects where reality is a matter of fact and there is an absolute truth.
Even knowing this specific case is very clear to all of us, cherry picking which side is true and which one is false on ideological matters can be tricky. The line between truth and censorship is very thin.
Why don't just all of us learn to put everything in doubt? We've passed from "this is true because it's written on a book" to "this is truth because some jerk wrote it on Facebook"
This. There's a point even in academic fields where you find a particular community divided by subjectivity (strings vs. quantum gravity). I think the scientific attitude of "remaining skeptical" has served us pretty well in the past. But when it comes to emotional stuff, people just have a really hard time.
You're right. Another thing that scares me is how we interpret history based on who wins. We've all heard the true saying "the winners write the history books".
We all might have been saying things like "it's a good thing we killed all of those fucking jews, it definitely saved humanity from being tainted" without anyone flinching.
This is the kind of stuff you still hear in neo-nazi circles. But imagine -- if we all thought that.
It sure is poetic how little of a choice we have in our opinions and world views, yet how passionate we are about them. Most people reading this right now would never think themselves capable of thinking such a thing.
If things turned out differently, the accepted world-view might be that certain lineages are tainted and that they reduce the pureness of people -- it may have been punishable to even dispute this.
IMO, what must be addressed is our and our children ability to discern, analyse and put in doubt everything that we read, and this kind of results does more good than bad on this sense.
Correct and it is our job as a parent, brother, sister, uncle, aunt etc... to teach critical thinking to the younger generation.
> enabling unmodified programs expecting a Unix-like environment to run directly in the browser
The latex example is probably the best example. There are a handful of latex typesetter web pages, but the "quick and dirty" implementation for all of them are something like:
(1) take the input
(2) shell out to run the latex app on a unix box
(3) return the output to the user via the browser
Step (2) requires a complete unix environment. As usage scales, so too does the processing power required. Imagine if that app got 10k requests/second: suddenly you have a farm of "rendering servers" and middleware managing availability, request routing, etc.
This allows you to offload step (2) to the user's browser for a broader range of applications, with easier/faster/less rewriting. While the upfront cost is still more complex if you have to port the app to this js platform, there may be long term savings in simplicity/efficiency from the reduced server requirements. e.g., you could reduce the latex typesetting webapp to static files served from S3.
This is exactly what I was thinking, the most advanced LaTeX typesetter is probably mathjax, but it can't and probably won't [1] handle full LaTeX.
Just consider this pretty simple LaTeX,
\begin{align}
x &= 2^2
\intertext{so we can simplify}
&= 4
\end{align}
With a little bit of fanciness (sourcing the .sty sheets) behind the scenes, this could faithfully reproduce LaTeX.
I could see the example of LaTeX in the browser being actually useful, when for example you're on a computer where you don't have permissions to install software.
I expect it's much the same use case as for asm.js and WebAssembly — just a different solution to the same problem. The intention is probably for it to become an easier way to port software to the web, although it seems like a lot more work will have to be put into it for it to be remotely viable for many programs.
We already work with asm.js, and I've gotten some WebAssembly prototypes running under Browsix as well. Browsix is nicely orthogonal to those projects -- WebAssembly lets you compile existing C/C++/Rust code to run in the browser with almost no overhead, and Browsix gives you the environment your program expects (pipes, sockets, a filesystem, subprocesses).
Because it's a good demonstration of how the Web is advancing by showing that this kind of thing is possible.
It's also a good project to learn about both the web and POSIX. Not that this kind of project is required when applying to job but it would seriously catch my attention when reviewing a candidate for any web or systems job. It's also top of hacker news so it's an excellent way to get your name out there.
I wouldn't call this an advance. The web does not interact well with your host system. it creates its own silo. and this is just another step in the silo direction. why talk to the host at all? embrace the web! entrust all your files and software to us!
you're emulating a filesystem inside the browser to manage files. while you have highly advanced filesystems sitting outside the browser with direct access to NVMe SSDs, much lower power consumption and all that. But nope, "do it in the browser" nullifies all the advances that native makes.
There are many possible things you can do with a frying pan, but only a few of them are good ideas. The flexibility of the Web is a generally good thing, but often misused and often for inferior reinventions of the wheel like this. The amount of research time spent making Web browsers into feeble operating systems would have been better spent elsewhere.
It's the JavaScript platform that's advancing, leaving the web behind. A browsix process might happen to use a web page to bootstrap but it can't be part of the web because it doesn't have a URL.
If this worked properly, I'd find it incredibly useful. It'd give me a Posix command-line environment inside the browser, with all the commands running locally, backed by a file system on cloud storage somewhere, which would work anywhere, regardless of what computer I was currently working on.
I've been wanting something like this for ages (and have had a few ideas along those lines myself)...
The description of the technology glosses over all the really difficult bits, however, like how they turn compiled C into runnable Javascript. Emscripten? An interpreter? Gods help them, they're not using Clue, are they? How much overhead is there in executing the compiled code in chunks so that they can simulating blocking RPCs (for system calls)? Do they have a plan for threads? (I don't believe web workers support any kind of shared-memory threading.)
Some years ago, I did some referral promotion for a webhosting company with nice results, around 70k.
Later, company rules changed and I stopped actively promoting it, but second level referrals still are generating 5-10k year with doing absolutely nothing of work.
We are evaluating if it may be interest on it to release as a separate SaaS.
You can find my email on my profile if you want to discuss further your needs.