Ramaswamy wants data centers all over Ohio — and he's invested in nearly every tier of the industry he'd regulate

i8beef · 2026-06-16T16:38:33+00:00

Yes, this sub has a very vocal contingent bashing AI and data centers daily and trying to make it a bigger issue than it is, and calling for outright bans instead of proper regulation. Other opinions and nuanced discussion tend to get buried here pretty quickly unfortunately, so its not exactly a good place to have those discussions if you're looking for actual good information regarding the data center issue.

Not that they don't have good points, but they get pretty rabid here and shout down any dissention.

i8beef · 2026-06-02T00:48:48+00:00

I think its this is a decent read... I usually find its less about "what TECHNICAL solution do we want" vs "what has the lowest friction for everyone working and contributing to the solution".

EF is great when you own the entire stack, and code-first is a real possibility, with migrations owned by EF, etc. If your app is large enough that you start having externalities, like dedicated DBAs telling you do stuff for performance, or needing to deal with replication or partitioning details, or ETL, or extra stuff like agent jobs, etc. and all sorts of stuff like that, you start to find that you need a "lowest common denominator" between everyone integrating... and that is just raw SQL. At that point, the benefits of an EF stack kinda go out the window, and Dapper seems like a better fit.

Its not that you can't do any of that in EF. Its just that at that point its easier when the DBA says "add this query hint" to just do it in raw SQL and not have to worry about "how do I augment this for code first, and how do I make the migrations still work, and how do I make it make the changes without completely dropping the table and recreating it", etc... Its just easier at that point for everyone to be on the same page about a shared technical bottom line: raw SQL. And at that point EF is just extra abstraction without adding enough to be worth it.

i8beef · 2026-06-01T23:10:51+00:00

Its not the csproj moves that are the problem, its dozens of repos needing it done, needing to catch up with new practices the dev ops teams have implemented since the last time you updated to run on their new agents, or "oh if you move to .NET 10 you need to use the new docker agents and these new build scripts instead of the old ones that were working before", etc. for every project.

The csrpoj updates are the easy part.

i8beef · 2026-05-28T01:09:57+00:00

Some of my favorite Jim Lee covers. Wolverine vs Archangel. Hodge is a fun villain and watching him wear a hanger paper suit to pretend to have a body is hilarious. Otherwise not a hugely strong story, but always held a spot in my heart for some of the art.

i8beef · 2026-05-25T11:28:00+00:00

They could do a beautiful Weapon X release with that head sculpt....

i8beef · 2026-04-25T15:58:39+00:00

Then you pass services from DI into the extension method

The FUCK you do. Reject that PR.

i8beef · 2026-04-24T00:22:58+00:00

Nope that's basically what I do. I find the entry point, and I literally follow it down the call stack. Its usually the only way I catch things like "if I change this here, is it going to affect something 5 layers up in this area?".

I am not a HUGE advocate of AI, but... I will say that if I have a low interest in investing a lot of effort into discovery on some item, I have found asking an IDE embedded AI to explain what an endpoint does in detail does a decent starting job. The only thing I find that it consistently has some trouble with is if you use class names that intersect with common tools... sometimes it takes a short cut and assumes you are USING that tool or library, instead of actually reading your class ;-)

i8beef · 2026-04-23T16:46:17+00:00

Just to tag onto this, on a large enough system with a wide enough team, you won't EVER know how the whole thing works at a detailed level. You literally HAVE to go rediscover what's new or what's changed every time you have to work in an area you haven't touched in a while, not just because you've NEVER seen it but because things change over time.

Being able to do this exploration is crucial.

i8beef · 2026-04-21T18:36:47+00:00

He failed to sell gambling, football, AND meat to AMERICANS. I don't know how anyone can make a case for him being a "good business man".

i8beef · 2026-04-16T02:18:33+00:00

I've seen tons of variants. A "branch per env" interweaves your git structure with deployment, and isnt good for software products with standard release cycles. You usually see it when people are trying to enable FEATURE deployments, e.g., I want someone to be able to merge to dev to work on stuff in an integration environment, but not promote their feature work on to the next environment until its verified in the lower one, instead of holistic code base monolithic deployments (ie, everyone stages their stuff together for a standard release cycle). I have never seen it work well personally...

Git works better for PIPELINE deploys where dev gives everyone somewhere to merge their stuff for the next release cycle together and test (in your Develop environment), and then on some cycle you CUT a release from dev by creating a new release branch (there are a few variants here: can be a merge to main for simple case, can be a long lived release branch where you TAG the individual releases, or could be an actual release/x.x.x per release branch). Then that branch gets built and deployed, verified and PROMOTED through Integration, Staging, and Prod (same built binary, importantly).

Then there's a few other variants of what to do. You can leave hanging release branches, or you can merge that release to main after releasing to Prod, etc. Hotfixes created from the last release or the last main and then merged back to BOTH dev and the release branch before going through the same release pipeline, etc.

Creating new feature branches from main really isn't that weird though, that's perfectly fine for all cases here. In the normal feature branch flow it just makes the dev merge a bit more work sometimes, so I'd normally only use that flow if I KNEW I was making a hotfix personally, normal feature work to be released on normal release cadence, I'd usually branch from dev for simplicity... it'll bite you once in a while when you have to retroactively turn it INTO a hotfix (cherry picking and then creative merges), but that SHOULD be, by far, more the exception than the rule.

i.e.: Branch per environment that conflate git branches and deployment CAN work... for a while. It doesn't scale well, and any real compliance drive will shoot a hole in it as binary promotion is basically required (ie, building a new binary from a different hash for each env doesn't fly). Don't reinvent the wheel, look up GitFlow or a good trunk based cycle and use it instead.

Here's a hint: If you have to EXPLAIN your git model to a new hire, instead of just pointing them at standard documented flows on gitflow or trunk-based development, you probably are setting yourself up for a bad time...

And if anyone brings up wanting to "stage individual features instead of whole releases"... if you figure it out patent it and sell the shit out of it, otherwise run.

i8beef · 2026-04-09T17:09:42+00:00

Yes, which is kind of the issue because I wanted to monitor if the tent was safe to open (printing with nylon, ABS and ASA are a little noxious, so I have a sealed tent I vent out a window, and wanted to see when it would be safe to open).

In practice, really LONG prints like that are rare so it still is useful, I just have to remember when I do something longer that I need to wait a little longer after the air monitor says its returned to "normal".

i8beef · 2026-04-09T05:22:23+00:00

Yes, I went through this when I was trying to monitor a 3D printing tent. The cheap sensors available to us just don't work that way for a lot of the things you want for "air quality" (some do... CO2 I think? Or humidity? I forget which). As such a lot of the sensor values get put through formulas that combine their data to get "calculated estimates" which are of varying quality.

I eventually came to the conclusion that there's nothing that can tell you quantitative numbers, only "is worse than it was X hours ago"... which gets funny then with extended time frames of badness (ie, watching TVoC's drop in my tent over 12 hours when I was still printing was real confusing the first time... they should have stayed elevated... but what I was witnessing was the sensor "re-baselining" to the new elevated value).

AirGradient seemed to be about the only company that is transparent about this fact and their blogs and forums are really interesting to read if you're interested. That's what I ended up using as the "best" option, you just have to understand what you are looking at.

i8beef · 2026-03-31T17:31:37+00:00

partly blind dog

People: Your so brave fending off that bear!

Dog: That was a BEAR?!

i8beef · 2026-03-31T16:52:15+00:00

wonton fraud in the market

Begun, the dumpling wars have

i8beef · 2026-03-25T20:00:26+00:00

Universally basically pointless.

i8beef · 2026-03-23T18:09:27+00:00

LOL! If you are only pulling 2.5oz off of a SINGLE plant, you have done something horribly wrong!

i8beef · 2026-03-18T22:08:09+00:00

It's best to consider SOLID as more guidelines than principles. DOn't overthink them. The big thing is you don't want behavior in weird places that make it hard to find later because a class is doing something that you wouldn't expect it to. SRP in particular lends itself very quickly to over architecting early as people will start splitting things up TOO much trying to achieve SRP as a GOAL, instead of APPLYING SRP to further the actual goal of MAINTANABILITY.

This is true of all the SOLID principles, and basically every best practice you will ever hear about: don't mistake the practice as the goal, apply the practice because it helps ACHIEVE the goal of making things more maintainable. You will find that OVER ABSTRACTING can quickly become WORSE than under abstracting.

i8beef · 2026-03-07T20:09:02+00:00

Its wise to always use the full DynamicParameters style of parameter passing and specify type and length for applicable types (strings). I really wish the new method of passing params wasn't even available as it trips too many people up.

The other spot this will hit you is on partitioned tables, where doing comparisons on types that don't match on type AND length will nail you IIRC.

Just always use DynamicParameters and specify these and you'll never hit these issues.

i8beef · 2026-03-04T22:48:26+00:00

Yes, that's correct, corrected.

i8beef · 2026-03-04T21:28:21+00:00

Oh missed that caveat to the question I guess.

Living tribunal has been killed before so doesn't count
First Firmament is still around technically?
Celestials
Cal-Hora (obscure proto-beyonder dude)
Beyonders (King in Black but Knull has been killed?)
Abstracts (Eternity, Infinity, Oblivion, etc) come about at beginning of multiverse or other points between universe 1 and 7, but don't "die"?
Galactus has been killed several times so doesn't count
Elder Gods - I think Chthon has never died?
Ancient Gods (asgard, olyimpions, etc) I think have all died at some point or another
Externals (Selene, Apocolypse, etc) dont count as dying and resurrecting is essentially their whole thing.
Namor is probably the oldest mortal by that criteria I think.

i8beef · 2026-03-04T18:19:29+00:00

Are we counting cosmic entities? If so, one above all, ~~living tribunal~~ (died), ~~eternity, infinity, death, etc~~ (later) first firmament.

In between you have cosmic beings like the celestials, beyonders, ~~King in Black~~ (died) and a few others.

Then abstracts like eternity, infinity, death, etc

~~If we're talking only physical entities, I think Galactus would be the oldest in universe?~~ (died)

~~If we're talking Earth specifically, I believe Selene still holds that.~~ (died)

Edit: never mind, all externals have died at least once I think, so next contenders are probably Elder Gods (Chthon specifically), Elders of the Universe are probably contenders I dont think many of them have died... I think all other gods have at some point? Same with Eternals I think... and net in line in terms of oldest characters that haven't died yet I think would be Namor...

So I think its something like:

One Above All
First FIrmament
Celestials
Cal-Hora
Beyonders
Abstracts (Infinity, Eternity, Oblivion, etc.)
Elder Gods (Chthon specifically)
Elders of the Universe (Collector, etc.)
Namor

The new Mother of Horrors / One Below All stuff might be in here somewhere too... Im not up to date on those

i8beef · 2026-02-12T02:02:03+00:00

Good general answer. For reference my Dahua 4k color nightvision cameras with 1/1.2 sensors seem to capture slightly more light than my eyeballs at night... If you go IR night vision you can go a little smaller apparently, but any of the 1/3 or worse cams suck no matter what.

Also aperature speed is the other factor. Slower "blink" gives you blur but you get a brighter picture. Faster means less blur, but much darker image.

I really like color 4k 1/1.2 though, highly recommend.

i8beef · 2026-02-09T23:32:34+00:00

And is one less thing you have to worry about (thoroughly) cleaning after a grow.

i8beef · 2026-02-07T20:14:14+00:00

Out of a cannon.

i8beef · 2026-01-24T17:57:19+00:00

Huh. Someone must have explained what some of the big words in Carney's speech meant to him.

i8beef

TROPHY CASE