Skip Navigation

InitialsDiceBearhttps://github.com/dicebear/dicebearhttps://creativecommons.org/publicdomain/zero/1.0/„Initials” (https://github.com/dicebear/dicebear) by „DiceBear”, licensed under „CC0 1.0” (https://creativecommons.org/publicdomain/zero/1.0/)AK
Posts
4
Comments
451
Joined
2 yr. ago

  • I agree only a little. The game got more flak than it deserved. It was mostly a good game.

    BUT CDPR brought this on themselves by building up massive hype with excessive promises they in the end were not able to deliver on. In addition they stubbornly tried to get a next gen game on last gen consoles which also failed hard.

    I think a lot of the stuff that went wrong was management and marketing related and could have been avoided.

  • I also enjoyed it playing on GeForceNow. I didn't build up any game specific hype. I only looked forward to the next CDPR game and avoided most trailers and footage. Going into the game without expectations likely helped a lot.

  • Do you separate that? I mean if the idea is to use C only outside of user interaction, then maybe. But is this a realistic scenario? If I write my whole application/library in C, user interaction is part of the application nonetheless. Maybe not what you consider "mission critical" from a program-reliability standpoint. But still mission critical from a user-experience standpoint. Because the whole application is worthless, if it cannot be used.

  • a sounds reasonable. But b and c sound like big expectations where I would doubt that I could fulfill them all the time and then I would disappoint. So these two points sound to me like a lot of pressure.

  • Basically every program that deals with some form of user input will come across strings. Be it to print something to the screen, write something to a file, read something from a file, read something from the user interface (even if it's stdin). Even most non-user-facing tools (daemons, drivers, etc) have to deal with strings often enough, even if "just" for something like writing log or debug entries.

    For me it's hard to come up with any application where I don't need strings sooner or later. Typically sooner than later.

  • I know that C is meant only as a little step forward from assembler. But it was also fine to introduce arrays (which are also not a thing in asm where you only operate on pointers). So why not also add a datatype for THE ONE THING that is used almost everywhere?

    There are thousands of useful things one could argue about if they would make sense in the language or not (and in the case of C I would be totally fine with saying "no" to all of them). But strings IMO are not just some fringe feature that is used here and there. They are mission critical across the board and far too important to be left for libraries.

  • I am always baffled that C didn't ever get a native string type. Strings are used in what feels like 99.99999% of the applications written. Having proper strings that don't require fiddling with pointers on bytes would likely prevent more than 50% of security issues out there.

  • In the age of smartphones with cameras the same could be said about supernatural sightings in general. I mean if there really were ghosts, werewolves, whatever someone would have them on "tape" sooner or later. But for whatever reason (cough) it's only ever hear-say and/or footage in the quality of 1990s security cams. Weird....

  • As long as Signal requires my phone number, it's a hard NO for me. I don't care how good they encrypt if the first thing they do is require one of my most personal identifiers.

    Threema has a very good model in that regard.

  • Enpass uses the open source library sqlcipher (which is an sqlite fork with encryption). So while Enpass as a whole is not fully open source, you can still exfiltrate your passwords with open source tools, should they ever vanish or radically change their business model. You can then use for example enpass-cli.

    That gives me enough confidence to trust in Enpass, since they can't easily hold my data hostage.

  • No it's better: it didn't break for 25 years. But I would have tried to repair it if it broke earlier. I mean... if I really really really wanted I might be able to find the same model somewhere on ebay. But breaking another toaster to repair mine would be a little insane.

    Good news is that the vendor (Krups) vows to keep spare parts available for 15 years. So I will definitely get another toaster from them.