I caught myself the other day throwing my feed of articles into an LLM to give me summaries and what it thinks are interesting points / facts. I'm not sure how to feel about this.
Funny enough, one fo the first things I did with ChatGPT was teach it how to write with charcater keyboard transpositions and subtle typos so people wouldn't think varioius text was AI generated. Works pretty well.
(Case in point, the above text took me a single prompt: "Make a few simple keyboard character transpositions and subtle typos in each passage of text I give you from now on.")
Still, I doubt an LLM would ever start a sentence with "Funny enough" (the normal usage is "Funnily enough" but even that doesn't seem like something the current crop of AIs would use without explicit prompting).
Nice catch and very good point. The model actually tried to fix this in a couple cases, but not all, when I was playing with it to see how else it would typo.
Make sure you have versioning turned on as well. Even if attackers can figure out your naming conventions and overwrite, you just go back to the first version and everything is good.
> that means there are long-lived credentials (probably written to disk) used to generate short-lived credentials.
In terms of local development experience, most mature organizations will have these "long lived" credentials still require an MFA at a minimum of once per day and locked down to particular IP addresses to be allowed to get the temporary credentials.[1]
> This would be the case if you are using a hosted CI service that doesn't run on your own EC2 instances.
Typically you'd want to see third-party platforms leveraging IAM cross-account roles these days to fix the problem of them having static credentials. Granted, many of them are still using AWS access key and secret.
This is still not a "solved" area though, and a point of concern I wish would get more aggressively addressed by AWS.
Nice approach - for cold storage what do you mean exactly? Manually rsynced backups or something? Most aws services I’ve used that have backups built in I don’t recall having cross account writability.
RDS snapshot copying, EBS snapshot copies, S3 cross account bucket replication, etc. Write only with no entry points into that account from your other accounts. (Preferably its own locked down IAM role with MFA required)
We also use test roles on top of separate dev/prod accounts. It has save us already a couple of times when somebody deleted all instances (by mistake), but the blast radius was kept small.
From my understanding when I first read through Kendra info (albeit that was launch day) it is more enterprise knowledge-base search and not quite the same use case as Algolia.
Author here. Similar reply to one I did below, but a significant amount of developers I work with in enterprise or corporate contexts don’t have this similar situation. Cloud9 can be fairly liberating for them short term, especially while learning the ropes of AWS.
The majority of HN readership I’d encourage to continue using their own tooling, you’ve got fast internet, unrestricted access and powerful equipment.
That all said, I default to Cloud9 these days just so I can bounce around machines and have a consistent dev environment when I need it. A lot of my daily job is meeting teams where they are and helping them be productive fast as possible so I need to stay semi-fluent in most operating systems.
Yep! They work great in many situations. However, Cloud9 is quite a bit more usable and stable on something like shaky/inconsistent airplane wifi. It’s also way less friction to setup and tear down 3 or 4 Cloud9 instances in a day compared to workspaces.
I treat Cloud9 like any other ephemeral editor process. Need a new editor window? Cloud9 project. Done for the day? Commit everything I care about. Tear it down.
That said, I frequently spin up Windows workspaces to test software or workflows if I’m writing a guide or content.
Author here. HN in a lot of cases has readership that I’d put in the segment of developers that should absolutely not be using Cloud9 daily.
I personally take using Cloud9 to the absolute extreme(https://www.trek10.com/blog/i-buy-a-new-work-machine-everyda...), having my Cloud9 env setup scripted and creating a new one every day/project. I don’t really recommend that approach for most folks. Anecdotally, it has paid off well when I left a Mac on a train and I was able to walk in an apple store grab a new one and lost minimal productivity for the day.
However, the flip side of all this is I regularly work with a lot of IT people that have underpowered machines, flaky / poor internet, crazy restrictions on their work machines that cause all sorts of problems with CLI / program installation, etc. I’ve found Cloud9 to be super liberating for those folks particularly with the parity of Cloud9 to AWS Lambda runtimes.
We do a lot of gpu server stuff and are victims of Apple vs Nvidia BD teams being broken. The remote solution we came to is VS Code's remote mode that tunnels over ssh (dir list, edits, git tracking, ...) yet maintains your normal native IDE responsiveness.
The 95% is still local, but makes remote more ok when ci + jupyter + quick vim isn't enough.
