winocm

Honestly, me too.

Honestly, I agree.

I just can’t bring myself to trust an organization that allows these types of underhanded things to happen in the first place. The fact that this behavior even got to customers raises a lot of red flags for me.

https://www.theregister.com/systems/2026/06/25/micron-locks-...

:(

On the note of PG&E, my electric bill averages to about $750 despite only running an air conditioner, several device chargers, a router, some lights and a fridge...

Thanks PG&E.

Don't forget the word "epic" (in terms of the literary definition).

Perhaps I am the odd one out here, but a small part of me wants to see what happens when you run a proprietary SOTA model on a laptop.

https://halupedia.com/2048-united-states-presidential-electi...

Amazing.

"AI can make mistakes, so double-check responses."

That just ended up inadvertently reminding me, Windows Vista is actually almost old enough to be at the minimum legal drinking age in the US.

Windows 8 is nearly a decade and a half old as well.

Time really does fly.

This almost sounds like The Monkey's Paw by Jacobs.

Kinda sorts. The systems that the "MacOS on CHRP" thing ran on had a very strange looking device tree, with some bizarre combination of PC and Mac peripherals.

  Apple Cobra Open Firmware CHRP 1.1 B3 built on 08/18/97 at 13:04:24
  Copyright Apple Computer 1994,1996,1997
  Copyright IBM Corporation 1996
  All rights reserved.
   ok
  0 > dev / ls 
  ff82ec18: /cpus
  ff82ee08:   /PowerPC,604e@0
  ff82f600: /chosen
  ff82f750: /memory@0
  ff82f8d8: /memory-controller@fec00000
  ff82f9d8: /openprom
  ff82fab8: /rom@ff000000
  ff82ff48:   /boot-rom@fff00000
  ff830060: /options
  ff830828: /aliases
  ff830c78: /packages
  ff830d00:   /deblocker
  ff8314c8:   /disk-label
  ff832090:   /obp-tftp
  ff835db8:   /mac-parts
  ff836578:   /mac-files
  ff837de0:   /fat-files
  ff839700:   /iso-9660-files
  ff83a148:   /bootinfo-loader
  ff83b7d0:   /xcoff-loader
  ff83c060:   /pe-loader
  ff83c7d0:   /elf-loader
  ff83da18:   /terminal-emulator
  ff83dab0: /rtas
  ff83dc70: /pci@80000000
  ff83ff38:   /isa@b
  ff8414e0:     /nvram@i74
  ff841ad0:     /rtc@i70
  ff842500:     /parallel@i378
  ff842988:     /serial@i3f8
  ff843020:     /serial@i2f8
  ff8436b8:     /sound@i534
  ff850288:     /8042@i60
  ff8515f8:       /keyboard@0
  ff854b88:       /mouse@1
  ff8554c0:     /fdc@i3f0
  ff858730:       /disk@1
  ff85bac0:     /op-panel@i808
  ff85bba0:     /pwr-mgmt@i82a
  ff85bed8:     /timer@i40
  ff85c070:     /interrupt-controller@i20
  ff85c250:     /dma-controller@i0
  ff85c738:   /pci-ide@b,1
  ff85d028:     /ide@0
  ff85db78:     /ide@1
  ff85e6c8:       /cdrom@0
  ff862e60:   /mac-io@d
  ff863468:     /scsi@10000
  ff865298:       /disk
  ff8660c8:       /tape
  ff8671b8:     /adb@11000
  ff867cb0:       /keyboard@2
  ff8685a0:       /mouse@3
  ff8687c0:     /escc-legacy@12000
  ff8689b8:       /ch-a@12002
  ff868b08:       /ch-b@12000
  ff868c58:     /escc@13000
  ff868e40:       /ch-a@13020
  ff869500:       /ch-b@13000
  ff869bc0:     /via@16000
  ff869cb0:     /interrupt-controller@40000
  ff869e70:   /cirrus@e
  ff86e2c8:   /pci1022,2000@f
   ok
  0 >

The Motorola Yellowknife board seems remarkably similar to this system, as well as the IBM Long Trail system (albeit with Long Trail using a VLSI Golden Gate versus a MPC106 memory controller). Both of them use W83C553 southbridges and PC87307 Super I/O controllers.

The architecture is kind of weird, but the schematics on NXP's website can probably elucidate a bit more on the system's design.

Mildly related, sort of, one can prevent expansion of variadic macros as follows:

   #define printf(...)

   int (printf)(const char *, ...);

You also get "Program Files (ARM)" (including a complementary "SysArm32") on older arm64 systems too.

If you want to download SARS-CoV-2, here you go: https://www.ncbi.nlm.nih.gov/nuccore/NC_045512.2

The latter is known as a "twiddle" in BSD land.

(c.f: https://ftp.netbsd.org/pub/NetBSD/NetBSD-release-10/src/sys/...)

At least since maybe the DEC Alpha 21264. It could address 48-bits of VA space, but that comes with caveats due to PALcode specific intricacies.

I think VMS (or was it Tru64?) uses this mode, but many other OSes just use 43-bit or 40-bit addressing. Realistically though, I don’t think many users would be using workloads that addressed more than 38-bits worth of contiguous VA space in 1998-1999.

LLVM SPIR-V's backend is a bit... questionable when it comes to code generation.

Don't forget the infamous pattern used in some C projects too:

  struct foo decl = {
    .member = /* ... */
    .next = &(struct nested_pointer) {
        .nested_member = /* ... */,
    },
    .array = (struct nested_array[]) {
      [0] = { /* ... */ },
    }
  };

Consider this implementation:

https://llvm.org/doxygen/STLFunctionalExtras_8h_source.html

Kind of. NIR is more oriented towards lowering and optimizing code for driver backends, as far as I know. SPIR-V is targeted towards the other end of the spectrum.

Sounds about right.

VMS is the only OS (that I know of) that uses all 4 processor privilege modes.

Side note: The 21064 has such bizarre IPR mappings, the read values have lots of bits scrambled around compared to their write counterparts. This is likely a hardware design decision affecting the programmer's model, if I had to guess.

The Alpha architecture was 64-bit from the very beginning (though the amount of addressable virtual memory and physical memory depends on the processor implementation).

I think it goes something like:

  - 2106x/EV4: 34-bit physical, 43-bit virtual
  - 21164/EV5: 40-bit physical, 43-bit virtual
  - 21264/EV6: 44-bit physical, 48-bit virtual

The 21364/EV7 likely has the same characteristics as EV6, but the hardware reference manual seems to have been lost to time...

You’re not alone. I do the same, but often I keep the text editor in dark mode but the rest of the system on light mode to help provide contrast.

My condolences.

I had SIRS/sepsis once and it really is a harrowing experience. It really changed me forever and as a bonus, if not to add insult to injury, my hair now falls out and barely grows. Wouldn't wish it on my worst enemy.

Don't forget F77 codebases too.

Complete anecdote, but my personal life experience is that offices only cause me to get more easily distracted and forget what I'm doing (which costs me time and productivity), whereas at home I can actually concentrate and not lose track of my own mental models, leading to better results.

It's kind of sadly become necessary after having some traumatic brain injury, since I wasn't quite like this a decade ago.

It really depends on what you're doing and what dynamics the task at hand requires.

Off topic but tangentially related, here’s a fun fact, DEC Alpha actually ends up transparently converting IEEE single precision floats (S-float) to double precision floats (T-float, or register format) when performing registers loads and operations.

Ah, my favorite instructions, 'hw_ldl/l', 'hw_stl/c', 'ldl_l', 'stl_c' and their quadword siblings.

I guess the biggest difference is that Coldfire parts are still being produced (c.f: MCF52256CVN66).

I'm not sure if Alphas are even being made anymore, even 15-20 years ago.

To be fair, anything that does not support BWX is really painful to deal with.

Take, for example, an 8-bit/byte store. Without BWX the sequence would be something like:

        bic     a0, #3, t1
        and     a0, #3, t4
        ldl     t2, (t1)
        insbl   a1, t4, t3
        mskbl   t2, t4, t2
        bis     t2, t3, t2
        stl     t2, (t1)
        ret     zero, (ra)

        stb     a1, 0(a0)
        ret     zero, (ra)