leeter

I recall awhile back Linus Tech Tips pointed out that the primary failure point for old machines wasn't the CPUs which tend to be piling up cheaply (I can't say how true this is for pre PIII parts) but instead the motherboards.

I wonder if in some sense there isn't a market for someone to just make new motherboards instead for this stuff using modern parts. I realize there are some licensing issues after a certain point, but in theory everything up to a PIII should be doable. Particularly since memory controllers are in the chipset there are options to use things like modern ram chips and then 'downgrade' performance to be compatible in the chipset. This could also be used to allow for modern M.2 SATA drives to be run in IDE emulation mode locally or even have SD/CF options directly on the board.

The main downside at that point is space of course, hardware always takes up more space than an emulator ;)

IANAL, but no. You can still get sued.

IANAL, the risk is generally not in the downloading per-se but the distribution and use. The copyright owner can sue for use or distribution of the IP. So you might be able to download and look but that would then basically prohibit you from making your own compatible QBasic interpreter. You're better off clean rooming it generally speaking. So it's basically poisoned, you can look but as soon as you do you can't touch anything to do with that area again until you can plausibly say you forgot everything you saw.

Honestly? Having written software for both Win32 is actually pretty nice to work in. Better in many ways than the alternatives. Most of the things Raymond goes on about are weird quirks you can ignore for the most part. Whereas there are some very serious hazards running around POSIX if you're not careful that can bite hard. Glares at signals

I much prefer the EVENT based system Win32 goes with. You can just suspend on the event and not worry about it. The kernel will wake you up when it matters. Also MS seems to have very serious API design rules that help keep usage patterns consistent, which is important in making sure things aren't accidentally misused.

NGL... that inspired my comment XD

Which they explicitly prohibit, in fact if you look at how they design the APIs they'll deliberately add reserved members to ensure they hold the space so that it's much harder to break.

This forgets MS:

MS: "Let's design it so either it never breaks or if we can't avoid that we'll just add a FooEx or Foo2 method call"

This is why so many Win32 methods take structs that have a size parameter that must be filled in. That acts as a version parameter. That's not to say they haven't had ABI fun moments... glares at COM.

Good to know I was looking in the wrong spot, I was looking for what looked like the most likely header other parts of the code would be using.

I can't find support for those flags outside of two files, I'm 90% sure the kernel requires CMPXCHG8B which isn't supported on 486 iirc

It does... and doing a quick search of the kernel source it's not actually used for anything I can't find it referenced outside of itself. There is FPU emulation for m68K that is, but x87 is not.

Me: "Surely the Linux Kernel has build options for x86 that includes no-FPU"

20 minutes later: "Oh right they removed i386 as a target because it sucked and wasn't maintained that includes i486... so now you'd have to target a Pentium or higher"

But seriously the Linux kernel does support not having an FPU... just not on x86 as best I can tell.

I was more disappointed they didn't seem to have a "Make MIDI" option; or if they did I missed it.

I seem to recall Chef Achatz actually talking about food as an emotional experience given his own trials with cancer and actually losing his ability to taste for awhile. I can't find the interview (or it might have been Chef's table) but I'm pretty sure that informs the style of Alinea.

Nice didn't know this existed!

Honestly I was thinking similar but not exactly the same. More something with a VT-d memory map/port map so that the DOS application could potentially directly interface with legacy hardware without interfering or making the PIF incompatible. This has applications particularly in factories where they still use ISA interface cards with tooling etc. At the same time it would allow setting things like EGA/CGA compatibility requirements. Could you do it in the PIF? Probably, but I'd rather not risk breaking compatibility if possible. It's an idea only and would require research anyway assuming I actually had the time and energy to implement.

You can absolutely leave long mode once entered; it's just annoying and silly. In fact one of the plausible options for running a DOS on UEFI would be downgrading the mode to 'unreal' mode. But you'd still have to put BIOS replacement code in memory to manage that part.

However the better option IMO is to allow the DOS kernel to just virtualize the applications using the virtualization extensions on almost all modern CPUs. Then you could do something like adding an emu.ini file next to the exe/com that sets things like memory and emulated hardware settings.

Furthermore virtual machine BIOS code already exists for things like qemu etc. so there is a place to start on that too.

Appears so?

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux...

not sure that's used for /dev/random/ but I thought it was, but the question is when because early in the boot process that may not be loaded. There was also a general distrust of vendor specific hardware randoms in the past IIRC.

It is, was, they were warned and launched anyway. I assume they calculated they could get through it and didn't. Live and learn. My guess is this was in budget an 'acceptable losses' to the constellation.

Fun site to track this stuff: https://www.spaceweather.com/

There are actually genetic reasons that some percentage of the population tastes both common artificial sweeteners as bitter

https://academic.oup.com/chemse/article/38/5/379/360864?logi...

It's related to why some people taste Cilantro as soap too.

Oh it's still a thing from hardware companies, I recently had to warn a dev away from using a lib by ST because it didn't have a license and it created legal vuln they might have to deal with down the line. While that would have been fine in a hack project; in a commercial product (what they were working on) that was unacceptable. Hardware companies rarely understand or care about the software side of things and it makes for all sorts of fun in places like the Linux kernel where they actually have to make that fun do what the end user actually expects.

You're misunderstanding. I was responding to the idea that simply shutting of the mains will protect from burst pipes. It wouldn't; all it would do is trap the water inside the existing pipes with no outlet. Completely draining (and potentially backfilling antifreeze into sumps) will protect pipes however but that was not what was being suggested by my reading. That said homeowners in this sort of situation may not have pipes built to completely drain anyway; nor would they necessarily want to as that would have a negative impact on sanitation.

> I can just run a bucket of water then shut off the main to make sure the pipes don't burst.

Don't do this... please don't do this. Just set all your taps (internal and external) to drip slowly. That's all you need to do. Shutting off the main could actually make it worse because it creates an area without expansion.

> So what would I do to "winterize"?

Consider putting in more insulation in your attic, R30 should do it. It will help with energy bills in the summer too. Fixing walls is nice but not worth it unless you're doing a whole house reno.

Also next time you get your AC replaced, consider swapping it for a unit that also functions as a heat pump. Get one rated to 5-10F, that means it will be within rated efficiency range until that point. It will still function and operate below that but will be more like the electric heat you have now below that. But still generally more efficient overall. That reduces load, less load overall means less chance of things going out. It may seem small but those two things can have an effect.

This too, we're a technical consultancy (DevOps) so we get the gamut of reactions from "You're on my turf" to "Finally someone that my boss will listen to". Getting the former early on severely hurts your chances of success sadly.

Edited for spelling

This 100%, I've literally been hired onto a client to basically tell management something their internal team had been saying for ages. The challenge wasn't telling management that; but rather getting them to (politically very carefully) open their eyes to the fact they had the solution (and the people to implement) right in front of them the entire time. That was a very tricky situation as the management didn't trust their team at all. So most of our time was spent untangling that and doing a little implementation.

I also did this (around ~2008), a friend of mine and I built near identical Atom boxes with first gen (Diamondville) 64bit atoms on Intel motherboards running 865 chipsets IIRC. The GPU/Chipset was louder than the CPU because the CPU was completely passive. I did emerge Xorg on that... it took I think a day and a half(ish) even optimizing the heck out of compile options to use everything march=native... it was slow as heck. But it lasted me for years as a little project box until I replaced it with an 4th gen i5.

You really do start to ask yourself if you need a package if compiling it will take a day or two. Hence OpenOffice never got installed.

For games generally those parts can be shifted to the GPU because they feed the rendering pipeline anyway. Doing so has other benefits of lowering latency for that data to be picked up by the graphics bits already there etc. Also the clock speed penalty for AVX512 is pretty steep so unless you're going to do a lot of AVX512 it really doesn't make sense either. Games generally aren't using double precision either which is the AVX512 bread and butter. To make it more fun even if they were... a 4x4 matrix is composed of 256bit elements so the vast majority of register usage wouldn't be 512 bit anyway. The main benefit would be the new instructions more than the register width.

Long story short: Games generally aren't doing enough AVX to really benefit from it as implemented. They can be quite bursty in their use. Not to mention that Not every CPU even has AVX (because apparently Pentium Gold is a thing) even today.

If Intel convinced AMD to pick up the 256 bit versions and removed the clock speed penalties I could see them getting more use. But at the moment it's really just a feature for the HFT market primarily and even they are extremely careful in use because of the clock speed penalty. To the point they will literally benchmark both ways to make sure the penalty is overcome by the throughput.

Other than BIOS/UEFI as far as I know nothing is stopping them from using existing chipsets/motherboards. I don't recall anything on the chipset itself being inherently tied to x86 per se. I think even port IO is handled in the SOC/microcode these days. So they could probably do it. Particularly if they reused things like the AMD IO die etc. No need to reinvent the wheel because the cores are different.

Someone needs the courage to make a motherboard and CPU with off the shelf parts and a socketed chip in the non-x86 space. That was one of the key reasons that the IBM PC succeeded: it was easy to clone. Without that it's likely it would have been just another interesting footnote in history. But because IBM didn't take the time to do everything custom and locked in others were able to enter the market and make things happen. Honestly I don't think anyone sells socketed ARM64 or RISC-V chips. There might be OpenPOWER but I don't think anyone is really fabbing them at a cost that a consumer could even consider.

Sadly I don't think that sort of courage is in copious supply it's always easier to vendor lock people than it is to take the risk of someone else eating your lunch. So until that happens I just don't see non-x86 platforms really eating into the desktop/laptop market in any large share.

They are also incredibly tolerant to current/voltage spikes because they are purely resistive, which makes them ideal for situations when power could be 'interesting' as they will still function unless they are run well beyond normal limits. So when it's more important that it just works, it's not a bad design.

Also soldering them would be least of the cost concerns for the shuttle program, which had much bigger and nastier cost centers.

I'd say it was extremely intentional given this:

https://lwn.net/ml/linux-api/20180905165436.GA25206@kroah.co...

And that's for a userspace header.