Redkey

I know it's a really picky take, but I resent the implication that I should want to keep my personal files mixed in at the same level of the file hierarchy as all my applications' random settings, cached data, and temporary garbage. Documents, Music, Videos, Projects, .config, .cache, SelfishAppName, OtherSelfishAppName...

It bothered me when Microsoft started doing it in Win95, and it still bothers me in Linux. Especially when software acts surprised (or occasionally indignant) that I don't keep all my files in those directories. I have lost small bits of my own work over the years by forgetting to back up things that recalcitrant software refused to store anywhere else.

But I am amused that this is the same name that I use at the top of my own storage hierarchy for self-made things.

I used one of the i5 CPUs with HD2500 integrated graphics in my main gaming PC for several years, up until only about 3-4 years ago. The performance was OK for me, but I paired it with a much newer, discrete GPU. Those integrated graphics are really going to hold you back. In games from 2012-2014 (around when those CPUs came out), they average 20-40 fps on lowest settings.

You don't have to use Steam, but it is a very painless way to play games that you own on Steam. I use Lutris for my non-Steam Windows games. It works well on my main gaming PC, but I often have issues with it on my laptops which have older integrated graphics, due to lack of Vulkan support, which Lutris seems to insist upon even when the software can use OpenGL.

Your comment seems to be trying to disagree with me, but I think you wrote almost the same things that I wrote in the comment that you're replying to:

• The Rust book is about much more than just what's in its title (my point being that this also goes for the cited C++ book).
• C++ is a baroque and sometimes unwieldy language.

Initialization in C++ is so simple that somebody wrote a nearly 300-page book on the subject

There's a book about 101 ways to cut potatoes. Perhaps that could be a real mike-drop bit of evidence that we shouldn't be cooking potatoes.

Here's a 249-page book "just" about atomics and locks in Rust. Does a book this large about only one aspect of Rust prove that it's a terrible language? No, because as with the C++ book, if we look at the summary of contents we can see that it actually covers a great deal more, simply with a focus on those topics.

Luckily we don't have to be compete masters of every aspect of a language in order to use it.

Honestly, I think that modern C++ is a very piecemeal language with no clear direction, and it has many issues because of that. But the title and page count of a single book is not a convincing argument of anything.

I'm all for humourous roasts of things, but does anyone really find this funny? Was the author possibly being serious? I don't know. What I do know is that I stopped watching after the first four examples because they were all deliberately incorrect or misleading, but also didn't seem funny to me.

1. Crazy initialization
   That sure is a lot of ways to initialize a variable! Even though some of these variables are quite different and would be initialized differently from each other in many other languages, even only counting the initializations that are functionally equivalent, there are a bunch of abuses of syntax that I've never seen used in the wild.

At this point I had hope that this was meant to be amusing.

2. Printing to the console
   C++ has had a version of C's printf function from the very beginning. That weird stream syntax has some hardcore fans but many people ignore it. I did my CS degree close to 30 years ago, and the only time I used stream syntax was for one lab class exercise in which we had to show that we understood how to use stream syntax.

They still could be going for a comedy roast, I guess.

3. Getting a random number
   Much like the printf statement for number 2 above, C++ had its own version of C's rand function from the start. I've never even heard of the stuff that's being shown in this part of the video.

OK that was virtually the same fake point as the previous one, and still no punchlines in sight.

4. Having to type "static_cast" every time you recast a variable
   Nope, you don't. You're free to ask the compiler to automagically recast your variables to another type without giving any further detail just like you can in C. In fact, they're often called "C-style casts". There are even implicit casts, where you literally don't add anything, and just cross your fingers that the compiler does what you think it should do. It's like a little bit of the thrill of dynamic typing brought into C++! By using the static_cast keyword, you can tell the compiler that you understand that there's a potential issue with this recast, but that you expect that the standard way of handling it will be fine. There are other keywords for more unusual situations; it's not just a random bit of busywork added for no reason.

Many years ago I lived alone in a small apartment, and I used to leave most of my consoles connected and kept them in a big shelving unit with my TV. But now I live in a house with my family and that's not practical.

At the moment I'm in the process of moving the consoles I still use to wide, shallow boxes with fully removable lids. Up until recently I laboriously unpacked and repacked every console when I wanted to use it, carrying armfuls of cables and equipment to wherever in the house I wanted to set it up. But now, I'm buying these boxes and transferring each system across as I use them.

The idea is that I can leave everything attached to the console while it's in storage, and then when I want to use it I can just take the box to whichever room I want to use, remove the lid, connect power and AV, and pull out the controller and go. When I'm done, it's easy to disconnect the cables from the display and power socket, tuck everything back into the box, and put it away. This is almost as easy as leaving systems set up in place, plus it keeps dust and pet hair out of the equipment, which was a constant issue when I lived alone and left them all set up.

You just need to find boxes that are long and wide enough to hold the console with all its cables and peripherals attached without putting undue bending stress on the cables. For older systems you need to be careful of height as well, for joysticks and so you can leave any top-loading flash carts plugged in to save the connectors.

The original StarCraft and Brood War expansion didn't require Internet for installation. And while the original boxed copies (I got the "Battle Chest" re-release which is the same) required the CD to be in the drive, the last one or two official update patches let you copy the .mpq (?) data files from the CDs into the installation directory so you can play without them.

Reading current discussion, it seems more like "You say that it's impossible to dirty your house, yet nothing's stopping anyone from dumping out this bucket of mud on your floor, curious!"

Sorry for not being clear; when I said "keep track automatically" I meant dynamic typing. Of course you're right that "keeping track of your variables" could also be interpreted to refer to static typing.

I started programming in a time when the idea that the computer could keep track of your variable types for you automatically was a fever dream, so it's wild for me to see some programmers now throwing shade at particular langages for "not implementing proper variable typing functionality".

It feels like someone saying that low-fat milk producers are too cheap or lazy to put enough fat in their milk.

Fashion really does go in cycles.

Years ago I used to have Lakka on a bootable USB drive to turn an old, low-powered laptop into a dedicated emulation machine.

The specs are hard to read, but I believe the main processor is an AMD A6-1450 APU, designed for tablets and released some time in or after 2013. Not a powerful chip by modern standards, but IMO still useable depending on your expectations. It's definitely capable of emulating SNES without breaking a sweat. Even PS1 shouldn't be a problem at native resolution. N64, Saturn, and Dreamcast are probably where you'll start seeing slowdown in some games, and anything more, like PS2 or GCN, is unlikely to be playable.

I've tried all the suggestions made so far by other commenters, and they are solid options IMO. One of my personal requirements has been that the writing tip is either smooth/rounded, retractable, or covered in some way, because I use my pencil a lot every day, and I prefer to keep it in my hip pocket. If a fine tip is exposed, it gets caught in the fabric and/or bent.

For a long time the GraphGear 1000 was my favourite because the tip retracts and it has a sturdy metal body. But it's quite long and heavy, and I had to use the clip, which has a somewhat flimsy hinge joint. If the clip gets ripped off (happens to me) it renders the pencil useless because the clip holds the tip out for writing. I also used Orenz pencils for a while because I like the lead-protecting sleeve, but the tip doesn't seem to be designed to be repeatedly pushed back into the body, because they always start jamming on me pretty quickly.

A few months ago I discovered the Pentel Kerry and it's my new favourite. It has a removeable cap to protect the lead when closed, and to use it you remove the cap (friction/snap fit) and put it on the other end of the pencil like you would with a regular pen. The tip of the cap has a spring-loaded button which connects with the lead advance button on the main pencil body, so you can click on the rear end to advance the lead as normal. Unfortunately I don't think there's a metal body version, but the plastic feels quite sturdy to me.