lldb ...

[René J.V. Bertin]

On Friday September 09 2016 13:59:50 Jeremy Huddleston Sequoia wrote:

>> As an aside, I'd be in favour of setting up MacPorts such that ${prefix} is owned by a ${macports_operator} who's got admin rights (= myself) and reserve use of actual root privilege to those few ports that require setting up SETUID/GETUID executables or that need to create users or groups.
>
>YES!  We should not be needing to do such things as root.  That is 100% true, and I am in full support of moving away from that and only using root for activate.  We should be able to use fakeroot (https://wiki.debian.org/FakeRoot) for destdir.

Why would we even require root for activation, except for the few exceptions that install items outside of ${prefix} or that install SETUID/GUID to another user/group? It's already an implicit requirement that the MacPorts operator (the user who installs it and ports) be an admin user, and once ${prefix} is created there's no need for it and anything below it to require root access.

I've run MacPorts for years like that, and only moved away from it very recently because I made an error (forgot a ${destroot}) that caused pollution of my ${prefix}. Of course the protection I gained with that move is very relative, and depends on the destroot step NOT being run as root.

Would fakeroot work on OS X, including on versions that predate SIP/rootless? Funny btw, I trust Debian to have written a safe fakeroot implementation, but if you read the wiki you get the impression it's a dangerous little hacking tool, which could be misused easily e.g. to make any executable setuid root...


>It's quite a bit more complicated than that.  First off, these settings are on by default but can be configured through SIP flags, boot args, etc.  There >are also many types of restrictions that have different effects.

Hah, TMI :)

>Because of the CS_HARD restriction, all libraries that are linked against require a valid code signature.

Out of curiosity, if an IDE were to use a proper lldb debugger implementation that uses liblldb rather than an existing external driver (lldb-mi, python, ...), will all of the IDE have to be signed or is that still a requirement only for the debugserver utility?

>This is because you likely already launched the executable, so the old signature for that particular inode was already cached.  If you copied debugserver somewhere else and then copied it back, it would have addressed the problem for you.

Presumable, but that's the point, it didn't. I tried that manually, but shouldn't reinstalling via MacPorts have taken care of that too? Because that does
- delete the previous copy
- install a new, unsigned copy
- sign the new copy

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.

>> I'm concerned about every step that takes OS X away from a regular Unix (underneath a nice and truly integrated desktop) and towards a locked-in OS like iOS.'
>
>Well macOS is still UNIX.  We continue to verify that through continual conformance testing.  I don't expect that to ever change.

iOS used to be a Unix too. I don't know whether one can still think of it as that, though. But anyway that wasn't my real point. For me, "regular Unix" carries connotations and associations of an open developers' OS of choice that date back to the late 80s. 
Something "breaks" in that perception of things when we get to the point where you have to ask (or pay) for a certificate to install and run even your own code even if it stays away from system areas. That's exactly why I never got into iOS development, too.

>FWIW, I really love my 2015 rMBP.  I was a holdout staying on the pre-retina ones so I could continue to have a DVD drive and a 2.5" drive bay, but I finally gave that up and am really glad that I did because the newer SSDs are blazing fast.

Going completely OT here :)

I guess that if I had the money I might be less sceptic, but the fact is that I simply cannot afford to dump the amount required to replace my current "mobile workstation" mid 2011 13" MBP with something comparable from Apple (or anyone else if I want to stick to an i7). It's got a 1Tb Hitachi HDD which is plenty fast for me (and cost me all of 80€), evolved from 4 to 8 to 12Gb RAM as prices dropped and lacks an expensive LCD screen that won't outlive the computer itself. I've got a 1080p 21" external screen that is largely sufficient. When I go mobile I either can make do with the low internal resolution, or I have another external screen.
That large disk allowed me to make 4 partitions and keep large working directories like Qt5's source+build+destroot around without running out of space. I wouldn't feel comfortable at all with a non-replaceable SSD of a comparable size knowing its cost and that rapidly evolving tech is almost by definition of largely unknown reliability. I presume you run additional storage over USB3; can you vouch that you get comparable I/O speeds out of that as you got from big internal spinners, regardless of the overal CPU (and bus) load?

My current MBP cost me about half a month's salary when I bought it (her? :)). That was an investment because I knew my contract was ending with little chance of finding a new job easily (prediction come true ...), justified by the fact that my previous G4 Powerbook had given me 6 years of reliable service despite rough handling. Even if I were still earning a salary I'd really hesitate to spend significantly more on a system with basically no user-replaceable off-the-shelf parts.
As an anecdote from the dark side: I also have an Acer Netbook that's been running Linux since 2012 and that cost me less than 450€ with the upgrade to 8Gb and a replacement HDD because the original failed a few months ago (running ZFS I lost only a single worthless file). It feels feeble but it can actually take a lot of abuse (and the keyboard is frankly more robust than the Apple ones). I only replaced it with another sub-400€ 11" notebook (by Clevo) because it really became too slow for what I was doing with it. I've already seen that Clevo also have a 13" line that can be configured to correspond almost exactly to what I look for, except for running OS X (but for I'd say less than half the price of a new MBP).

R.