lldb ...

[René J.V. Bertin]

On Saturday September 10 2016 08:45:38 Jeremy Huddleston Sequoia wrote:

> Yes, for most cases we would probably not need root access at activation time, but for those cases you just listed, we would.  We could do a pass over the bom to determine if root access is needed or not.  The UI for handling such a case is non-trivial.  Do we prompt once for the entire run of the process or escalate permissions for each port we encounter and then drop them again?  If 8 ports are being installed and 4 require root, that's not a good user experience to prompt for password 4 times.

I think it'd be up to the port to indicate if it requires root privileges during the destroot. This is (implicitly) what happens with ports that create a new user or group; there's a phase that requires root (configure, I think).

How's that handled at the UI level? I'm guessing that the phase will simply fail for the port(s) that don't have the appropriate privileges.


> > I understand that the certificate catching is coupled to the file's inode (whatever that is under HFS+), and the new copy indeed had a new inode. And yet another inode after signing it.
> 
> If you can reproduce this, please let me know and file a radar with details and let me know the number, so I can followup internally on it.  I haven't seen such cases.  The only issue I'm aware of is with overwriting an existing file (eg: using cp instead of mv).

To make this reproducible I'd probably be looking at the following sequence?
1) copy a binary from some original and ad-hoc sign it
2) delete it
3) copy the original once more and sign it with another certificate

Correct me if I'm wrong, but I think that's what a `port -n upgrade --force` boils down to if signing is done in the post-activate, no?
Is there any reason to expect that the certificate used in 3) must be a new one not yet used to sign other executables?

> iOS was never branded as UNIX.  It is UNIX-like, but it was never UNIX.

AFAIK it is or used to be based on OS X, evidently without the userland but with a comparable kernel. Was that just a shortcut way of thinking of things?

> I've got an internal 1TB SSD and it is more than enough for most of my needs.  I mainly use USB for thumbsticks and my camera.  In such cases, the throughput is bottlenecked on the attached device, not the bus.
> 
> That being said, my server machine is a 2012 MacMini, and I've got a DroboMini and a LaCie RAID attached to it via thunderbolt, and the throughput and latency are more than adequate for my demanding needs.

Thunderbolt external disks and 1TB SSDs are simply out of my budget.

>  For folks like you and me, it might be a minor concern being limited to 1TB, but we can certainly use an external SSD or an SDXC to increase storage as needed in the future.

I see it as more than a minor concern. Not because I expect I'll ever need more than 1TB internal space, but I would certainly not feel comfortable when I know I cannot replace something that can fail that easily and unpredictable as an SSD (or HDD for that matter). I don't recall but it's quite likely too that I replaced the HDD in my current MBP with a Hitachi as soon as I received the machine.
My only experience to date with SSDs was as an external. Connected over FW800 (the fastest bus I had at the time) showed 0 gain over a good HDD ... and the whole thing died catastrophically after not even 4 months. 

FWIW, that Clevo notebook I mentioned has an internal 2.5" disk (came with an SSHD) but even at its price point it has a fashionable slot to add an SSD. That's the kind of approach I like: adding expansion options instead of removing them.

R.