Skip Navigation

Posts
5
Comments
357
Joined
3 yr. ago

  • You can snapshot them independently and if you want you can set quotas to size restrict them. Although that latter point defeats one of the advantages of subvolumes over partitions. So really just the ability to snapshot them independently

  • They make a subvolume for every traditional unix partition and the system takes automated snapshots so you can rollback the system to older configurations. I don't actually run opensuse but I've dabbled with it specifically to see how they setup btrfs and you can just tell they're invested in it.

  • I hope one of the things they do is make better use of subvolumes. If you look at the way SUSE handles btrfs it's night and day compared to everyone else.

  • This reminds me of this lol... unrelated but still funny

  • Ooohh nice. That's a beast of a system. Although mine isn't a slouch it doesn't quite compare to that. I have a 7950X, 10TB of total NVMe but with raid it's only 5TB, 64GB of ram...and my 5700 XT.

  • Damn, nice. That's the card I keep telling myself I should upgrade to. I have a 5700 XT and I really like it but I kinda want something newer with more power

  • Just avoid Nvidia to start with?

  • ...I want details. Java is my most used language and I want to know lol

  • I don't get it? When has this ever fixed a bug? Compiler error sure? But a bug?

  • Yeah I agree, they are but I guess what I'm trying to get at is in day to day conversation I use "programming language" as a term for compiled languages hence "real" and "scripting language" for scripting languages. I never say "real" in conversation, just in the context of this post and as I mentioned it's not to say scripting languages aren't good languages, just how I separate them. Your distinction is much better in more comparative dialog such as this

  • I'm aware of the increasing prevalence of JIT, that doesn't change the other markers I listed. Ironically though the language the post is about, CPython still lacks JIT. Also I disagree in general, there are things scripting languages can't do and will never be practical for. It's not that they aren't useful programming languages, that's not what I'm saying but I think having a separate category for them is useful.

  • I personally draw a distinction between "real" programming languages and scripting languages. Scripting languages being languages that are traditionally source distributed. They tend to be much easier to write, run slower, often but not always dynamically typed, and operate at a higher level than "real" programming languages. That's not to say they aren't actually useful or difficult to learn etc. It's not a demeaning separation, just a useful categorization IMO. Not to say the categorization always holds water in all those attributes, luajit is way faster than Java but it does follow the other bits. As someone who loves C there are lots of languages that seem too limiting and high level, doesn't mean they aren't useful tho.

  • Network location sounds impractical for anyone other than power users, maybe USB? Probably not big enough tho. Looking at my system, I have tebibytes of data and don't see how it could work outside of an in place conversion. Ofc I'm already on Linux but if I weren't.

  • The copy across their data for them honestly sounds the most difficult just because of the free space requirements and juggling the partitions. It would only work for users that had 50%+ free space. There is a tool called ntfs2btrfs which may be an option but in place filesystem conversions scare me, maybe it's reliable. Otherwise you have to leave them on NTFS or erase their data which are both less than ideal.

  • I'm so excited for this!!

  • I am aware secure boot doesn't require a TPM, but I've always been confused by its purpose since it's trivial to disable. Makes sense if you use it in conjunction with TPM measurements. I personally encrypt all my filesystems except my /boot which is also my ESP, I use the efistub and that's good enough for loss of device. For a physical attacker with actual skills I'm SOL, it's not that I don't want to protect against it, I just couldn't figure out a reliable way to.

  • By that statement I take it then without TPM you basically can't have truly secure secure boot? Since the password is your protection from secure boot tampering but the TPM is your protection from password tampering

  • The last time I tried enabling a UEFI password clearing the CMOS would clear it. I haven't tried on my latest mobo...but I'm just putting it out there that SOME UEFIs do that

  • I'd argue any solution necessitates secure boot, not just the efistub. If someone is determined enough to modify your kernel they'll be determined enough to modify your bootloader