Re: [dev] app locations?
On Mon, Oct 17, 2016 at 07:03:59PM +0300, Ali H. Fardan wrote: > /bin - for binaries that come with the system So they never get maintained with a package manager? Sounds like a really weird way of doing things. If you bootstrap with a tarball, the distinction becomes meaningless once you've updated packages with a package manager. Some of us currently use package managers that bootstrap the system though. > /usr/local/bin - is for binaries installed by the user without using the > package manager So /local/bin now? > */sbin - is nonsense Details? Do you mean because it should be root:root 700, but everybody has it in their $PATH anyway? Or do you mean because permissions on the binaries themselves is good enough? Or because protections on the resources accessed by the binaries is good enough? Or because you just don't like splitting things into four?
Re: [dev] app locations?
On Mon, Oct 17, 2016 at 05:56:56PM +0200, Laslo Hunhold wrote: > There is no reason to support this ancient concept of a separate > /usr-partition. The age of tape-drives is over, there is no need for > it. And I must admit, it really makes things complicated in a lot of > respects. NFS mounts maybe, who want to have a /bin and /sbin in case their NFS mount freezes still in the age of NFSv4? Not a minority this distro should support though, right? Your /usr that big? Possible but… > I hear arguments that you put user-specific applications into /usr/bin > and general applications into /bin, Anything even remotely important other than the above? > however, what kind of joke is this distinction anyway? What's the argument you're making? That it's ridiculous? *HOW*, not just it's ridiculous again and again on the mailing list. > In my opinion, we should also get rid of /sbin. We are entering the > age where we don't have "root" and "normal" users. Educational institutions and libraries, not that I think many of those oft backwards institutions will choose this distro.
Re: [dev] app locations?
> Throw away your Linux-ish idea of "everything is a package", What the heck is wrong with that? And why argue against, if you mentioned it in the first place? I was just pointing out an inconsistency in how it was presented, as if /bin wasn't managed by the package manager. Geez. > and take a look at BSD systems, they provide tarballs for updating > your system, Whole system tarballs? So we're doing stable releases or big lumbering version changes? If so, great. I'm out of here. > which are maintain by the mainstream distribution, and are not under the > risk of breaking because of a silly package manager mistake. That's not an argument. You can break things with the other methods. You blaming the package manager, or are you confusing it with all the libpng's ABI or libsfml's ABI changed and half my packages are on the old version bullshit? > > Some of us currently use package managers that bootstrap the system > > though. > > I have nothing against this, but I prefer the BSD way of doing it. Can we just say "unpack a tarball?" [, chroot, configure]?
Re: [dev] [stali] The stali way to wifi
On Tue, Oct 18, 2016 at 07:46:14PM +0200, Kamil Cholewiński wrote: > not running stali (Debian here), but should work all the same. > I simply put wpa_supplicant and dhclient under runit: dhclient? I thought that was, *relatively* speaking, looked down on?
Re: [dev] [stali] Boot time (was: The stali way to wifi)
> On 10/21/16 11:48, Anselm R Garbe wrote: > > I've been arguing against MS Windows' misdesign to reboot the system > > on configuration changes. But from a stali perspective I kind of > > prefer rebooting the system for the prize of avoiding a daemon or > > runlevel management. It's simpler and it also makes you "configuring" > > a system less. > > > > "Configuring" is always an indicator of suckiness. If you're that worried about speed though (and you don't seem to be) or just want to skip crappy firmware, you could try to kexec, since you'll probably disagree with the reference implementation build system at least. But I suppose that that's a very low priority now, right? On Fri, Oct 21, 2016 at 12:19:52PM +0200, Paul Menzel wrote: > I totally agree. Same goes for suspend to RAM in my opinion. They're not comparable when you've got quite a bit of work going on. There are likely enough “edge cases” to that thinking. And besides, how hard is it to just echo mem to /sys/power/state? Who said suckless use cases need userspace support? I'd leave that in the kernel at least, because it's not an unlikely use case, though I already build my own kernels with lots of the junk stripped anyway… If all I want to do is flip my laptop closed to go from the kitchen to the bedroom…
Re: [dev] Collecting sins of Apple
On Tue, Oct 25, 2016 at 12:53:36PM +0200, Anselm R Garbe wrote: > To bring it to one sentence, Apple is about providing their stuff as > incompatible as possible with all non-Apple stuff. […] proceeds with > the keyboard layout, Unh, other than swapping Mod1 and Mod4, they've usually been the most consistent layout and non-minuscule keys unlike just about every other laptop manufacturer out there selling *consumer* grade keyboards. And is there even really any agreement on what a laptop keyboard layout should be? They've just not been consistent in key switch quality. > goes on with accessory cable adapters and doesn't end with their > software stack consisting of propietary Apple-only protocols Thunderbolt in practice: implemented in software rather than firmware, no hotplug for a long time if at all ever. Which other consumers even see it? signature.asc Description: PGP signature
