strags

This legislation might be more persuasive if it were tied to a reasonable time limit, but I don't see anything of that nature in the text. An obligation to support or refund customers that lasts for a fair timespan (ie. preventing rugpulls) is far less onerous than an obligation to release your code to satisfy someone's nostalgia.

That might be fine for very small titles - where the "game server" is a relatively simple binary that can be run anywhere. Larger titles depend on a huge amount of infrastructure, for authentication, progression, matchmaking, etc... It's not feasible to open-source all of that, especially given that it may well still be in use for more recent titles.

Quote: The PIC has 1024 words (12-bits) of program ROM, ~256 bytes contain a hand-crafted RFC1122-compliant implementation of TCP/IP including.

HTTP/1.0 and i2c eeprom Filesystem, using 3 to 99 instructions. TCP and UDP protocol stack, using 70 to 99 instructions. ICMP [supports upto ping -s 11], using upto 14 instructions. IP - Internet Protocol, v4, using 68 to 77 instructions. SLIP - Serial Line IP packetisation, about 76 inst Fully buffered UART, upto 115200 bps, using 38 to 56 instructions. Operating system: RTOS with Rate Monotonic Analysis, using 3 to 15 instructions.

I'd like to invoke them with just (eg.) ./dostuff.py - Python, Ruby etc... have absolutely no problem running files containing Win-style line-endings. The only issue is that /usr/bin/env complains that it can't find (eg.) "python3\n".

Yes, I know I could convert these files with dos2unix, and I also know that I can just invoke the interpreter explicitly - but I'm lazy, and this seems like such a trivial thing to solve that I can't believe it's not been done already.

I've taken to actually recompiling /usr/bin/env to strip trailing whitespace from the executable name - but there must be a better solution.

My team and I run the servers for a number of very big videogames. For a high-cpu workload, if you look around at static on-prem hosting and actually do some real performance bencharking, you will find that cloud machines - though convenient - generally cost at least 2x as much per unit performance. Not only that, but cloud will absolutely gouge you on egress bandwidth - leading to a cost multiplier that's closer to 4x, depending on the balance between compute and outbound bandwidth.

That's not to say we don't use the cloud - in fact we use it extensively.

Since you have to pay for static capacity 24/7 - even when your regional players are asleep and the machines are idle, there are some gains to be had by using the right blend of static/elastic - don't plan to cover peaks with 100% static - and spin up the elastic machines when your static capacity is fully consumed. This holds true for anything that results in more usage - a busy weekend, an in-game event, a new piece of downloadable content, etc... It's also a great way to deal with not knowing exactly how many players are going to show up on day 1.

Regarding latency, we have machines in many smaller datacenters around the world. We can generally get players far closer to one of our machines than to AWS/GCP/Azure, resulting in better in-game ping, which is super important to us. This will change over time as more and more cloud DCs spring up, but for now we're pretty happy with the blend.

I discovered that my son (17 months old at the time) loves to mess with stereo controls. So I bought a few rotary encoders and neo-pixel rings - build a wooden enclosure with a plastic faceplate, and wrote some code to generate fancy light and audio effects when he turns/clicks the knobs. He loved it. We call it the "Max Distractor".

https://www.youtube.com/watch?v=xtE8oE9GOsM

Inside it's just a RPi. One of these days I really need to make it do something more fancy.

How to build the dictionary? Well, in order to determine the most commonly used English words, I downloaded a bunch of free texts from Project Gutenberg, and did some simple filtering - nothing less than 5 letters, no duplication of singular + plural, etc...

A valuable lesson that I learned during this process is that when your corpus includes older english texts, you should always give your final list a visual once-over and apply some judicious manual filtering. I'm looking at you, "The Adventures of Tom Sawyer". (And, to a lesser extent, Moby Dick).

The house was built about 10 years ago with what (I presume) was a state-of-the-art system at the time - an "AudioAccess WHEN" system. It works fine - there are keypads and speakers in every room, and I can pipe audio from the Sonos (or an Airplay receiver) to anywhere.

It's a weird topology, however - the speakers in each room are wired to the keypads (which is where the amps live). Each keypad has a power connection, and some kind of (presumably proprietary) Cat-5 connection to a central hub. The hub in turn is connected via Cat-5 to a head unit with FM receiver, CD/AUX inputs, etc...

When we moved into the house, the head unit wasn't working - it refused to establish a connection to the hub. I managed to track down a working tech support phone number, only to hear that they don't make this system any more, and that the head units often fail in this way. I managed to find what may have been the last replacement head unit in existence on Ebay - bought it, and fortunately everything started working!

I am, however, dreading the day when it inevitably dies. Since the speaker wires go to the keypad amps, and not to the wiring closet (where the hubs live), I'm not sure what I could replace it with - beyond re-running new speaker wire to a completely new system in the wiring closet.

https://www.youtube.com/watch?v=xtE8oE9GOsM

Currently it's still running my test code, which just lets him mess with volume/pan/pitch. I need to get around to writing something a bit fancier.

Tech deets: It's just a RPi3 with most of the stuff written in Python. I tried to get a bunch of Python audio libs working, but gave up and wrote my own C++ module for sample mixing. The NeoPixel rings are driven via the SPI output, and the rotary encoders/switches are just hooked up to random GPIOs.

Err... were these commands meant to be obfuscated the whole time?

(In fact, C and GOAL code almost used the same ABI. IIRC, GOAL always had the GP(?) register pointing at the symbol table for fast access, but gcc MIPS code expected it to be something else. If you wanted to be able to call back and forth, you had to write tiny shim functions).

I started at ND in 2004, around the tail-end of Jak 3. After Andy had left, I picked up the Goal compiler, and hacked it around to generate code for the PSP. After about a week or two, we had the kernel booting, and hot-patching working. We built a whole engine that looked amazing, but unfortunately the project was shelved. Still, it was some of the most fun I've had in my career.

Actually, it did. IIRC, the debug state required for converting run-time addresses to source lines was persisted in the compiler (which was a REPL, not a one-shot process like C), rather than exported in the form of symbols. The interface was pretty sketchy, but I'd say it was about as usable as GDB. You could set breakpoints, inspect registers, etc...

A lot of debugging was "live" though - since all the code was hot-loadable, you could just insert a debug print in the middle of a function on the fly. It was a really nice, iterative way to work.

http://www.thefreelibrary.com/Court+Rules+for+Scenix+Semicon...

Featuring such fabulous claims as:

-- Having a number of I/O pins that is less than the instruction word size; the SX Series 12-bit instruction word is clearly smaller than its number of I/O pins.

Seriously - you pretty much just have to make a .dep and a .rpm and you're covered. Is that so hard?

Wikipedia says ( http://en.wikipedia.org/wiki/RSA_(cryptosystem) ): "When m is not relatively prime to n, the argument just given is invalid. This is highly improbable (only a proportion of 1/p + 1/q − 1/(pq) numbers have this property), but even in this case the desired congruence is still true. Either m ≡ 0 (mod p) or m ≡ 0 (mod q), and these cases can be treated using the previous proof.".

I'm not sure I follow 100% - perhaps someone smarter can explain.

http://www2.physics.umd.edu/~yakovenk/teaching/Lorentz.pdf

The Lorentz transform allows you to calculate exactly how time/distance differ between two reference frames.

The above link derives the transform from first principles - assuming only spatial symmetry and the invariance of the speed of light in different reference frames. There are other derivations, but I found this one the most straightforward.

As player #181 out of those #182, I'm excited :)