JustSomeGuy1

About

Banned
Username
JustSomeGuy1
Joined
Visits
60
Last Active
Roles
member
Points
1,172
Badges
1
Posts
330

Reactions

472Like0Dislike121Informative

  • Questions raised about M1 Mac SSD longevity, based on incomplete data

    JustSomeGuy1JustSomeGuy1
    Mostly decent article but some of your important numbers are WAY off. You wrote:
    The cells in an SSD are durable for at least 5,000 read and write cycles in the cheapest Triple Level Cell-based flash memory chips, though more typically around 10,000 cycles for mid-range Multi Level Cell-based chips. Even at the low end of the scale, that still equates to over a decade of usage based on the one complete drive-write per day rating.
    TLC can be 3000 cycles at the high end, less at the lower end, with 1000 cycles typical today. MLC is irrelevant, as there are no MLC consumer drives, nor have there been for quite a while. (Maybe Samsung still sells one? They're going to rare and costly, if they exist at all.

    Typical warrantied DWPD on consumer TLC drives is 0.3. Some go lower. 1DWPD is firmly within the domain of Data Center SSDs, and not even all of those (though some will go to 3DWPD or more).

    All your math after that is wrong because the base number are wrong.

    I've got one of these Macs and I have zero worries about this. Apple uses more flash than anyone else in the world and they're not going to screw this up. They couldn't, really - that much bad flash isn't available. I mean, if they wanted to cheap out they could have gone to QLC, and they didn't.

    OTOH, it's possible that the 8GB machines are so fast even when paging that users don't realize that they're thrashing their disk. That's unlikely to be a real problem for most people, but I guess time will tell. If you are a heavy-duty user and you buy an 8GB machine... you were just asking for trouble. But I still doubt you'll find it.
    h4y3sFileMakerFellermacplusplusjony0Detnatorwatto_cobra

  • Lastpass limiting free users to either computers or mobile apps in March

    JustSomeGuy1JustSomeGuy1
    To all the cheapskates who want this for free: This is not like a word processor asking you to pay a subscription. A good password manager (like 1Password, which I use) is constantly changing their software to accommodate all sorts of crazy password schemes that appear on web sites. Like, for example, the split-between-two-pages username/password setup on some banks (and google). I hate subscription software, but even with out the cloud features, 1Password is earning their fees monthly. As it happens, I use the non-subscription version of 1P, but the next time I upgrade I will probably switch to the subscription version because of the family-sharing stuff they have.

    All that said, I don't know anything about LastPass, good or bad.

    As for Apple's stuff, it's way better than nothing at all, but it's not nearly as good as 1Password. The convenience features in 1P are easily worth $3/month to me.
    maltzwatto_cobra

  • macOS Sudo vulnerability could give root privileges to any local user

    JustSomeGuy1JustSomeGuy1
    Hm, sorry, that last comment might not have been very clear.

    Local access is not physical access. It means having credentials as a user on the machine, and being able to use them. So for example, if you have a user account on a Mac in a different country, and you can SSH to it (or, say, use screen sharing to log in), then that is "local access", even if you're 10,000 miles away.

    Many exploits can give you local access, but not admin privs. And many others can give you admin privs if you already have local access, but not the access. So often attacks will consist of using one exploit (or, sometimes, social engineering) to gain local access, and then another unrelated one to gain root (admin access). The sudo vulnerability gives you the second half of that chain.
    watto_cobraCheeseFreeze

  • macOS Sudo vulnerability could give root privileges to any local user

    JustSomeGuy1JustSomeGuy1
    bulk001 said:
    Thankfully, I am just not important enough for anyone to want to physically access my Mac and hack it. Even if they did, nothing much to see here. Dissidents from places like Saudi Arabia, Iran or China might want to be more careful ... 
    Physical access is not required. You just need "local access". That means you need to be able to run code, or get a shell, and then you have root. It's one half of the holy grail- the other half is gaining non-privileged local access.

    Of course with catalina and big sur things are more complicated because of the protected boot volume. So it's harder to be persistent. But not by much.

    watto_cobra

  • macOS Sudo vulnerability could give root privileges to any local user

    JustSomeGuy1JustSomeGuy1
    auxio said:

    auxio said:
    Yup, and I work with those languages because they're the only way to create native, cross-platform applications (core is C++ code, UI layer is native Swift/Kotlin/language du jour).  Memory management isn't hard once you come up with a model of ownership.  And modern C++ has reference counted pointers as part of the standard library, which is essentially what Objective-C (and, by proxy, Swift) has.

    But anyways, strategies for dealing with memory management is a bit of a digression here.  The point is that, for smaller apps, auditing all sources of input data for buffer overflow/invalid data attacks, any external tools used for validity, etc, isn't a massive undertaking.  But yeah, it seems like this was something missed in a recent change/addition to sudo, not a security hole which has been in the tool for ages.
    Not so. The faulty change is about a decade old. It just required a lot of trickiness to exploit, and nobody noticed it until now.
    A decade is recent when one is talking about tools which are around 40 years old.  A thorough security audit would catch these kinds of holes, which I assumed would have happened at some point in 40 years.  But it may have done before this change.
    I am old enough to remember. But sudo is not that old.
    watto_cobra