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
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?
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 :-(
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.
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.
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.
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.
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.
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.
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.
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.
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.
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'.)
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.
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.
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.
I think having publicly-viewable 'karma' is a mistake - there's no benefit to having karma-whore posts and bots if it doesn't gain you anything, and that's a cancer that eats away at other platforms. Similarly, the effect of brigading a single comment is much less - encourages conversation rather than groupthink. And we can all see each other's posting history anyway - we can see whether any given account is a troll account and admins can ban them.
I don't quite understand where this money is going, either. Does Australia not have existing swimming pools and athletics tracks with grandstand seating, near to some existing large hotels? It seems like any large sporting event (see also, the world cup and the Olympics) demands that everything be built brand spanking new for a one-off tournament. Completely pissing money away, couldn't agree more with cancelling it.
It's a massive question, and I think quite a lot of the argument comes from the fact that it depends what direction you're answering it from.
As a user, do I like being able to just systemctl enable --now whatever.service , and have a nice overview of 'how's my computer' in systemctl status ? Yes, that's a big step up from symlinking run levels and other nonsense, much easier.
As an administrator, do I like having services, mounts and timers all managed in one way? Yes, that is very nice - can do more with less, and have to spend less time hunting for where things are configured. Do I think that the configuration files for these are a fucking mess of 'just keep adding new features in' and the override system is lunacy? Also yes.
As a developer trying to do post-mortem debugging, who just wants all the logs in front of him for some server that's gone wrong somehow, which I often have to request via an insane daisy-chain of emails and 'Salesforce nonsense that our tech support use' from our often fairly non-technical end users, on some server that I've no other access to? No, I do not find having logs spread between /var/log and journalctl (and various CloudFormation logs in a web console) makes my life easier. I would be pleased if that got sorted out.
tl:dr; mostly an improvement, some caveats.
Proving a negative, eh? Good luck with that. But I'm sure with a carefully chosen game, a carefully chosen setup, and a carefully chosen independent benchmarker, then it won't have any problems.
Besides which, if we're linking PCGamer, here's their Resi 8 Village comparison between the Denuvo and the cracked version, showing the Denuvo version stuttering like crazy compared to the butter smooth cracked version. Probably the same maximum framerate and the same median framerate, and I wouldn't be shocked if the cracked version had a stutter in it, so the minimum framerate would be the same too.
https://www.pcgamer.com/resident-evil-village-drm-denuvo-stuttering/
Thought the text said that they were going to do Grimes. I'm up for some crimes, tho.
Nah, that there's an armsadillo. You can tell, because he has two.
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.
Humble guy, but that list of features that they're working on is really impressive. Got a wee DragonFly Black USB audio thing that just never worked quite right with PulseAudio - install PipeWire instead, and it just does all its tricks. Great work team, keep it up.
It's not the compiling that kernel is hard - ironically, it's one of the easiest things in the whole ecosystem to compile, got great tooling. It's breaking down the mental barrier of something that you thought would be hard, but turns out to be completely within your grasp. Great work, keep it up, and never be afraid to keep pushing onwards.
Ah, that sounds a bit unfortunate. I've run AMD CPUs on Linux desktops with Bulldozer / Piledriver / Ryzen 7, my current laptop is a Ryzen 7 as well, never run into that at all. Hopefully the Arch wiki will sort you out. If not that, the third option would be 'install Linux on an M-series Mac' - don't know how feasible it is at the moment, and paying the 'Mac premium for hardware and software integration and then overwriting the software' doesn't make a lot of sense to me.
You seem to have fallen foul of all the SystemD haters in the voting, when this is the best answer. OP's question was about doing one thing on a timer and a very similar thing on login; SystemD can achieve both of these in one place with proper logging and status displays, whereas Cron cannot.
Most of the things that you'd want to run on a timer have additional dependencies (I'd like to snapshot the database if the database is running; I'd like to backup up my files to a remote server if the network is up) which as easy to express in SystemD files as anything else it can do. Might as well learn to use the most versatile and powerful tool if you're going to learn anything. Admittedly, I don't like its syntax, but it achieves this kind of thing perfectly.
Well; setting aside the small reference pool of modern gaming journalism, I'm not sure that it is such a big step from HL to CoD, just a bit of a step down. HL is as much of a 'corridor shooter' as you could ever hope to find - there's one path through it, and I doubt that many people deviate from it all that much on a playthrough. The difference is, that HL is super imaginatively dressed up on that one path. The levels have a real sense of place. Like you say, the puzzles are never all that difficult, but they're extremely well-integrated into the design; they feel like the kind of obstacles that you might have to overcome in a top-secret research facility when disaster has struck. And they're mainly new puzzles; nothing hackneyed or tropey here.
From the article:
In many ways, Half-Life can be seen as an indictment of the video game industry: how can a 25 year-old game be better than almost every shooter that has followed it? Why has its ambition only ever been exceeded only by its own sequel? It paints a picture of a stagnated industry still playing with toys from the 1990s.
I think there's two problems here; one is that it's safer to play follow-the-leader, and one is learning the wrong lesson from the leader. Kind of hard to believe now, but HL was considered a graphic powerhouse when it came out, requiring some of the top class machines of the day. But I think that the kind of 'immersive feeling of wonder' that HL has via its design conjuring up a real place is mostly due to its environmental storytelling and the novelty of not knowing what to expect around each corner. The imitators saw the twisty-but-linear game, and decided that the most important thing to copy was to have as much graphics as possible. Can't copy the imaginativeness and the care, so yeah, perpetually taking control away from you for a shooting gallery setpiece, when in fact that only draws you in in a superficial way.
I wouldn't mind other games copying HL if what they wanted to copy was inventiveness, experimentation, and non-stop gameplay. Copying the things that were new about HL is the complete wrong thing to copy, though.
That's a fair comment. But on the other hand, if you are spending a fortune on a CPU the size of your hand (look at that thing in the article!) then there's a good chance you're using it for business purposes, and either you or your IT department will be very keen to have a completely vender-supported stack. Enthusiasts with fresh OS installs will not be representative of users of this tech - AMD haven't really been targetting it at gamer desktops.
Of course, comparing both would be even better, see whether it is an HP crapware issue...
Oh, one of our customers' users deleted the
/vardirectory 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.