#ifdef MGBALOG
  #define mgbalog(level, format, ...) \
      do { _mgbalog(level, format, ##__VA_ARGS__); } while (0)
  #else
  #define mgbalog(level, format, ...) \
      do { } while (0)
  #endif

The reason I prefer the "do { } while (0)" form is that it keeps the macro structurally equivalent to a single statement in both debug and release builds. With the empty disabled macro, this:

  if (failed)
      mgbalog(ERROR, "failed");

  if (failed)
      ;

It also means the enabled case is already set up correctly if the macro later grows beyond a single function call. For example, if you later add another statement to the macro:

  #define LOG(x) printf("log\n"); printf("%s\n", x)

  if (failed)
      LOG("failed");
  else
      recover();

So in this specific case the empty macro is probably fine for ordinary "mgbalog(...);" calls, but wrapping both versions in "do { } while (0)" is the more conventional and future-proof C macro shape.

One of those was Word.

In Word you could write macros and use shell to launch other applications.

Suddenly the locked down computer that exposed a handful of applications could run anything (well anything a Windows 3.11 machine in 1995 could run).

It was quite exciting at the time, I don't feel like I have hit the same sort of issues since. Ocassionally I see people say that some touch screen information displays (in shops/shopping centres etc) have ways to escape from kiosk mode (locked to an app) so you can use them for anything, I guess that is similar.

In general most developers struggled to do much with it, it was just too small (combined with the fiddlyness of using it).

PS2 programmer's were very used to thinking in this way as it's how the rendering had to be done. There is a couple of vector units, and one of them is connected to the GPU, so the general structure most developers followed was to have 4 buffers in the VU memory (I think it only had 16kb of memory or something pretty small), but essentially in parallel you'd have:

1. New data being DMAd in from main memory to VU memory (into say buffer 1/4). 2. Previous data in buffer 3/4 being transformed, lit, coloured, etc and output into buffer 4/4. 3. Data from buffer 2/4 being sent/rendered by the GPU.

Then once the above had finished it would flip, so you'd alternate like:

Data in: B1 (main memory to VU) Data out: B2 (VU to GPU) Data process from: B3 (VU processing) Data process to: B4 (VU processing)

Data in: B3 Data out: B4 Data process from: B1 Data process to: B2

The VU has two pipelines running in parallel (float and integer), and every instruction had an exact number of cycles to process, if you read a result before it is ready you stall the pipeline, so you had to painstakingly interleave and order your instructions to process three verts at a time and be very clever about register pressure etc.

There is obviously some clever syncing logic to allow all of this to work, allowing the DMA to wait until the VU kicks off the next GPU batch etc.

It was complex to get your head around, set up all the moving parts and debug when it goes wrong. When it goes wrong it pretty much just hangs, so you had to write a lot of validators. On PS2 you basically spend the frame building up a huge DMA list, and then at the end of the frame kick it off and it renders everything, so the DMA will transfer VU programs to the VU, upload data to the VU, wait for it to process and upload next batch, at the end upload next program, upload settings to GPU registers, bacially everything. Once that DMA is kicked off no more CPU code is involved in rendering the frame, so you have a MB or so of pure memory transfer instructions firing off, if any of them are wrong you are in a world of pain.

Then throw in, just to keep things interesting, the fact that anything you write to memory is likely stuck in caches, and DMA doesn't seem caches, so extra care has to be taken to make sure caches are flushed before using DMA.

It was a magical, horrible, wonderful, painful, joyous, impossible, satisfying, sickening, amazing time.

That’s not just "relativistically instant", that’s literally instant in your frame. The time dilation becomes total at light speed, and length contraction collapses the entire distance in the direction of travel to zero.

Now, it’s true we can’t really assign a rest frame to a photon, so this is a thought experiment. But if you extrapolate the math, the conclusion holds: no time passes for something traveling at light speed.

For a few reasons, but the most common is that when you write a file, you 'fwrite' operation doesn't typically immediately write blocks to the disk, instead it gets written to caches that will be written to disk in due course. Changes to the disk, tables with crucial data, etc again are just updated in memory, and written to the disk at a 'sensible' time. It's possible that you aren't actively performing operations to modify the disk, but various previous changes are sitting in memory waiting to be synced. If you kill the power then these changes aren't flushed so you can end up with corruption/filesystem problems. The main reason things work this way is for performance.

I remember a long time ago (25 years?) someone 'invented' a device where you plug your TV into it, and it has an IR receiver to go with it, you program it to respond to your TVs power button (on the remote control), and then when you go to put your TV into standby, the plug then turns off too, and when you switch it on it does the opposite. At the time it was being touted as the money saver, and I got the impression (although never actually tested!) TVs back then did draw a lot in standby, so this 'invention' was a legitimately good one. But it didn't seem to really take off, I am assume because standby was rapidly implemented in a way where there is such minimal electrical draw that it would be pointless.

I don't have experience of any other password management software, so I certainly can't compare and contrast. But I will say Keepass + Dropbox has worked flawlessly for me across desktop, laptop and mobile. The biggest inconvenience I have had is things like manually typing in a Netflix password into a Smart TV when on holiday (just takes time with long passwords with capitals, lowercase, numbers and symbols).

https://play.google.com/store/apps/details?id=com.dsemu.dras...

Over one million downloads, price £4.99

;)

We stayed in a lot of hostels, along with some guest houses, Airbnbs, hotels but the majority of the time it was something in the cheaper end of the spectrum.

We initially budgeted £10 food, £5 drink and £5 activities per day, and kept quite a lot of records at time, but ultimately we just ended up feeling "it is what it is". We made the active decision to just make the most of the trip and overspend. For a reasonable number of days we could average out towards our budget but we found fairly regularly there were bigger expenses for activities which would blow the budget and we neither wanted to miss them or do nothing for the next fortnight! Once you have committed so much, it sort of feels like it is better to commit a bit more and make it awesome (£60k spent on awesome seemed better than £42k spent on okay).

Before leaving I ran a couple of companies, one which employed 12 people and another which was contractor based. I wasn't wealthy (at least not by the standards set in the UK if you speak to a financial advisor) and £60k was a large amount of money for me to spend (a very large amount). But all things going well with life, you earn it, you spend it, we decided we wanted to do some of that spending earlier in life whilst we could enjoy it.

Since then... I have had heart ops, a blood clot on the lung, my partner has developed ME/chronic fatigue syndrome... COVID19 has engulfed the world. Needless to say we are glad, thankful and lucky we did what we did when we did!

We got a round the world flight ticket, we had to commit to the first six month flight times then half way through commit to the rest. It was possible to change for a fee. But we found the flights gave us a schedule to work around.

Some parts we planned extensively (you can't go to Tibet without being on a tour the whole time you are there, Machu Picchu books up months in advance, etc) other parts (Vietnam, Cambodia, Laos, Thailand) there is somewhat of an established back packer route you can follow and just make sure you get through in time for the next flight.

By far the least safe place was South America, we met many travellers there who had been mugged, beaten up, etc. It was our last destination and we were not very adventurous as we were tired and also just wanted to get to the end without an incident.

Other than that, we generally felt safe, there were one off isolated incidents (drunk Russian man on train trying to make advances on my partner when he thought I was asleep) which were uncomfortable, or going to a train station in Jaipur at 3 in the morning and waiting for a train, with lots of people loitering around and bothering us, and no real security or staff to reassure us, but these were exceptions rather than the norm.

We typically went to places which had a reasonable number of travellers, so it didn't feel too crazy in that sense.