[dev] [9buntu] first attempt -bashing needed
Hi all. While waiting for Sta.li to be finnished, I started playing around with a custom ubuntu build that uses plan9port as default user interface on as many levels possible (inspired by some e-mails from Anselm that were lying around on the web). I am basically a total layman on this and I have sort of leant as I went along when I built this... so there are probably a few completely useless configuration setting changes made. The latest live ISO that boots + screendump can be found at http://dl.suckless.org/9buntu/ Stuff that seems to break the system - removing Bash (lots of warninigs after an aptitude purge bash and the boot hangs from the resulting iso) - which was surprising since most upstart things seem dash-controlled. The boot process probably needs some analysis... A README file is is put in the /etc/skel/ directory and a copy should be accessible in every $HOME. In this document I have tried to add all the modifications on configuration files that I have included. I hope that some people on this list will enjoy playing with this. In particular someone with intimate experience with p9p would be appreciated to configure this thing deeper to be even more Plan9-like (factotum as security model?). Flame retardant: This release codename is putting sexy bynny ears on a fat cow - that is 9buntu is probably not up to the high standards of the Suckless community and should at this stage more be looked at as a toy to play with and to explore what is possible and what is not... Enjoy!
Re: [dev] [9buntu] first attempt -bashing needed
On Fri, Jul 30, 2010 at 09:09:08AM +0200, Jens Staal wrote: Hi all. While waiting for Sta.li to be finnished, I started playing around with a custom ubuntu build that uses plan9port as default user interface on as many levels possible (inspired by some e-mails from Anselm that were lying around on the web). I am basically a total layman on this and I have sort of leant as I went along when I built this... so there are probably a few completely useless configuration setting changes made. I'm more than a little surprised that you'd start with such an overgrown, hulking Goliath of a system such as Ubuntu. I think it says enough that it has aptitude, apt-get, apt-cache, dpkg, dpkg-*, dselect, debhelper, and devscripts, just to make a start. Then you have such abominations as Sys-V init to contend with, and the maze of tangled configuration schemes. I would have started with a simpler system like Arch or GoboLinux, or even a BSD. Or if I were feeling a bit sadistic, Gentoo, Source Mage, or Slackware. Debian, though... I'm not that sadistic. -- Kris Maglione Fashion is something barbarous, for it produces innovation without reason and imitation without benefit. --George Santayana
Re: [dev] [9buntu] first attempt -bashing needed
Kris Maglione maglion...@gmail.com writes: On Fri, Jul 30, 2010 at 09:09:08AM +0200, Jens Staal wrote: Hi all. While waiting for Sta.li to be finnished, I started playing around with a custom ubuntu build that uses plan9port as default user interface on as many levels possible (inspired by some e-mails from Anselm that were lying around on the web). I am basically a total layman on this and I have sort of leant as I went along when I built this... so there are probably a few completely useless configuration setting changes made. I'm more than a little surprised that you'd start with such an overgrown, hulking Goliath of a system such as Ubuntu. I think it says enough that it has aptitude, apt-get, apt-cache, dpkg, dpkg-*, dselect, debhelper, and devscripts, just to make a start. Then you have such abominations as Sys-V init to contend with, and the maze of tangled configuration schemes. I would have started with a simpler system like Arch or GoboLinux, or even a BSD. Or if I were feeling a bit sadistic, Gentoo, Source Mage, or Slackware. Debian, though... I'm not that sadistic. Why not Linux from Scratch? Or even Glendix... (Slackware is probably the best realistic bet, due to the simplicity.) -- \ Troels /\ Henriksen
Re: [dev] [9buntu] first attempt -bashing needed
On Fri, Jul 30, 2010 at 05:58:55PM +0200, Troels Henriksen wrote: Kris Maglione maglion...@gmail.com writes: I'm more than a little surprised that you'd start with such an overgrown, hulking Goliath of a system such as Ubuntu. I think it says enough that it has aptitude, apt-get, apt-cache, dpkg, dpkg-*, dselect, debhelper, and devscripts, just to make a start. Then you have such abominations as Sys-V init to contend with, and the maze of tangled configuration schemes. I would have started with a simpler system like Arch or GoboLinux, or even a BSD. Or if I were feeling a bit sadistic, Gentoo, Source Mage, or Slackware. Debian, though... I'm not that sadistic. Why not Linux from Scratch? Or even Glendix... LFS is not a Linux distribution, it's an epithet. (Slackware is probably the best realistic bet, due to the simplicity.) No. Slackware may be relatively simple, but it's no simpler than Arch or GoboLinux, and it has, by far, a weaker packaging system which leads to nothing but headaches. -- Kris Maglione The tragedy of modern war is not so much that young men die but that they die fighting each other, instead of their real enemies back home in the capitals. --Edward Abbey
Re: [dev] [9buntu] first attempt -bashing needed
Yeah... along the way I have sort of figured that stuff ARE very complex (for example, PATH seems to be set and re-set several times during init and login and some environment variables seem very resistant to sticking, which probably means that there is a later event that I have yet to identify) Basically, the only reason I went with a *buntu minimal debootstrap was Anselm's idea of a 9buntu that I came across in some mailing list archive on the web and there are probably tons of people out there that find it good just because it is a *buntu and are willing to try it :). As I mentioned in the earlier message The weird Bash dependency during boot annoys me though... as far as I could see everything was geared towards /bin/sh, which should = dash. I found another interesting debian-type in emdebian grab, which should be busybox-based... might make things simpler if the whole GNU stuff has already been cleaned out once (and since I am on a sidux box, I think I am more inclined to try to mess with that family...). 2010/7/30 Troels Henriksen at...@sigkill.dk Kris Maglione maglion...@gmail.com writes: On Fri, Jul 30, 2010 at 09:09:08AM +0200, Jens Staal wrote: Hi all. While waiting for Sta.li to be finnished, I started playing around with a custom ubuntu build that uses plan9port as default user interface on as many levels possible (inspired by some e-mails from Anselm that were lying around on the web). I am basically a total layman on this and I have sort of leant as I went along when I built this... so there are probably a few completely useless configuration setting changes made. I'm more than a little surprised that you'd start with such an overgrown, hulking Goliath of a system such as Ubuntu. I think it says enough that it has aptitude, apt-get, apt-cache, dpkg, dpkg-*, dselect, debhelper, and devscripts, just to make a start. Then you have such abominations as Sys-V init to contend with, and the maze of tangled configuration schemes. I would have started with a simpler system like Arch or GoboLinux, or even a BSD. Or if I were feeling a bit sadistic, Gentoo, Source Mage, or Slackware. Debian, though... I'm not that sadistic. Why not Linux from Scratch? Or even Glendix... (Slackware is probably the best realistic bet, due to the simplicity.) -- \ Troels /\ Henriksen
Re: [dev] [9buntu] first attempt -bashing needed
On Fri, Jul 30, 2010 at 11:36 AM, Kris Maglione maglion...@gmail.com wrote: On Fri, Jul 30, 2010 at 09:09:08AM +0200, Jens Staal wrote: Hi all. While waiting for Sta.li to be finnished, I started playing around with a custom ubuntu build that uses plan9port as default user interface on as many levels possible (inspired by some e-mails from Anselm that were lying around on the web). I am basically a total layman on this and I have sort of leant as I went along when I built this... so there are probably a few completely useless configuration setting changes made. I'm more than a little surprised that you'd start with such an overgrown, hulking Goliath of a system such as Ubuntu. I think it says enough that it has aptitude, apt-get, apt-cache, dpkg, dpkg-*, dselect, debhelper, and devscripts, just to make a start. Then you have such abominations as Sys-V init to contend with, and the maze of tangled configuration schemes. I would have started with a simpler system like Arch or GoboLinux, or even a BSD. Or if I were feeling a bit sadistic, Gentoo, Source Mage, or Slackware. Debian, though... I'm not that sadistic. I generally agree with the advice you've given above, but disagree with your inclusion of Slackware in the sadistic category. Slackware is very easy to install and configuration is simple and logical (and BSD-style init). It's well documented, as well. Think of it as the OpenBSD of Linuxes (Theo de Raadt would not be pleased with me for this turn of phrase), in the sense that there's little, if any, excess mechanism, and what's there is very well thought out. /Don Allen -- Kris Maglione Fashion is something barbarous, for it produces innovation without reason and imitation without benefit. --George Santayana
[dev] Re: [9buntu] first attempt -bashing needed
Jens Staal writes: Stuff that seems to break the system - removing Bash (lots of warninigs after an aptitude purge bash and the boot hangs from the resulting iso) - which was surprising since most upstart things seem dash-controlled. The boot process probably needs some analysis... Is it based on 10.04? That boot process defies any analysis. Did you manage to remove that thing they call 'plymouth'? Flame retardant: That won't help you much as long as you keep posting HTML mails. ;) -David
Re: [dev] [9buntu] first attempt -bashing needed
On Fri, Jul 30, 2010 at 01:17:49PM -0400, Donald Allen wrote: On Fri, Jul 30, 2010 at 12:04 PM, Kris Maglione maglion...@gmail.com wrote: No. Slackware may be relatively simple, but it's no simpler than Arch or GoboLinux, and it has, by far, a weaker packaging system which leads to nothing but headaches. I'm sorry, but this is simply not true. I have run Slackware for some time now on 5 systems and it's rock-solid and very easy to administer. The package system is simpler, not weaker (I'm a bit surprised at your statement, given that it was made on dev@suckless.org, where simplicity is considered such a virtue; yes, things can be *too* simple, but this is not an example of that; read on). Most of what you need is present by virtue of the core install and just about anything else is available from slackbuilds.org, a very high-quality bit of work. Installing packages from there is simple. The only thing not done for you, apt-style, is making sure everything an app depends on is loaded. But the fact is that, by virtue of the core install, in most cases everything *is* loaded, so missing dependencies are relatively rare. Where something is not part of the core install, it is carefully spelled out on the slackbuilds.org page for the application you are after. You load the dependency, build the slackware package once, and then you can load it on all your systems. It's easy and the underlying package management stuff is very solid. I ran Gentoo, with all its fancy package stuff, some years ago, and it was a nightmare to administer, e.g., dangling pointers to shared libraries needing to be fixed with revdep-rebuild and such. I spend *far* less time tending to my Slackware systems than I did with Gentoo. Another such example of a system that will give you headaches is Arch, with its rolling releases. Arch is *continuously* releasing new stuff, which means it's impossible to test the entire system every time something new appears on the Bleeding Edge. Most of the time this works, but occasionally you will do an update and find your system completely wedged. At that point, you get to learn about booting from the install disk, chroot, and figuring out how to put your system back together, at which you may or may not be successful. I've had this happen three times during the time I ran Arch (maybe six months?) and got sick of it. Read the Arch discussion groups. It's not hard to find messages from people who are in the kind of trouble I just described. This is the reason why systems that are renowned for reliability, like OpenBSD and Slackware, release with a frequency that allows thorough testing of the whole thing. Theo de Raadt and Patrick Volkerding have a lot to teach the world about software QA and release engineering. I never said ‘weaker’ meant simpler. My problem with the Slackware packaging system is its lack of dependency management. I'll agree, though, that the Arch people are not entirely sane. The aggressively rolling nature of the package repo is certainly irritating, but that doesn't have much bearing on the utter simplicity of the packaging system which rivals every other distro I've come across (except perhaps GoboLinux). The same goes for the base system. Most of the configuration is done in one BSD-like file, /etc/rc.conf. /etc/rcN.d are not used. There are no fancy network configuration scripts. The base system is small and, though irritatingly bash-entangled, fairly clean. Beyond that, it's trivial to setup a package repo. One script, repo-add, one directory of packages, and one tarball containing the plain-text, filesystem-based package database. As for upgrades wedging the system... well, it may happen to others, but I've got a lot of tricks up my sleeve, and if I ever have to boot from a CD, something is seriously wrong. But I do often wish that Linuxes would provide something akin to FreeBSD's statically linked /rescue. -- Kris Maglione Correctness is clearly the prime quality. If a system does not do what it is supposed to do, then everything else about it matters little. --Bertrand Meyer
Re: [dev] merp is a loneliness mitigation device written in python and Tk
I have not been able to get wm/irc to work under acme-sac. Is there something I'm missing? As I see now the snarf issue has been fixed one day after this discussion. The inferno host-window is not resizable yet as in i.e. 9vx or acme-sac, so it's still difficult for me to use it. I would also love it if we could let the host manage the windows instead of wm/wm, as in plan9port. Although I don't know whether this would even be possible with the current code base. Just dreaming a little.
Re: [dev] [9buntu] first attempt -bashing needed
I think this is a very nice distribution: tinycorelinux.com It uses busybox and sh scripts for it's base and definitely has no bash dependency. There's only one bad thing that comes to my mind: it has no man pages by default.
Re: [dev] [9buntu] first attempt -bashing needed
On Fri, Jul 30, 2010 at 2:04 PM, Kris Maglione maglion...@gmail.com wrote: On Fri, Jul 30, 2010 at 01:17:49PM -0400, Donald Allen wrote: On Fri, Jul 30, 2010 at 12:04 PM, Kris Maglione maglion...@gmail.com wrote: No. Slackware may be relatively simple, but it's no simpler than Arch or GoboLinux, and it has, by far, a weaker packaging system which leads to nothing but headaches. I'm sorry, but this is simply not true. I have run Slackware for some time now on 5 systems and it's rock-solid and very easy to administer. The package system is simpler, not weaker (I'm a bit surprised at your statement, given that it was made on dev@suckless.org, where simplicity is considered such a virtue; yes, things can be *too* simple, but this is not an example of that; read on). Most of what you need is present by virtue of the core install and just about anything else is available from slackbuilds.org, a very high-quality bit of work. Installing packages from there is simple. The only thing not done for you, apt-style, is making sure everything an app depends on is loaded. But the fact is that, by virtue of the core install, in most cases everything *is* loaded, so missing dependencies are relatively rare. Where something is not part of the core install, it is carefully spelled out on the slackbuilds.org page for the application you are after. You load the dependency, build the slackware package once, and then you can load it on all your systems. It's easy and the underlying package management stuff is very solid. I ran Gentoo, with all its fancy package stuff, some years ago, and it was a nightmare to administer, e.g., dangling pointers to shared libraries needing to be fixed with revdep-rebuild and such. I spend *far* less time tending to my Slackware systems than I did with Gentoo. Another such example of a system that will give you headaches is Arch, with its rolling releases. Arch is *continuously* releasing new stuff, which means it's impossible to test the entire system every time something new appears on the Bleeding Edge. Most of the time this works, but occasionally you will do an update and find your system completely wedged. At that point, you get to learn about booting from the install disk, chroot, and figuring out how to put your system back together, at which you may or may not be successful. I've had this happen three times during the time I ran Arch (maybe six months?) and got sick of it. Read the Arch discussion groups. It's not hard to find messages from people who are in the kind of trouble I just described. This is the reason why systems that are renowned for reliability, like OpenBSD and Slackware, release with a frequency that allows thorough testing of the whole thing. Theo de Raadt and Patrick Volkerding have a lot to teach the world about software QA and release engineering. I never said ‘weaker’ meant simpler. That's true and I didn't say you did. You said it was 'weaker' and I said it's 'simpler' (but not *too* simple). My problem with the Slackware packaging system is its lack of dependency management. My point is that that's a much smaller issue than one might think, because, again, core Slackware installs just about everything you need. So there's hardly any dependency management to be done. And what needs to be done is simple to do. I was as skeptical as you are, until I finally (in desperation, because I couldn't find a simple, unbloated distribution that was reliable) gave it a try. In actual use, it's a simple system to administer. If dwm (WHAT?? No config files? I have to edit C code? Mon dieu!) were a Linux distribution, it could easily look like Slackware. I'll agree, though, that the Arch people are not entirely sane. I love it. Thanks for a good laugh. The aggressively rolling nature of the package repo is certainly irritating, but that doesn't have much bearing on the utter simplicity of the packaging system which rivals every other distro I've come across (except perhaps GoboLinux). I agree that the actual mechanism is excellent. No question about that. It's how they use it that's the problem. The same goes for the base system. Most of the configuration is done in one BSD-like file, /etc/rc.conf. /etc/rcN.d are not used. There are no fancy network configuration scripts. The base system is small and, though irritatingly bash-entangled, fairly clean. Beyond that, it's trivial to setup a package repo. One script, repo-add, one directory of packages, and one tarball containing the plain-text, filesystem-based package database. No argument with all that. As for upgrades wedging the system... well, it may happen to others, but I've got a lot of tricks up my sleeve, and if I ever have to boot from a CD, something is seriously wrong. Most do not have those tricks up their sleeve and they get screwed. The only reason I can see for using Arch is if you make a conscious risk-benefit decision that always having
Re: [dev] [9buntu] first attempt -bashing needed
There is already a 9vx is already included in tiny core, so that was not much to play with :) I also think that the usage cases of tinycore/9vx and a plan9port-based normal distro are different, but I might be wrong. As I said at first, though. The whole thing is mostly for fun. It seems like a system can run quite OK even when the plan9port bin directory is first in the PATH... At the moment I am basically just trying to figure out how to make the plan9port parts more deeply embedded into the system and how to best leverage plan9port stuff as defaults. in response to a previous question: yes it is 10.04 and I have absolutely no idea how the plymoth works, which probably is one of my problems... One reason I looked at debian-based systems at first was that they allegedly had gotten rid of Bash-isms in their init scripts (in contrast to Arch), but since the ISO refused to boot after I removed Bash, I am sort of sceptical about that... Personally, I definitely look forward to playing with Sta.li whenever it is ready. A really cool project! 2010/7/30 hiro 23h...@googlemail.com: I think this is a very nice distribution: tinycorelinux.com It uses busybox and sh scripts for it's base and definitely has no bash dependency. There's only one bad thing that comes to my mind: it has no man pages by default.
Re: [dev] [9buntu] first attempt -bashing needed
Why, you could add plan9port to tinycore, perhaps you could make linux to somehow share the namespace so that it could access all those neat 9p services... I'm currently playing around with inferno on tinycore and will probably package it up soon. But I have no idea how /lack the skills to integrate it cleanly. It will thus be a standard install.
Re: [dev] [dwm] adding WM_WINDOW_ROLE rule
On 27 Jul 2010, at 1:03, Kris Maglione wrote: On Tue, Jul 27, 2010 at 12:53:12AM +0100, Ethan Grammatikidis wrote: On 26 Jul 2010, at 11:48, Rob wrote: There is something that make me sad with dwm, there is a lack of role rules for clients. I explain : clients have instance and name using WM_CLASS, but there is also WM_WINDOW_ROLE which is really important and useful. Pardon me for ranting, but WM_WINDOW_ROLE looks like nothing more than brain-damage from freedesktop.org monks who had to reason away perfectly sound usage of WM_CLASS. I'm upset because this broke a window manager I got on with rather well, but I honestly wonder how close the reasoning behind this issue is to that of the 12th-century monks who wrote down, as a factual example for human life, that a badger when pursued by dogs would bite it's own balls off because it knew that's what the dogs were really after! You would do well to indulge in some cursory research before opining. WM_WINDOW_ROLE predates the freedesktop project by quite a long time and serves an entirely different purpose from WM_CLASS. Nor could it be a freedesktop invention, since by policy they are all prefixed with _NET_. WM_WINDOW_ROLE is an old part of ICCCM that deals with session management, not window identification. I guess I should have focussed my rant differently, but one thing which does not predate fd.o is the practice of setting both class and name (in WM_CLASS) to the same for every window in the application. I'm fairly sure when this practice first caught my attention I looked it up only to read a ridiculous mandate decreeing class and name *must* be set the same (except for capitalisation) on every top-level window of an application. I'm almost certain the same mandate decreed WM_WINDOW_ROLE to be the thing to use to distinguish between different windows of the same application. Some cursory research seems not to be enough to find about anything how to use WM_CLASS etc, or at least 20 minutes of searching turned up nothing for me. -- Kris Maglione Deleted code is debugged code. --Jeff Sickel
Re: [dev] [dwm] adding WM_WINDOW_ROLE rule
On 28 Jul 2010, at 2:24, Kris Maglione wrote: On Wed, Jul 28, 2010 at 11:55:14AM +0200, Uriel wrote: On Tue, Jul 27, 2010 at 1:29 AM, Kris Maglione maglion...@gmail.com wrote: On Mon, Jul 26, 2010 at 11:09:22PM +0100, Anselm R Garbe wrote: I think the right thing to do would be to extend Rule and applyrules() with support for WM_WINDOW_ROLE. However I doubt that many client make actually use of WM_WINDOW_ROLE in a consistent way, which is why I believe there is no great benefit in doing so -- or in other words, yet another proof how hideous X has become ;) Has become? It was so from the start, and I'm really not certain it's possible for it to have become worse. There are certain depts of depravity in software that are impossible to surpass without resorting to Java. I think somehow X managed to surpass its own hideousness without resorting to Java thanks to things like the use of XML by fontconfig, and the auto*hell-ization of the whole X.org distribution. I have to admit that I don't make a strong distinction between XML and Java, but fontconfig really isn't X. It's just an external library like anything else. Can you build or run the X server without fontconfig? I haven't tried in years, but if I remember right the one time I tried, it wouldn't work. And, as for autohell, well, bad as it is, I'm really not sure that it's worse than imake. Indeed. I've not heard anything good about imake, and back when autotools was considerably less mature than it is now I only ever came across one or two packages outside X which preferred imake to autotools.
Re: [dev] [9buntu] first attempt -bashing needed
On 30 Jul 2010, at 7:48, Jens Staal wrote: One reason I looked at debian-based systems at first was that they allegedly had gotten rid of Bash-isms in their init scripts (in contrast to Arch), but since the ISO refused to boot after I removed Bash, I am sort of sceptical about that... If I remember right the announcement that they were removing Bashisms was not made very long ago, I'd be surprised if they'd done a complete job already even if they say they have.
Re: [dev] [dwm] adding WM_WINDOW_ROLE rule
On Sat, Jul 31, 2010 at 02:12:39AM +0100, Ethan Grammatikidis wrote: On 28 Jul 2010, at 2:24, Kris Maglione wrote: On Wed, Jul 28, 2010 at 11:55:14AM +0200, Uriel wrote: I have to admit that I don't make a strong distinction between XML and Java, but fontconfig really isn't X. It's just an external library like anything else. Can you build or run the X server without fontconfig? I haven't tried in years, but if I remember right the one time I tried, it wouldn't work. Yes, you can. fontconfig is purely a client-side library. On the other hand, Xft requires it, and therefore so does everything built on GTK, Qt, FLTK, or Java. More sinister, ghostscript also requires it, and so does xetex (most distressingly). It will be a bad day when I meet Kieth Packard. -- Kris Maglione Insane people are always sure that they are fine. It is only the sane people who are willing to admit that they are crazy. --Nora Ephron
Re: [dev] [9buntu] first attempt -bashing needed
On Sat, Jul 31, 2010 at 02:51:53AM +0100, Ethan Grammatikidis wrote: On 30 Jul 2010, at 7:48, Jens Staal wrote: One reason I looked at debian-based systems at first was that they allegedly had gotten rid of Bash-isms in their init scripts (in contrast to Arch), but since the ISO refused to boot after I removed Bash, I am sort of sceptical about that... If I remember right the announcement that they were removing Bashisms was not made very long ago, I'd be surprised if they'd done a complete job already even if they say they have. It was some years ago, I'm fairly certain. /bin/sh has defaulted to dash for some time now, so any script that doesn't have bash in the shebang line (which none in the base system do, to my knowledge), should run fine without it. -- Kris Maglione Actually I made up the term object-oriented, and I can tell you I did not have C++ in mind. --Alan Kay
Re: [dev] [9buntu] first attempt -bashing needed
On the subject of distros I would like to promote Source Mage as a class above Gentoo and Arch, although it's really not the right distro for this topic. I think of it as a class above the purely rolling update distros because the Source Mage folk found a way to produce a fairly reliable stable version with frequent releases despite having a small team. It's certainly not in the same class as Slackware for reliability, but fixing packages in Source Mage is probably easier than in most distros. I don't think Source Mage is suitable for this particular topic because the base system just isn't very flexible, it has to be all Gnu or you're left with a lot of work adapting stuff. Both the package manager and the init system are written in shell script, that shell is Bash, the supporting utilities probably need to be Gnu coreutils (and of course POSIX grep and sed), and that's not even the whole story. I sometimes wish for a distro with the practices and principles (and camaraderie) of Source Mage but dependant on rc/p9p instead of bash, or at least plain Bourne shell (with a statically linked toolset to make up performance), but Donald reminds me of an overriding concern. On 30 Jul 2010, at 7:47, Donald Allen wrote: My problem with the Slackware packaging system is its lack of dependency management. My point is that that's a much smaller issue than one might think, because, again, core Slackware installs just about everything you need. So there's hardly any dependency management to be done. And what needs to be done is simple to do. After 5 years with Source Mage, which ultimately developed its package manager to what I think is a very high standard, I really feel that a large, comprehensive base system is a better thing than the best package manager there could ever be. I'd even say a large base system is actually suckless, because compared to a many-package distro the large base system needs about the same amount of work to integrate but saves on the work of developing and maintaining the package manager. There are of course issues with the large base, but I really prefer it.
[dev] [dmenu] dinput make error
Hello -
dmenu fails to compile from tip. I got this message:
make: *** No rule to make target `dinput', needed by `all'. Stop.
I removed `dinput` from `all`. It compiled successfully, with one warning:
config.h:11: warning: ‘spaceitem’ defined but not used
I know CLS has been doing a lot of development lately; probably
related to that in some way. I saw that the latest commit merged
dinput and dmenu.
$ hg diff -r 342 -r 343 Makefile
diff -r 8ea0ba2b94ed -r d31226a6ad9f Makefile
--- a/Makefile Fri Jul 30 13:40:56 2010 +0100
+++ b/Makefile Fri Jul 30 22:47:07 2010 -0400
@@ -6,7 +6,7 @@
SRC = dmenu.c
OBJ = ${SRC:.c=.o}
-all: options dinput dmenu
+all: options dmenu
options:
@echo dmenu build options:
Cheers,
--
Andrew Antle
Re: [dev] [9buntu] first attempt -bashing needed
On Fri, Jul 30, 2010 at 02:47:45PM -0400, Donald Allen wrote: I never said ‘weaker’ meant simpler. That's true and I didn't say you did. You said it was 'weaker' and I said it's 'simpler' (but not *too* simple). You certainly implied that I was arguing against simplicity, which I very clearly wasn't. I was as skeptical as you are, until I finally (in desperation, because I couldn't find a simple, unbloated distribution that was reliable) gave it a try. In actual use, it's a simple system to administer. If dwm (WHAT?? No config files? I have to edit C code? Mon dieu!) were a Linux distribution, it could easily look like Slackware. I've used Slackware in the past, and the lack of dependency resolution did indeed cause problems (as it did on similar systems). On most Unices these days (even the loathesome RPM-based systems), just about anything may be installed with one command, or two if you have to search first. You don't even need to think about the dependencies, and you certainly don't have to visit a website. It's especially irritating if, like me, you tend to keep your system clear of Gnome, but occasionally need a Gnome-based program installed, along with its battalion of dependencies, and need to purge the lot afterwards. And, as for dwm, you won't win any points from me on that score. I still think that that's a bad design decision. Most do not have those tricks up their sleeve and they get screwed. The only reason I can see for using Arch is if you make a conscious risk-benefit decision that always having the latest and (presumably) greatest easily available to you is worth the risk of occasionally having to glue your system back together or restore it from a backup. Don't care about most people, frankly. That being said, I've never my Arch system wedged in the past three years or so, though I have had some more minor yet annoying problems relating to their rolling packaging. But I do often wish that Linuxes would provide something akin to FreeBSD's statically linked /rescue. I will avoid wasting network bandwidth by going on a FreeBSD rant. Suffice to say that I've tried 7.* and 8.* and I don't think that system is fit for the desktop. Its reputation for solidity was made on servers and I'm sure it's fine there. But, for example, the usb layer was totally broken in 7.*, they re-wrote it for 8.* and it still doesn't work correctly. There were other problems, too. FreeBSD has gone down hill over the years, no doubt. I used 4-STABLE for nearly 10 years, and only ever upgraded to 5-STABLE when 4 wouldn't run on my laptop. My firewall ran 4-STABLE for some years after that, and my desktop eventually got 6-STABLE when it was released. But after that, I didn't bother to install it on my new laptop, because things were clearly not moving in the right direction. OpenBSD is a different story. It is a very high quality system. But -- it's noticeably slower than Linux, it doesn't have real SMP support (just one Giant Lock around the kernel), it doesn't have unified buffer cache support, and its hardware-support repertoire is not nearly as big as that of Linux. But it's perfectly usable as a desktop system, if it supports your hardware (and you don't care about Flash, which many do not), very secure, very well documented and very bug-free. It's also simple to administer, because the config setup is sensible and everything is clearly documented. The big down-side, for me, is that the developer community has taken on Theo de Raadt's personality. A friend of mine said to me recently the only reason for running OpenBSD is if you like being insulted. Perhaps an over-statement, but there's some truth to it. I just don't like the way they treat people and so I won't use their stuff (because I like to give financial support to people who donate their time to making software that I use, and I just didn't want to send these guys any more money). Too bad, because in the right setting, it's a great piece of work. I don't believe that OpenBSD is noticably slower than Linux, at least not for servers. It consistently performs well on benchmarks compared to Linux and the other BSDs, and I know that the OpenBSD devs brag about their network device support compared to bothe Linux and the BSDs. They focus on server support, and they do that well. And, well, Theo is an asshole, but I rather like him. He's a rather welcome antidote to Ulrich Drepper at any rate. It's odd, though, that OpenBSD being so focused on security and stability, that DJB of all people ditched it for FreeBSD because of its lack of the latter... -- Kris Maglione One does well to put on gloves when reading the New Testament. The proximity of so much uncleanliness almost forces one to do this. --Friedrich Nietzsche
Re: [dev] [9buntu] first attempt -bashing needed
On Sat, Jul 31, 2010 at 03:35:46AM +0100, Ethan Grammatikidis wrote: On the subject of distros I would like to promote Source Mage as a class above Gentoo and Arch, although it's really not the right distro for this topic. I think of it as a class above the purely rolling update distros because the Source Mage folk found a way to produce a fairly reliable stable version with frequent releases despite having a small team. It's certainly not in the same class as Slackware for reliability, but fixing packages in Source Mage is probably easier than in most distros. The only reason I won't use Source Mage is that it doesn't do binary packages. I used BSD for a lot of years, and tended to build from source for a lot of those years, even on slow machines. But I eventually started using pkg_add -R, and now I'm just not willing to build my entire system from source anymore. It's certainly nice to have a package system that makes building from source easy (I still do it often enough), but it's frankly insane for it to be the only option. -- Kris Maglione Advertising may be described as the science of arresting human intelligence long enough to get money from it.
Re: [dev] [dmenu] dinput make error
Darn, I hoped no one would notice my mistake until I got back to a computer
with internet access. I'll fix it tomorrow; I have a big patch ready.
As for the spaceitem warning, just update your config.h by removing it -
it's not in config.def.h.
(Sorry for the html. Android.)
Thanks,
cls
On Jul 31, 2010 3:47 AM, Andrew Antle andrew.an...@gmail.com wrote:
Hello -
dmenu fails to compile from tip. I got this message:
make: *** No rule to make target `dinput', needed by `all'. Stop.
I removed `dinput` from `all`. It compiled successfully, with one warning:
config.h:11: warning: ‘spaceitem’ defined but not used
I know CLS has been doing a lot of development lately; probably
related to that in some way. I saw that the latest commit merged
dinput and dmenu.
$ hg diff -r 342 -r 343 Makefile
diff -r 8ea0ba2b94ed -r d31226a6ad9f Makefile
--- a/Makefile Fri Jul 30 13:40:56 2010 +0100
+++ b/Makefile Fri Jul 30 22:47:07 2010 -0400
@@ -6,7 +6,7 @@
SRC = dmenu.c
OBJ = ${SRC:.c=.o}
-all: options dinput dmenu
+all: options dmenu
options:
@echo dmenu build options:
Cheers,
--
Andrew Antle
Re: [dev] [9buntu] first attempt -bashing needed
On Fri, Jul 30, 2010 at 12:04:45PM -0400, Kris Maglione wrote: On Fri, Jul 30, 2010 at 05:58:55PM +0200, Troels Henriksen wrote: No. Slackware may be relatively simple, but it's no simpler than Arch or GoboLinux, and it has, by far, a weaker packaging system which leads to nothing but headaches. slackpkg is included in Slackware 13 so it is a lot easier to use it now. With it Slackware package system can be compared to OpenBSD: you can always build a list of extra packages that you have created and remove packages that you don't need. Official packages can be updated in one command. If you want to use Slackware with static linking, you don't need to track dependencies, so it is very good choice for a base system.
Re: [dev] merp is a loneliness mitigation device written in python and Tk
On 30 Jul 2010, at 7:09, hiro wrote: I have not been able to get wm/irc to work under acme-sac. Is there something I'm missing? As I see now the snarf issue has been fixed one day after this discussion. The inferno host-window is not resizable yet as in i.e. 9vx or acme-sac, so it's still difficult for me to use it. I would also love it if we could let the host manage the windows instead of wm/wm, as in plan9port. Although I don't know whether this would even be possible with the current code base. Just dreaming a little. Being a dreamer myself I had to have a little think about this. :) Window systems don't generally get on at all, but if you do it right they don't have to. For instance X11 on OS X is really not integrated into the host window system at all. Top level X11 windows use something from the host, but none of the standard decorations or features. You then have the option of using an X11 window manager which provides the _look_ of host system and which hooks into the host just enough so that minimised windows go to the dock and the window list in the Mac menu bar works. Apart from clipboard integration (only textual, which Inferno has anyway) that's about it. I expect much the same could be done with Inferno on either OS X or X11. I guess you would need a new device and would almost certainly need to replace wm/toolbar. Under OS X replacing wm/wm need only be a low priority, but under X11 even virtual desktops would be an issue for it. Perhaps Acme SAC's resize code would be of use in modifying or replacing wm/wm.
Re: [dev] [dwm] adding WM_WINDOW_ROLE rule
On 31 Jul 2010, at 3:33, Kris Maglione wrote: On Sat, Jul 31, 2010 at 02:12:39AM +0100, Ethan Grammatikidis wrote: On 28 Jul 2010, at 2:24, Kris Maglione wrote: On Wed, Jul 28, 2010 at 11:55:14AM +0200, Uriel wrote: I have to admit that I don't make a strong distinction between XML and Java, but fontconfig really isn't X. It's just an external library like anything else. Can you build or run the X server without fontconfig? I haven't tried in years, but if I remember right the one time I tried, it wouldn't work. Yes, you can. fontconfig is purely a client-side library. On the other hand, Xft requires it, and therefore so does everything built on GTK, Qt, FLTK, or Java. More sinister, ghostscript also requires it, and so does xetex (most distressingly). It will be a bad day when I meet Kieth Packard. Must have been the libraries that wouldn't build, but I'm sure it was core X.org. I don't think it was Xft, but if it was then some essential lib had deps on Xft I didn't expect.
Re: [dev] [9buntu] first attempt -bashing needed
On 31 Jul 2010, at 3:54, Kris Maglione wrote: On Sat, Jul 31, 2010 at 03:35:46AM +0100, Ethan Grammatikidis wrote: On the subject of distros I would like to promote Source Mage as a class above Gentoo and Arch, although it's really not the right distro for this topic. I think of it as a class above the purely rolling update distros because the Source Mage folk found a way to produce a fairly reliable stable version with frequent releases despite having a small team. It's certainly not in the same class as Slackware for reliability, but fixing packages in Source Mage is probably easier than in most distros. The only reason I won't use Source Mage is that it doesn't do binary packages. I used BSD for a lot of years, and tended to build from source for a lot of those years, even on slow machines. But I eventually started using pkg_add -R, and now I'm just not willing to build my entire system from source anymore. It's certainly nice to have a package system that makes building from source easy (I still do it often enough), but it's frankly insane for it to be the only option. Aye, they have finally started on a binary 'grimoire', after years of it would be nice. :) I don't know how much is in it, certainly firefox, almost certainly gcc since people need a binary gcc to fix their system more often than any other package. Last I checked I thought the binary grimoire was growing rapidly but I don't remember how big it was.
Re: [dev] [9buntu] first attempt -bashing needed
On Fri, Jul 30, 2010 at 10:49 PM, Kris Maglione maglion...@gmail.com wrote: On Fri, Jul 30, 2010 at 02:47:45PM -0400, Donald Allen wrote: I never said ‘weaker’ meant simpler. That's true and I didn't say you did. You said it was 'weaker' and I said it's 'simpler' (but not *too* simple). You certainly implied that I was arguing against simplicity, which I very clearly wasn't. Again, that's not what I said nor what I intended. You stated that Slackware's package management was weaker than Arch's or GoboLinux and that the lack of package management leads to headaches. The implication that I took from that was that you thought it was *too* simple and that was the point with which I took issue. That's very different than my implying that you were arguing against simplicity, which I was not. I think we would agree on the principle that things should be as simple as they can be, but no simpler. We're just disagreeing on how to apply that to Slackware, where the line is. I was as skeptical as you are, until I finally (in desperation, because I couldn't find a simple, unbloated distribution that was reliable) gave it a try. In actual use, it's a simple system to administer. If dwm (WHAT?? No config files? I have to edit C code? Mon dieu!) were a Linux distribution, it could easily look like Slackware. I've used Slackware in the past, and the lack of dependency resolution did indeed cause problems (as it did on similar systems). On most Unices these days (even the loathesome RPM-based systems), just about anything may be installed with one command, or two if you have to search first. You don't even need to think about the dependencies, and you certainly don't have to visit a website. It's especially irritating if, like me, you tend to keep your system clear of Gnome, but occasionally need a Gnome-based program installed, along with its battalion of dependencies, and need to purge the lot afterwards. I don't use Gnome or KDE, for that matter. Just a window manager (dwm -- though I'm testing i3 now -- dmenu, and something to display the date-time). What you cite above is not a problem for me. The one app that I use that needs chunks of Gnome is Gnucash. A shell script or two got me the slackware packages for the dependencies, they get installed on all my systems, and then the same for the Gnucash package. Look, the world's full of trade-offs. I want a minimal distribution (which is what originally attracted me to Arch), but it needs to be reliable. I don't want to spend my time fighting with computers. If I did, I'd run Windows. Arch didn't fill that bill for me. Slackware does. The small (and for me it has been small; virtually all of it was for Gnucash) amount of extra work I've had to do was well worth it to me, given how solid and well-done this system is and how well-suited it is to my requirements (more so than anything else I've tried). Apparently, you don't see it the same way. Vive la difference. And, as for dwm, you won't win any points from me on that score. I still think that that's a bad design decision. Disagree completely. It works beautifully for a (small) target audience willing and able to hack a C header file. For those who won't or can't, there are other choices, even from suckless. Most do not have those tricks up their sleeve and they get screwed. The only reason I can see for using Arch is if you make a conscious risk-benefit decision that always having the latest and (presumably) greatest easily available to you is worth the risk of occasionally having to glue your system back together or restore it from a backup. Don't care about most people, frankly. That being said, I've never my Arch system wedged in the past three years or so, though I have had some more minor yet annoying problems relating to their rolling packaging. I'd argue you've been lucky. It's also possible to smoke a pack of Pall Malls every day and live to be 100 (the great ragtime composer, Eubie Blake, did exactly that). But I do often wish that Linuxes would provide something akin to FreeBSD's statically linked /rescue. I will avoid wasting network bandwidth by going on a FreeBSD rant. Suffice to say that I've tried 7.* and 8.* and I don't think that system is fit for the desktop. Its reputation for solidity was made on servers and I'm sure it's fine there. But, for example, the usb layer was totally broken in 7.*, they re-wrote it for 8.* and it still doesn't work correctly. There were other problems, too. FreeBSD has gone down hill over the years, no doubt. I used 4-STABLE for nearly 10 years, and only ever upgraded to 5-STABLE when 4 wouldn't run on my laptop. My firewall ran 4-STABLE for some years after that, and my desktop eventually got 6-STABLE when it was released. But after that, I didn't bother to install it on my new laptop, because things were clearly not moving in the right direction. Agreed!! OpenBSD is a different story. It is a very high
