I've also used m247 in the past, but had terrible experiences with them since they were acquired by private equity - network & support quality went really downhill.
For servers, I use https://serverfactory.com/ and https://www.rackservers.com/. As is typical for this kind of thing ignore the online pricing and email in - you'll usually do rather better, but they'll want you to pay by bank transfer.
edit: being outside of London means power is a lot cheaper, but I get about an extra 2ms of latency to my server. I consider that a reasonable tradeoff :)
I rand rados benchmarks and it seems writes are about 74MB/s, whereas both random and sequential reads are running at about 130MB/s, which is about wire speed given the 1Gbit/s NICs.
I haven't had an excuse to test it yet, but since it's only 6 OSDs across 3 nodes and all of them are spinning rust, I'd be surprised if performance was amazing.
I'm definitely curious to find out though, so I'll run some tests and get back to you!
This is a big question for me. The CDK style form of authoring IaC is way better than config files in HCL/YML/JSON. It has some rough edges and I do wish it wasn't so gung-ho on the magical object-oriented constructor side-effects, but it's still a net improvement.
CDKTF looks promising. How will OpenTF interplay with it?
I'm not into the CDK at all to be honest but isn't it a glorified preprocessor that generates the JSON representation of Terraform input, which is then processed as usual by your regular Terraform binary?
To each his own I guess. I personally like the HTML-like mental model that HCL gives me. In a sense not being a programming language is to me a benefit. If anything, I'd love to see an equivalent of CSS to Terraform - an idea someone smarter than me was floating not so long ago. Decoupling structure from specifics - I can see a well thought-out implementation of this concept actually taking off.
Re: programming languages... I love programming. Just not my infra.
Disclaimer: I work for Google but nothing I say here is Google's opinion or relies on any Google internal information.
I'm not surprised that Workspace accounts weren't included in the initial rollout. Workspace setups have interesting requirements that aren't necessarily there for personal accounts. For example, under some circumstances, if an employee gets hit by a bus, and there is critical business data which is stored in the employee's account, an appropriately authorized Workspace admin is supposed to be able to gain access to the employee's account. But what is the right thing to do for passkey access? Especially if the user uses passkey to authenticate to some non-:Google resource like, say, Slack which has been set up for corporate use? Should the workspace admin be able to impersonate the corporate employee in order to gain access to non-Google resources via passkey? What about if the employee (accidentally) uses their corporate account to set up a passkey to a personal account, such as for example E*Trade? Maybe the Workspace admin should have a setting where passkey creation is disabled except for an allowlist of domains that are allowed for corporate workflows? It's complicated, and if I were the product manager, I'd want to take my time, understand all of the different customer requirements (where customer === the Workspace administrator who is paying the bills) before rolling out support for Workspace accounts.
I've seen this recently, but only in the last few months, after years of using Little Snitch with Spaces, so I think it's a new thing either with the most recent version of Little Snitch, or macOS Ventura.
I wrote w LS support, it is a Ventura-related issue. They've made a request, but it appears Apple has yet to address the problem.
This, unfortunately, is a major problem for my use of LS. Interrupted connection attempts happen silently and result in different behavior for each app they affect.
I've had the most problems with requests from pycharm, where the binary is updated regularly and needs a bunch of re-authorizations.
I'm ready to give up on Spaces, it is so poorly supported by Apple at this point.
Hackworth Ltd is a private limited company based in the UK. Our first product is a novel, web-based visual programming language designed to teach functional programming to beginners. Our tech stack is Haskell (backend) and TypeScript + React (frontend).
We're looking for a frontend web developer to join our team and help us ship this product. You should have at least some experience developing & testing bespoke, highly interactive UIs. Experience with D3.js, Visx, or similar visualization libraries is a bonus, but not required.
This is a full-time role on a fixed-term contract (until June 1 2023). Depending on how our product launch goes, there may be an opportunity to switch to a permanent role at a later date. Due to the product schedule and the amount of time required for someone new to ramp up, we need someone who can start more or less immediately.
We are fully remote within the UK. You must be eligible to work in the UK, as unfortunately, we can't sponsor visas at this time.
The full job posting is here, along with useful information about what it's like to work at Hackworth:
Hackworth Ltd is a private limited company based in the UK. Our first product is a novel web-based visual programming language designed to teach functional programming to beginners. Our tech stack is Haskell (backend) and TypeScript + React (frontend).
We're looking for a frontend web developer to join our team and help us ship this product. You should have at least some experience developing & testing bespoke, highly interactive UIs.
This is a full-time role on a fixed-term contract (until 1 May 2023). Depending on the success of our product launch, there may be an opportunity to switch to a permanent role. Due to the product schedule and the amount of time required for someone new to ramp up, we need someone who can start more or less immediately.
We are fully remote within the UK. You must be eligible to work in the UK, as unfortunately, we can't sponsor visas at this time.
The full job posting is here, along with useful information about what it's like to work at Hackworth:
This role is a great opportunity to help create an innovative, highly interactive user interface, while also making a positive impact on the world by helping kids learn to program.
We hope to hear from you! If you're interested, please email careers@hackworthltd.com and it'll come directly to me.
I'm in the process of doing this now. You can close accounts from Control Tower without needing to log in as root to each separate account, adding a credit card, removing it from the org, and then closing it manually.
However, you can only close them from Control Tower at the rate of 2 to 3 per month, due to a hard limit quota which cannot be changed, even if you request it. Needless to say, this sucks when you've followed AWS's own best practices and created lots of accounts using Control Tower's "vending machine."
AWS's archaic account model is one reason we've switched to GCP.
To be exact, the hard limit is: you cannot delete more than 10% of your organization's accounts (capped at 200) via AWS Organization within a 30 day rolling window. You can always delete an account by going into it as the root user.
If that was the concern then surely they could enable support to restore accounts during some grace period. The machinery for that already exists for people who completely close their AWS accounts down.
Maybe it was quicker to implement with a hard limit, or there is some internal service that can't easily handle large volumes of account removals. But if it was Amazon losing money from this limitation instead of the customer I imagine it would be fixed pretty quickly.
