Can't hide the stars from Github itself though. Keeping as much preference data away from social networks as possible is not an unreasonable stance, IMHO.
I mean spaces where we put things belonging to a name. When I look at the bin folder on my system, I am mostly: "what the heck are these?" If each of these binaries were in a folder, for example "Python" (that's the namespace), together with their sources, configuration, documentation, etc., I could easily explore this small aspect of the system.
some linux distributions, such as GoboLinux (which, i think, was mentioned elsewhere in the comments, too), do this.
from gobolinux.org:
> GoboLinux is a modular Linux distribution: it organizes the programs in your system in a new, logical way. Instead of having parts of a program thrown at /usr/bin, other parts at /etc and yet more parts thrown at /usr/share/something/or/another, each program gets its own directory tree, keeping them all neatly separated and allowing you to see everything that's installed in the system and which files belong to which programs in a simple and obvious way.
Note the (2004). Some things were removed/added/changed (/initrd, /sys, several things in /usr). Check <https://linux.die.net/man/7/hier> for an up-to-date resource.
Could you elaborate? To me there seems extremely little overlap there (I'm familiar with both the procfs and linux's ptrace APIs, but not OpenBSD's ptrace).
Interesting. I didn't know much about /proc's original design intent, and Wikipedia indeed says "the design of procfs aimed to replace the ptrace system call used for process tracing", citing https://lucasvr.gobolinux.org/etc/Killian84-Procfs-USENIX.pd... ("Processes as Files", USENIX 1984)
There are two "kinds" of panics: those initiated by the Go runtime, and those initiated by the program author, though technically there isn't a distinction. When you access an array out of bounds, the Go runtime initiates the panic. On the other hand, for a condition that the program should hold but doesn't, the program author should initiate the panic. For example, in the exhaustive switch below, reaching the default case means that either you have somehow incorrectly allowed the construction of an invalid token value earlier in your program, or you have missed to account for a valid token value in this function.
func (t token) symbol() byte {
switch t {
case add: return '+'
case sub: return '-'
case mul: return '*'
case quo: return '/'
default: panic("unknown token")
}
}
Errors are different. For example, url.Parse returns an error if its input string is an invalidly formatted URL.
That is a great example of a reason to panic. There is nothing you can do at that point but return an error or panic, and something has really gone wrong if you are pulling bad tokens out of a hashmap you made yourself, tonthe point I think you should panic. Sadly, almost all the panics I see coming out of rust crates are because someone called unwrap instead of handling the error case.
That is a terrible example of a reason to panic. If the programmer believes the list to be exhaustive and it isn’t, then the programmer is wrong. So raise an exception and let the caller decide what to do with it. But don’t punish the caller by forcing it to crash just because you made a mistake as a programmer.
(in go, "raise an exception" means "return an error.")
error values are meant to represent expected, unsuccessful conditions—internal properties of the program—during the program's execution. for example, looking up the address for a domain name is an operation that can be expected to fail at times, and an error is appropriate here.
errors in go are not meant to represent properties external to the program, such as mistakes by the package author or documented incorrect usage of the package by the package user. in go these are panics.
perhaps other languages use exceptions for both but that conflates.
I moved from Homebrew to MacPorts on a local, personal-use Intel Mac.
I chose Homebrew some years ago when I was not as experienced a programmer, because it was more popular than MacPorts. When I revisited the choice last year, I chose MacPorts.
On Homebrew:
* It has a Frankenstein permissions model; for example "brew install" writes files into /usr/local/* with your regular user account as the owner of the files.
* The permissions model means that Homebrew-managed parts of the system become a single user system, as far as I know. Multiple user accounts on the same Mac can't easily use Homebrew, as far as I know, and I dislike software with such design choices.
* Noisy messages and undesired colors in the command line output.
These issues are absent in MacPorts. Overall, MacPorts appears more mature and more Unix-like than Homebrew.
The cons of the move are that not all the packages I want are available in MacPorts. However I have sufficient experience now to package crucial missing ones into MacPorts.
> permissions model means that Homebrew-managed parts of the system become a single user system, as far as I know. Multiple user accounts on the same Mac can't easily use Homebrew
The single user thing is problematic in a corp env where you may have a mgmt admin user and a non-admin dev user.
Long story short, temporarily have the dev user be an admin, install brew, drop the admin priv. That works for cli tools (which is actually great), but may not work for /Applications unless you change its ownership. Used to be OSX effectively (not literally) merged ~/Applications and /Applications, but now in MacOS the security sandboxing and entitlements don't like that.
This is Debian 11 attempting a reboot as a regular user:
$ reboot
Failed to set wall message, ignoring: Access denied
Failed to reboot system via logind: Access denied
Failed to open initctl fifo: Permission denied
Failed to talk to init daemon.
$
But shutdown/reboot/halt could well check the pre-requisite user id (or other kinds of permissions needed for you to be allowed to reboot/stop the system) before invoking all those subsystems which all run on as if they were going to succeed when they are not.
And would it not be very weird if 2/3 managed to run, sending wall messages to everyone, preventing new logins and so forth but then not rebooting? Or not preventing new logins, not sending the message but still reboot?
All of those "corner cases", including the quoted permission denied messages, could well be prevented but are not.
