Plus the CBD one appeared when I had the "Kid Friendly" filter selected :-|
694 karma · joined April 22, 2014
Basic idea is to have a system call that allows library writers to get the bounds of a pointer. This way they can ensure they're not writing too much data to a location.
Another idea I've implemented in userspace is to create an allocator that allocates a page (via mmap) then set protections on the page before and after. The pointer returned aligns the end at the next page. If a write goes beyond the end of the pointer, it bumps into the protected page, and causes a fault. Then you can handle this fault, and detect an overflow.
A even more strict version of this is to add protection to the page the allocated pointer is assigned to. On _every_ write you get a fault, and can check that it's not out-of-bounds.
All of these methods are slow-as-hell, but detect any memory issues. While slow, they are faster than valgrind (not badmouthing it, it's an amazing tool!). So the recommendation is to use it in testing and CI/CD pipelines to detect issues, then switch to a real allocator for production.
I don't think this is true... It's more nuanced than this. Developers are much more skeptical of a "benefits" pitch, and care more about a "features" (and limitations as mentioned above) pitch. However, if you're just pitching a developer, you're probably only pitching the user, not the buyer. The buyer VERY much cares about the benefits, otherwise they're not buying. The buyer won't using a single feature, so that type of marketing is lost on them.
This is the challenge: the right message (features or benefits) to the right person (user or buyer) AND at the right time!
You can with log-store[1], as it allows you to run custom Python commands to do _exactly_ this!
I was arguing exactly the opposite... leverage S3's near-infinite storage so you can store whatever you'd like. Searching through it _can_ be fast with the right tool.
Without this you'll always be awoken by smoke, and at that point it's too late... there's already a fire. However, if you can monitor other things (gas pipes, lighters, etc), you might be able to remediate a problem before it starts smoking or burning.
There's no one-size-fits-all. Start with some obvious failure (e2e tests/checks; aka smoke), and when you root-cause, add in additional checks to hopefully catch things before the smoke. However, this also requires you update (or remove) these additional checks as your software and infra change... that's what most people forget, and then alert fatigue sets in, and everything becomes a non-alert.
I'd argue it _is_ solved... store your logs in S3. At ~$0.02/GB you can store a _lot_ of logs for like $20. The problem is that _most_ solutions (Honeycomb included) are SaaS-based solutions, and so they have to charge a margin on top of whatever provider is charging them.
You just need a tool (like log-store.com) that can search through logs when they're stored in S3!
I'll bite... why _not_ "ingest all the metrics/logs"? I see 2 possible reasons: 1) don't have enough resources (CPU/memory/disk) to consume "all the logs"; 2) you won't be able to find what you need.
I think both are a failure of the tools in the space.
I know how we get here, people simply report the error from the OS w/out adding context. This is why I love anyhow reporting in Rust, you can attach context (like the file name and path) to the error.
In log-store.com I report the default name of the config file (you can specify it via cmdline if you want), and the 3 locations and order searched, if the config file isn't found. I also have it report the file being used, so if you expected the file in /etc, but you accidentally had one in your home directory, you'll know on startup.
These things seem like table-stakes in 2023.
Also in the end, unsure of what the actual results are. Maybe I missed clicking on something.
Is Google really in a bad position? Microsoft? Others who are doing layoffs? Or can they do them, bring down expenses, and juice the stock price under the cover of "everyone is doing it"? I don't know, but it is a bit head-scratching (to me at least) that profitable companies would be doing double-digit percentage layoffs
I think that's your answer... Show them your existing front-end code, and ask them how they'd make it better. If they're experienced, then they should have some very concrete ideas. Then ask them "why" for their ideas. If they can't fully explain the "why" behind the "what" they're probably just regurgitating things they've read, but don't actually understand the tech.
I'm not sure layoffs prevent this
I would think you'd need to identify your target customer. Build a profile of them. What do they like to read? How do they find new products? Is there a magazine (old skool) or trade show or are they government customers or universities. Then copy how others are marketing to them.
Full disclosure, I work with Tom at Datto.
Slides: https://drive.google.com/file/d/0B5hUzsxe4cdmU3ZTRXNxa2JIaDQ...
Video: https://youtu.be/frnLiXclAMo
[1] https://www.3floyds.com/beer/alpha-king/?age_verification=e7...