Also interesting is the notion of 'Kolmogorov Complexity' - what is the shortest programme that could produce a given output? Worst case for a truly random sequence would just be to copy it out, but a programme that outputs eg. a million digits of pi can actually be quite short. As can a programme that outputs a particular block cypher for an empty input. In general, it is very difficult to decide how long a programme is needed to produce a given output, and what the upper limit of compression could be.

https://en.m.wikipedia.org/wiki/Kolmogorov_complexity

Which makes perfect sense - none of the previous producers have. Mostly, they've just used their stock characters and locations, and made a game that they thought would be fun out of them. There's a couple of games that qualify as 'direct sequels' (Ocarina -> Majora's, Wind Waker -> Hourglass) but even then, it doesn't benefit you much to have played the preceding one. Would be weird to try and twist the games into a chronology that strikes me mostly as 'fanon' anyway.

Well now. A few things, here:

• there are not 9 × 9 × 9 × 9 × .... possible ways to play. After the first move, 8 squares remain, and so on, so there's at most 9 × 8 × 7 × ... = 9! = 362880 ways that the game can be played, ignoring the fact that most of those can be eliminated as reflections and rotations, or as win positions before you fill the whole board.

• we don't care how we got there. Each square can either be blank, a cross, or a nought, so 3^9 combos = 19683, and most of those are illegal, as only the boards where there's (one or zero) more crosses than noughts are good. And you don't need to store 'the computer's move', just jump directly to letting the player go again. Let's guess we need at most a quarter of that.

• we could have created a single web page with 5k anchor elements on it back in the HTML 1.0 days, ignoring the fact that it would have taken a while to download on our 28.8K modems. That wouldn't have been 170 Mb of unnecessary tagging, even with the 'lay it out with tables' style we had at the time.

Google do seem to have a predilection for reinventing the past, poorly. I hear that their bonuses are based on inventing 'new' things, though, so it's in their interest to pass it off?

Obligatory www.web3isgoinggreat.com - catalogues all of the grifts, hacks and thefts, with a running $$$ total.

I still have a Rage 128 hanging around as a 'temporary head' for installing headless servers. Many happy nights playing Thief: The Dark Project with it, and now it's only good for rendering a TTY at a barely acceptable resolution. And soon, not even that. Goodbye, little e-waste :-(

Writing in ASM is not too bad provided that there's no operating system getting in the way. If you're on some old 8-bit microcomputer where you're free to read directly from the input buffers and write directly to the screen framebuffer, or if you're doing embedded where it's all memory-mapped IO anyway, then great. Very easy, makes a lot of sense. For games, that era basically ended with DOS, and VGA-compatible cards that you could just write bits to and have them appear on screen.

Now, you have to display things on the screen by telling the graphics driver to do it, and so a lot of your assembly is just going to be arranging all of your data according to your platform's C calling convention and then making syscalls, plus other tedious-but-essential requirements like making sure the stack is aligned whenever you make a jump. You might as well write macros to do that since you'll be doing it a lot, and if you've written macros to do it then you might as well be using C instead, since most of C's keywords and syntax map very closely to the ASM that would be generated by macros.

A shame - you do learn a lot by having to tell the computer exactly what you want it to do - but I couldn't recommend it for any non-trivial task any more. Maybe a wee bit of assembly here-and-there when you've some very specific data alignment or timing-sensitive requirement.

Moved over from Mint to Arch for gaming, which has some additional benefits:

• more up-to-date kernel and more up-to-date Mesa, which brings very noticeable improvements in frame rates - in Elden Ring for example, 45 fps outside in Mint to 60 fps outside on Arch

• my desktop soundcard isn't recognised properly by PulseAudio but is by PipeWire. It's hard to be sure that PulseAudio is completely gone when you uninstall it then reinstall something else. Arch, I just installed what I wanted in the first place

• some utility programmes, like CoreCtrl for graphics card fan and power tweaking, and emulators like RPCS3, are the Arch repositories but not the Mint ones. Much easier to keep them up-to-date

• for a gaming machine, no more 'mystery services' that I don't know what they are. I quite like having everything quite stripped back for a gaming machine. On Arch, I know what everything does because I installed it. That's not the case on Mint.

Obviously, I installed the Cinnamon desktop as my GUI choice - there's certain things about Mint that are tremendous and worth sticking to.

Cheaper for now, since venture capitalist cash is paying to keep those extremely expensive servers running. The AI experiments at my work (automatically generating documentation) have got about an 80% reject rate - sometimes they're not right, sometimes they're not even wrong - and it's not really an improvement on time having to review it all versus just doing the work.

No doubt there are places where AI makes sense; a lot of those places seem to be in enhancing the output of someone who is already very skilled. So let's see how "cheaper" works out.

A bit like when we renamed all the master/slave terminology using different phrasing that's frankly more useful a lot of the time, I think it's about time we got rid of this "child" task nonsense. I suggest "subtask". Then we can reword these books into something that no-one can make stupid jokes about any more, like "how to keep your subs in line" and "how to punish your subs when they've misbehaved".

Blasphemous 2 has a transgender breastfeeding scene, but only a single-player campaign, seems odd to call it a 'story mode'... Good work getting to that bit in four hours, too.

The kernel option is mitigations=off, if you want to try adding it to your Grub command line? From the testing I've done, provides no benefits whatsoever - no more frames in games, compilation runs no quicker, battery life on a laptop is no better.

https://wiki.archlinux.org/title/Improving_performance#Turn_off_CPU_exploit_mitigations

Yeah; if I was picking the aspects of Ubuntu where they were making a mistake, 'minimal default install but easy to download more' would not be what I'd have selected - that actually sounds a good thing. Having too much out-of-date crud was starting to be a problem. 'Everything is a snap, which runs like a three-legged dog even on a powerful machine, and causes me disk space issues on less powerful ones too' - that's a problem. 'Keeping on messing with Firefox, and replacing my ppa version with an out of date snap, which means I've changed my works machine over to Mint to avoid their nonsense?' - that's a problem.

Man alive, I thought that Mozilla had been doing their own Personal Package Archives so that we didn't have to deal with Ubuntu packaging it as a Snap anymore. And this is doubly disappointing.

Dang. It's going to take a dedicated regime to fill up a one gallon jar with, eh, fluids.

That's because Arch is the best, so any additional comparisons are just wasting everyone's time ;-)

RockPaperShotgun did a performance analysis on this - long story short, a 30xx card will be good for about medium settings, a 40xx for high, and really a 4090 for ultra. According to the Steam hardware survey, that's about one-in-five PC gamers that could start this up if they wanted to; a few percent can run it with all the flashy graphics. Combine the hardware exclusivity and the distinctly 'meh' reviews, get some seriously low player numbers.

I think when Disney demands an internally-hosted version of your product, then the sales team tells engineering that they'll provide one, and mark the price up accordingly. That kind of thing doesn't appear on the external listing for everyone else.

Deep frying a battery - likely to make your whole kitchen turn crispy.

Where he's likely to be going with this is "war ends, but Russia gets to keep the territory they've illegally annexed". And that will not do. They stole Crimea; if they get to steal more, then they'll just be back again in a few years once they've licked their wounds. All territory must be returned to Ukraine, and then they can pay reparations and fuck off, and we'll welcome Ukraine into the EU and NATO so this shit never happens again.

That is a good read, thank you. Didn't have procedures, had two different brokersge systems running at once because they'd no procedures to follow, lost a fortune.

I'm thinking it's the "most expensive bug in history so far - haven't seen an accurate total for CrowdStrike's little faux pas, yet.

The sound will eventually dissipate in the air as heat. The light will be absorbed into surfaces, like any other radiation, as heat. Still 100%, but with a couple extra stops along the way.

Assuming that these have fairly impressive 100 MB/s sustained write speed, then it's going to take about 93 hours to write the whole contents of the disk - basically four days. That's a long time to replace a failed drive in a RAID array; you'd need to consider multiple disks of redundancy just in case another one fails while you're resilvering the first.

Linus' anger management looks to be working out for him - that's four sentences in a row without any fucks in them. Keep on keeping it chill, big man.

Oh, one of our customers' users deleted the /var directory on one of the servers we provided to them, because it was "taking up too much space on disk". That's where Postgres saves its DBs as well; wiped out weeks of work in production for them. This hits very close to home.

I am shocked that Lennart Poettering, PulseAudio dev, but also Avahi and SystemD dev, whose name might frequently be brought up in conversations about interoperability, reliability, small ego, diplomacy, etc etc, might not be as good at coding an audio stack as legendary C64 demo coder and PipeWire dev Wim Taymans. Shocked, I tell you. Well, not that shocked.

No, it really is that simple. I've got Cinnamon installed since I prefer it for everyday; also, Gnome3 on Wayland for gaming (I've three monitors with different refresh rates, which doesn't work as you'd hope on X11). Log out, change desktop, log in again. No problems at all, except for more packages to update.

You can write an unmaintainable fucking mess in any language. Rust won't save you from cryptic variable naming, copy-paste code, a complete absence of design patterns, dreadful algorithms, large classes of security issues, unfathomable UX, or a hundred other things. "Clean code" is (mostly) a separate issue from choice of language.

Don't get me wrong - I don't like this book. It manages to be both long-winded and facile at the same time. A lot of people seem to read it and take the exact wrong lessons about maintainability from it. I think that it would mostly benefit from being written in pseudocode - concentrating on any particular language might distract from the message. But having a few examples of what a shitfest looks like in a few specific languages might help

There are, but it's complicated. Doom (2016) for instance - it doesn't handle the very large Vulkan swap chain that's possible on some modern graphics cards, crashes on start-up. Someone patched Proton around that time so that Doom would start; the patch was later reverted since it broke other games. Other games based off of that engine - couple of Wolfensteins, Doom Eternal - have the problem fixed in the binaries, and so run on up-to-date Proton, but depending on your hardware, only a few specific, old, versions of Proton, will do for Doom.

Regressions get fixed - that's okay. Buggy behaviour which depended on regressions that got fixed - that's a problem.

I remember the days when laptops used to have infrared ports, so that you could connect to the infrared port on your mobile phone for tethered internet. And it was atrocious - always dropping out, even when you'd moved either item. Bluetooth tethering / USB cable tethering is just so much more robust.

I realise that our tech has moved on a lot in the last twenty-or-so years, but I'm struggling to see the use cases that this 'new tech' (as described by PC Gamer) would enable. Mobile data and wifi are both fast and reliable, and wired connections are very fast and much more reliable. A 224 GB/s link speed is absurdly faster than most consumer hardware can read or write to disk; if you were hoping to reduce 'gaming latency' by holding your phone or laptop at just the right angle, then the benefit would be overshadowed by other delays in the general internet. Providing a 'secure link' at this speed ('quicker and safer than wifi') would only make sense if you've two mainframes in the same room, but for some reason you don't want to make your data centre look untidy by running fibre optic connections between them.

I wouldn't really use the pound as a comparison for anything - we decided that committing economic suicide and abandoning free trade with our closest trading block was a small price to pay for being able to be mean to poor brown people. The reviews are coming in; would you believe that that was a stupid decision, and we've a stupid currency that's not worth as much any more?

Javascript might be the most widely-used scripting language in use today, due to its browser dominance. Most popular would imply that it's not completely despised by everyone that has to use it, which is misleading. Even TypeScript tutorials are about 50% 'you have to understand what Javascript does wrong here'.

All my brothers and sisters in the 3.6%, represent. Let's make a new year's resolution to rub out twice as many next year!

Слава fucking Україні! Hope this is the first of many, get that counter-offensive rolling, bring them all back home.

emerges from a brand you've probably never heard of

Writing this on a Tuxedo Pulse 14 / gen 3 as we speak. Great little laptop. I'd wanted something with a few more pixels than my previous machine, and there's a massive jump from bog-standard 1080p to extremely expensive 4K screens. Three megapixel screen at a premium-but-not-insane price, compiles code like a champion, makes an extremely competent job of 3D gaming, came with Linux and runs it all perfectly.

"Tuxedo Linux", which is their in-house distro, is Ubuntu + KDE Plasma. Seemed absolutely fine, although I replaced it with Arch btw since that's more my style. Presumably they're using Debian for the ARM support on this new one? This one runs pretty cold most of the time, but you definitely know that you've got a 54W processor in a very thin mobile device when you try eg. playing simulation games - it gets a bit warm on the knees. "Not x64" would be a deal-breaker for my work, but for most uses the added battery life would be more valuable than the inconvenience.

I feel that 'gender' is probably a misleading term for the languages that have 'grammatical gender', it rarely has anything to do with genitalia. 'Noun class', where adjectives have to decline to agree with the class would fit better in most cases.

English essentially does not have decline adjectives, except for historical outliers like blond/e where no-one much cares if you don't bother, and uses his / hers / its / erc using a very predictable rule. So no 'grammatical gender'.

Once the kernel has loaded itself, it needs to start up userspace as well. This is usually (perhaps exclusively) done by starting an 'init' program as process number 1, which then starts up all the other userspace programs: systemd is no different in that regard. It solves a variety of problems that traditional inits have, though:

• rather than having near-incomprehensible shell scripts to start, stop, etc. all your programmes and services, it uses INI-style service files which are merely fiddly. They're kept in a few logical places, not 'everywhere'

• starting and stopping services is done with simple, consistent commands - systemctl enable tomcat will start the Tomcat webserver at next boot; start, restart, stop and disable do basically what you think. Shell scripts are... less predictable, especially between distros.

• rather than having to inspect all of your scripts and work out what order they start in, SystemD just lets you declare what they depend on, and it works it out for you - much simpler, much more robust.

• rather than needing a separate tool to manage scheduled events (usually a chron-like, like anachron), SystemD just lets you write a 'timer' with the same syntax as its service files. They can be set to only trigger based on other events, like start-up, so you can do once-an-hour database snapshots (but only if the DB is running) very easily. That's painful with traditional inits.

• also manages disk and network mounts, so you don't need a separate tool for those, and you can trigger other events off of them as well. That was also painful in older inits.

• and power events too, if you want to trigger other tasks before sleep or when your laptop wakes up. (Again, was painful before.)

• log files all in one place and controlled in the same way and accessed with one tool - again, traditional inits aren't like that.

• (advanced usages) works well with cgroups, so if you're looking to limit the CPU time on a web service and make sure that it only uses its share of memory, that's dead easy. Very difficult with traditional init.

You can get a reasonable idea of what systemd is doing with a systemctl status at the command line; shows you the overall system status, with a nice tree view of what's running and what caused it to start. Getting that kind of overview on a eg. SysV init is much less simple.

Administrators and devops generally love it; it's very simple and straightforward and consistent and predictable. Certain devs dislike it, due to the original author, or feelings of overreach and complexity (although it's much simpler than learning everything that it replaces), or because they're attached to Bash scripts. (You can trigger Bash scripts with SystemD if you like, but they're not 'in control'.)

Not all of the light would have been wasted on the wall. If your wall is painted green, then the 'rest of the rainbow' (red, orange, yellow, blue, violet wavelengths) would be absorbed and converted into heat. Paint is quite rough on a microscopic level, and the green light reflected would be scattered in every direction.

Things that have a colour do so because they reflect those frequencies. Mirrors reflect pretty much all frequencies of visible light with very little scattering - that's the definition of the word, really.

If you had a black feature wall behind your lamp, such that very little was reflected off it into the rest of the room, then with a mirror there would be about twice the photons illuminating the room. If your wall was pure brilliant white, much less of a difference. Your eyes don't perceive 'twice the photons' as 'twice as bright' - they scale from absorbing thousands a second when fully dark-adjusted at night, to trillions per second at midday - but you might find it a bit easier to eg. read a book elsewhere in the room.

Light output from the lamp doesn't change, but depending on the colours of things in your room, the light output that is useful for seeing might do.

I think that Python has a bit of a 'Microsoft Word' thing on the go. You know how your own docs are completely editable and print fine, but everyone else's are a complete fucking disaster and pressing a single key will screw up the formatting of the whole document? Your own Python code is full of sensible idioms and pragmatic naming conventions, but everyone else's was plainly written while on mushrooms.

Really? If it's a big enough treatment works to warrant a SCADA, then I doubt an automation engineer with the experience to set it all up would be asking this question, but here goes. You've a couple of obstacles:

• every contract I've ever seen for industrial automation has either specified which control plane they want directly, or they'll have a list of approved suppliers which you must use. Someone after you will have to maintain this. Those maintainers will only accept the things that they have been trained on. Those things are Windows PCs running Windows software. They will reject anything else. The people running network security on those machines will have a very short list of the acceptable operating systems for running SCADA systems. That list will be a couple of versions of Windows Server. They will also reject anything else.

• that's not nearly enough information to make a recommendation. Which PLCs? Allen Bradley, Siemens, Mitsubishi, ...? I can't think of a job I've ever been on where the local HMI hasn't matched the PLCs. The SCADA software almost invariably matches the PLCs used in the main motor control centre, with perhaps a couple of oddball PLCs for proprietary panels and such like. Could maybe ask the supplier if they've a Linux alternative? Siemens will laugh at you and Mitsi won't understand the question, but AB just might.

Sorry - I'm a Linux evangelist, but I don't think it's a good fit for here. SCADA performance generally isn't bad due to Windows Server - it's fine, does what it's intended to - but because eg. STEP 7 is an appallingly slow and bloated piece of software which would bring a mainframe to its knees. Which is bizarre - the over-the-wire protocol connecting the machines is generally a short binary blob described in the PLC configuration - these bits are the drive statuses, these bits are an int or a float for an instrument readout - and it shouldn't be at all slow updating it all, but slow it is.

Not interested in owning one of these myself, but thanks to everyone that does - the huge success makes life much better for Linux gamers, general compatibility has been absolutely through the roof recently.