joshdev

We discovered a bug in AWS Bedrock that is double counting cache writes when thinking/reasoning is enabled for the Anthropic models. It’s not clear to me if this is limited to just AWS Bedrock or all providers. AWS Support is aware.

We’ve also observed a much higher cache miss rate in the past few weeks. Combine both together and your usage consumption can be greatly increased.

What is the better solution you’ve moved on to?

This is the way. As others mention opening window is your cheapest option, but you lose a lot of your heating and cooling efficiency. We installed a whole house ERV for about $10K and saw a significant drop in CO2 readings.

I remember KoolBear from playing on Kali. That brings back good memories.

Hang in there. I’ve had the same challenge. Take some time off and burn through any energy accumulated taking care family in just a few days.

Best I’ve found is to try and keep things at a slow burn. You’ll never really relax but you can try to reduce the stress peaks.

I wonder if there is a case to be made for a patch branch that gets all PRs. Then the maintainer can do any further tweaks needed before merging down to mainline.

HN with an RSS reader is the way to go. No need to compulsively check and you can skim through things quickly.

Another way to look at it is you are expected to include business factors into your decision making. Sometimes the most optimal engineering solution is not the most optimal business solution. Politics can definitely be a factor, but being able explain clearly why doing something helps the business can be a big part of making the jump to more senior roles.

Have you considered looking at Amazon for their ARM offering (Graviton)? I'd be hesistant to use M1 minis for a production workflow as they are not really production grade (lacking ECC memory, not sure how long they are rated to run at high CPU, lack of user replaceable disks, no RAID, etc...).

It sounds like you just don’t enjoy frontend work. If you are trying to build a product on your own it’s impossible to avoid, but there are plenty of companies in the EU and US hiring for backend developers. Understanding how both sides get work done is important, but there is nothing wrong with focusing on just one area.

It's funny I have a logitech cam at the top of my monitor, which effectively covers the exact same space as this new notch. The bezels on monitors have gotten so thin it's tough to include add ons.

I get the use case, but I just can’t get behind using software like this for security reasons. It’s too easy to add users to slack, leading to accidentally exposing secrets.

Having worked remote before the pandemic I found having my camera on was a very good reminder to the team that I was still there. Increasing your visibility when you are one of a few remote employees is very important.

All that said a camera only helps so much. There is something to be said for traveling to your office periodically to put in real face time. I’m looking forward to offices starting to open up here soon.

Idiomatic scala yes, but while on boarding engineers hit many cases, where they ended up returning null in places they shouldn’t.

Somebody has used Scala

I had to switch back to drip for this very reason. I compensated by getting a good grinder and a solid whole bean subscription.

I think having a zero P0 and P1 bug policy makes sense. As others have said some bugs may not make business sense to fix. I do think it is useful to set thresholds for other bug priorities as well. 1,000 P2 bugs may make your product feel unusable.

Type inference is super handy in a lot of places. The problem I've run into in the rust book and other intro docs is they almost always use type inference, which makes it harder to learn what is going on. I'd prefer they used explicit types to start and then ease into type inference.

That's fair. When I say appreciate, I mean the results of the grind. Washing Dishes or any type of cleaning isn't fun, but finding coping mechanisms (zoning out, music, etc...) you can enjoy the results.

All jobs have some amount of grind. Being able to acknowledge its going to suck and push through it quickly can be super beneficial to your career. It's also one of the reasons why I encourage those in high school or college to try a non technical job first. Learn to appreciate doing monotonous tasks well.

The best advice I can give is to stop attaching yourself to a specific language. Having expertise in a language can be great, but you are going to be better served by demonstrating the ability to ramp up on any language that is needed. Scala is a solid language, but is plagued with functional purists and a love of domain specific languages. Take the skills and patterns you've learned from Scala and apply them to other jobs.

I wonder if it makes sense to create a new uri scheme for local https access. Something along the lines of locals://<ip>, which would receive different treatment by browsers.

* Mythical Man Month

* Pragmatic Programmer

* Code Complete

I think the main issue is that beyond the very basic examples the new Docker 1.12 swarm features aren't really production ready. At this point there is a significant amount of tooling required to get a production cluster running with your applications. The Distributed Application Bundles (DAB) files, one of the features I was most excited about, are still marked as experimental.

Overall I think Docker is heading in the right direction, but for now Kubernetes, ECS, etc... are better solutions for orchestration. I was hoping to only use Docker for my current project, but I think I'll have to wait until the next one rolls around and Docker releases a few more updates.

Based on my experience with SaaS, those that do offer Open Source software, are only open sourcing the core of their product. There is typically a whole suite of tools and add ons that expand their core offering into something that makes it more beneficial for companies to just go with the SaaS offering. Deployment and monitoring are two pieces that come to mind.

It appears to be a fork of Atom.io. Just take a look at the app contents on OSX.

  $ ls "Visual Studio Code.app/Contents/MacOS/"
  Atom

That's where I think containers come in handy. Assuming you have other services you are managing you can pack them into instances running your main workload. https://aws.amazon.com/blogs/aws/cloud-container-management/ will likely make that very easy to manage, assuming you are willing to go all in with Amazon.

I agree that there is value in having a team handle both the research & development phases. That said, you may not need the full team to handle research. Not all team members may be interested in research related tasks or have the discipline to execute effectively on them.

From a company standpoint the challenge is to make the research phase valuable, even when the results are not positive. With limited resources, it is tough to balance too much or too little research. As the phase is harder to plan for, you are usually stuck with some timeboxed effort. There is immense pressure for that timeboxed effort to provide some direction for moving forward.

OSSEC combined with Logstash, Elasticsearch, and Kibana can give you a lot of this data on the fly. Here is my list of bad ssh logins from the past 24 hours.

  Taiwan              145963   
  China               15881  
  Korea, Republic of  14079  
  United States       9600   
  Kuwait              1769   
  Thailand            1563   
  Portugal            1518   
  United Kingdom      788  
  India               558  
  Saudi Arabia        284  
  Russian Federation  190  
  Japan               146  
  Turkey              94   
  Bulgaria            83   
  Brazil              35   
  Netherlands         33   
  Rwanda              28   
  Hong Kong           22   
  Germany             19   
  Romania             15   

Some details on the end to end setup https://groups.google.com/forum/#!searchin/ossec-list/kibana...