201–210 of 233 posts
Earlier quoted context omitted.
Hating systemd is like hating Hillary Clinton at this point. It's well past time to suck it up and make peace with your next init system/President because the only viable alternative(s) are far worse.
How can any human being be worse than Hillary Clinton?
Earlier quoted context omitted.
I was responding to the "NIH" comment. It's not NIH syndrome if it doesn't matter where it comes from. Philosophy has its place in software engineering but often it's not on a pedestal. That's a philosophy in itself, as is pragmatism or adherence to science. You just happen to disagree with theirs.
Meh. I don't buy the "moderate valuing of philosophy is a philosophy" argument. If everything is a philosophy then nothing is a philosophy. My point is, suckless products can actually suck despite following their "philosophy." It's not only the UI, although strictly adhering to the "UNIX" philosophy has its flaws. No, it's the suckiness of the source code that I'm talking about, e.g. dwm is composed of ad-hoc interna…
Nope, all ideas are philosophy. Just as all matter is made up of atoms. You can't escape philosophy no matter how hard you try.
"FHS sucks" - and then they make an even worse hierarchy. at least modern distros moved all distro-contents to a single /usr (possibly read-only, snapshoted, etc) mount point. #suckmore
I don't know what a good hierarchy is, but with symlinks it should not be so important where the mountpoints are. So why not keep opportunities to split distro contents into convenient directories living under "/"? Also separating writable from read-only content, or having volumes with different performance characteristics, makes sense in certain situations. Why not have these mountpoints directly under "/"?
Earlier quoted context omitted.
The other channel: read the source code yourself before compiling. This actually possible with most suckless projects since they are just a couple of hundred lines of C...
Are you familiar with the Underhanded C Contest? It's possible to maliciously tamper with C code such that you definitely wouldn't spot it with a cursory glance over, and possibly even with careful study.
> "Follow the suckless philosophy" I used to love the idea of the suckless philosophy, until I forked `st` to make it work on OS X by removing globals and by separating the terminal emulator logic from the X11 logic, and asked[1] on the mailing list if they'd be interested in merging my changes. The responses I got made me never want to use any suckless software ever again. [1] http://lists.suckless.org/dev/1408/2336…
This is hilarious
( Also discussed previously at https://news.ycombinator.com/item?id=8819085 and https://news.ycombinator.com/item?id=7261559 ) Interesting points: * http://sta.li/filesystem -- Everything not obviously covered by a fairly simplified hierarchy is put into /sucks , without fixing the problem of /etc still being a grab-bag miscellany. * http://sta.li/filesystem -- /dev being for devices is a "Linux assumption". * http:/…
> http://dwm.suckless.org/ -- "Because dwm is customized through editing its source code, it’s pointless to make binary packages of it. This keeps its userbase small and elitist. No novices asking stupid questions." The worst thing about that attitude is that the suckless programs I tried are full of bugs and usability problems. I actually liked the idea of building simplified core programs, without the bloat and bc…
Earlier quoted context omitted.
It's a complete fallacy that every program that needs crypto needs to link to crypto libraries. Look at how Plan 9 does it, where everything is statically linked, but it's other processes which do crypto. Replace only one binary, and the crypto is fixed for all binaries.
shared object libraries are exactly that, a special case of an ELF executable. Special, in the sense that they are not directly executable by users on the command line, other than that, there is no difference (as regular ELF executables can be compiled as re-entrant, position independent code just like shared object libraries).
Earlier quoted context omitted.
The problem here is that the choice is one extreme or the other, never the happy medium. The extremes are statically linked everything and dynamically linked everything. Bryan Cantrill deplores this part of the design of Go. He decries the fact that rather than sitting on top of a HLL-function-call binary interface, with the portability layer being HLL function calls like read(), write(), close(), socket(), execve(),…
Bryan would have to elaborate an awful lot on the evilness of using system calls to make that a more general argument. (we're not supposed to use the kernel now for some reason?) It looks like it was just kind of a pain in the ass for the Joyent guys because of what they were doing specifically, which was pretty specialized. (there's a mean and almost clinically insane blog post about Go by one of the other Joyent gu…
On Solaris, the system call interface is not a supported public interface, so I made the Solaris port use libc through cgo.
Solaris made the decision that the supported public interface is through libc. That's a fine decision to make if you are the sole vendor of libc. But, that doesn't mean there's anything wrong with different operating systems making different decisions.
On Linux we use the Linux rules, and on Solaris we use the Solaris rules.
I will tell you this though, having done numerous Go ports and having written many Go compiler targets several times, it's much, much simpler to port Go if your target is something that allows static executables and making system calls.
Having done linux/arm64 and solaris/sparc64, I know exactly how much harder is one versus the other.
Earlier quoted context omitted.
I don't know what a good hierarchy is, but with symlinks it should not be so important where the mountpoints are. So why not keep opportunities to split distro contents into convenient directories living under "/"? Also separating writable from read-only content, or having volumes with different performance characteristics, makes sense in certain situations. Why not have these mountpoints directly under "/"?
When distro-packaged content is in /bin and /sbin (and /lib, /usr etc), you can't easily have those 4 directories in a single image that you can atomically handle (upgrade, snapshot, mount, share, etc) and you must have them together on the /. That's why Android has /system, and Linux has /usr now. ( https://www.freedesktop.org/wiki/Software/systemd/TheCaseFor... ). Ideally, and we are getting there, / should be tmpf…