schizo @ schizo @forum.uncomfortable.business

Posts

11

Comments

1,437

Joined

1 yr. ago

It more sounds like the mod won't work on the most current version of FO4, and because you can't install older versions on Epic, it won't work.

That's a shockingly misleading title, even for vidya game "journalism".

Eh, I'd be fine with them taking however long they need to release a fully complete and working game, rather than shove out a half-baked one.

See: 2077 at release vs 2077 patch 2.0

It probably is intended to indicate that Google's software doesn't have a notice anywhere it's sending this data that a normal human could reasonably find.

There's a lot of 'Data we collect' stuff on sites and software now, and I'm entirely sure I've never seen this on any browser using Google's code for this.

In fairness the motherboard not restricting power usage isn't a bad thing: it's not like it's shoving 4000w through the cpu, it's just letting the cpu pull as much as it wants which, with a non-defective piece of silicon, is probably fine.

A modern CPU shouldn't pull enough power that it kills itself, unless there's a major failure in design or manufacturing.

Sure, the CPU gets hotter with more power and sure, the last 5% of performance is a third of the total power usage and probably not worth chasing, but them's the design decisions x86 vendors are making right now and the motherboard (assuming it can deliver enough clean power) shrugging and saying 'whatever' is, outside factors aside, fine.

Also, that 253w TDP limit on a i7 or i9 is a bit low. Yes Intel's spec says that, but intel lies like crazy on power usage, and pretty much always has. These are chips that will happily gain performance up to about 400w of total draw, so capping at half that is a bit of a kneecapping, though it MIGHT keep them from failing as fast, but who knows.

I'd argue the opposite: it's made it where I care very little about the dependencies of anything I'm running and it's LESS of a delicate balancing act.

I don't care what version of postgres or php or nginx or mysql or rust or node or python or whatever a given app needs, because it's in the container or stack and doesn't impact anything else running on the system.

All that matters at that point is 'does the stack work' and you then don't need to spend any time thinking about dependencies or interactions.

I also treat EACH stack as it's own thing: if it needs a database, I stand one up. If it needs some nosql it gets it's own.

Makes maintenance of and upgrades to everything super simple, since each of the ~30 stacks with ~120 containers I'm running doesn't in any way impact, screw with, or have dependency issues that impact anything else I'm running.

Though, in fairness, if you're only running two or three things, then I could see how the management of the docker layer MIGHT be more time than management of the applications.

The Cloudflare certs CN are yourdomain.com and *.yourdomain.com, so enumeration via that means is not really going to lead anywhere.

Cloudflare is resistant to, but not totally immune from, DNS enumeration. But, frankly, the attack profile you're concerned about isn't likely to have the resources to do proper enumeration: automated bots are going to guess a static list of hosts, not spend time trying to scrape data out of DNS.

TLDR: don't use common service names, don't use common activity (don't use jellyfin. or movies. or media. or tv. and so forth) and make sure your host responds with something aggressively fuck-off for non-matched requests. For nginx, the default_server site configuration I'm using sends what's likely real humans to a rickroll, and everybot else gets a 444 which is nginx for go fuck yourself.

Want to add s-tui to the list of useful power monitoring tools, as well. It's not really focused on 'changes' so much as just presenting pretty graphs and power monitoring.

Wake-on-LAN is probably what you want, if your specific hardware supports it which it probably does. This is a case of figuring out your exact hardware and a little RTFM-ing about how to enable and use WOL.

As for the drives it, in theory, would add more load/unload cycles to them and thus reduce their lifespan. But, in the real world, that almost certainly doesn't matter, unless you're turning the system on and off every 5 minutes: modern drives expect to go in and out of power saving modes and most controllers (especially usb enclosures!) do this pretty aggressively, so a couple more load cycles more-or-less are unlikely to actually cause your drive to fail any quicker than it would anyways.

Classic Marathon is also free: https://store.steampowered.com/app/2398450/Classic_Marathon/

It's pair of 16gb 6000mt/s sticks that i just run at stock 4800mt, primarily because the BIOS fails to post every 3rd or so time, shits itself, and resets to defaults. I've quit fucking with it because, frankly, it's fast enough and going into the bios requires a 2nd reboot and memory retrain, which will fail 50% of the time, and lead to the bios resetting itself, which leads to needing to reconfigure it which....

When the system is up, it's perfectly stable, and stays fine through sleep states and whatever else until I have to reboot it for whatever reason (updates, mostly).

But honestly, if the memory controller can't handle dual-channel 4800mt/s ram, then it's really really fucked, because that's the bare minimum in terms of support.

I'd also add I have 3 mobile AMD based devices with DDR5, none of which exhibit ANY of this nonsense. Makes me think their desktop platform may well be legitimately defective, given how many people have this issue, and how it doesn't seem to be universal across even their own product stacks.

(And, yes, two of the mobile devices have removable ram, so it's not some soldered vs dimm thing)

What's really gross is the amount of money we're talking about here isn't even the loose change you'd find between the cushions on the congressional couch.

It's a shockingly paltry amount of money they're refusing to pay out, as they should.

The last generation has been a total mess for both Intel and AMD.

AMD had motherboards frying CPUs, crazy stupid post issues due to DDR5 memory training (and my personal build fails to post like 25% of the time due to this exact same stupid shit), and just generally less than a totally reliable experience compared to previous gens.

Intel has much the same set of problems on their 13/14th gen stuff: dead chips, memory training issues, instability.

Wonder if it's just a fluke that both x86 vendors are having a shitty generation at the same time, or if something else is at play.

Coming soon to Costco: 10 packs of 5090s.

Back in the super early era of computers, they were stupidly expensive. One solution was to hook up a lot of people to a single computer via a computer terminal, which were much cheaper.

Basically it would allow you to deploy a ton of monitors and keyboards to access a single computer relatively cheaply, and UNIX was the OS that (mostly) was used for this.

You noticed that your console session is called 'TTY-a-number'. Well, TTY stands for 'teletypewriter' which was the very first incarnation of this, and was what was in use when the name of the console was a made, and it's just... never been changed, though tty devices and their later serial consoles are quite dead as far as tech goes.

Enabling a serial terminal in Linux is a one-line change, and you can then use any terminal emulator you'd want to connect over it, but eh, it's a pretty dead technology and nobody uses that at this point.

Since I seem to be dumping useless retro facts all over the place: you could do this with DOS, and Digital Research released Concurrent DOS to allow multi-tasking, multi-user access to a DOS system. If you wanted to fiddle with that in the modern era, you'd want the Novell Multiuser DOS rebrand, since it supports vt100 emulation and thus can be used with basically any serial terminal app unlike the previous versions which emulated specific HP and IBM serial terminals.

Here's some useless retro crap: the 8" disks almost certainly cost more.

There was absolutely a reliability scale as you moved down the physical disk size: the 8 inch disks were more reliable than the 5.25, which were more reliable than the 3.5, due in large part to the market was requiring them to get cheaper as the drive tech matured, and thus you ended up with cheaper, less reliable media as you went along through the evolution.

40 years later, 8" disks nearly all read, 5.25" disks mostly all read, and 3.5" disks are an absolute crapshoot: I find that less than half of the ones I come across are still actually accessible, compared to about 90% of the 5.25" and 8" ones.

That experience of course has some personal bias, but that's a story that holds pretty true talking to anyone who tries to archive old floppies, so it's probably reasonable enough to use for actual data.

So, if you wanted the most reliable option, and since the military probably doesn't care what it costs, you'd pick a 8" disk.

I mean, real person isn't the bar I'd call 'minimum', a helpful real person is.

It sounds like they met one of those two, but the difference between an AI who can't help you and a real human who can't help you is pretty small: you still don't get what you're after either way.

I read this thinking you meant you wanted to only use a serial terminal, which sounds like a really neat project: they're cool hardware and would certainly be a unique way to interact with modern computing.

But uh, yeah no that's probably not what you meant and I've spent WAY too much time dealing with retro stuff lately.

Yes those are all lovely fancy numbers, but the only ones I really give a shit about come after the $, and the one that comes before the W on the power supply requirements.

Ah yes, the Lightning to 3.5 dongle. Which I've had to buy like 6 of because I keep losing the stupid thing.

You'd almost think that was the point, but

Introducing Apple Intelligence Genius. Now you can get technical support from the comfort of your home. We think you're going to love it.

(It does nothing but tell you to reset your pram and turn it off and on again.)