Date: Sat, 22 Nov 2014 16:10:48 -0600 From: will cunningham <willpanther@...il.com> To: sabotage@...ts.openwall.com Subject: Re: changing/fixing the tarballs in the butch This is fairly long and it's just for Linux users like myself who are experienced but not at the level of the Sabotage developers/current users looking through threads like ours above: To wrap this thread up, It may seem Sabotage is flaky and difficult looking at problems of seemingly simple things like getting X working, but in fact what's working, works really, really well, and by the time it gets rounded out will be quite something, and I believe will satisfy the following needs for users like myself: I've become too good at making several Linux distros work without understanding the guts of the system. In my 15 years with it, I can do things like load part of a Gentoo system with a few Use flags set; then change those flags and load the rest, and then add the right overlays among several options until I have a system that does what I want very well. I can also do similar mixings and matchings with Arch and Debian. Therefore, I use several distros for different workflows, knowing one caters better to certain usages, including both their functionality and the communities using them. You can see on this thread how I have a basically absurd way of deleting tarballs and reloading for all kinds of issues, and have no idea why it worked. The other factor are the layers of functionality added by distros. When I started you used these command line tools like ifconfig for network configuration that I recently found out has been pretty much replaced by ip. I hadn't used ifconfig for years because some of the GUI network config tools I've used can't be used in conjunction with ANY command line tools. That is using command line can mess up the settings the GUI automagic uses for its own functionality. Note in this thread John made a point that Sabotage ain't about automagic, and this would be an example of why not to go that route. The effect of this is that I know MUCH less than I should know about what's going on with all the elbow grease I've put into this over the years. That's not so bad as with all these distros I've been able to do wonderful things with Linux. However, any of these distros can make major changes to their architecture, usually adding it as a layer instead of a redesign, and what I use that distro for no longer works, or not easily for my needs. I have no power to get around this because my solutions are already duct tape oriented. Again, not complaining as I'll take the Pepsi challenge with anyone for what I've gotten Linux boxes to do. However, without a middle layer in Sabotage, you can much more easily poke at how everything fits together to take control of your box. Also they're using these libs like musl, busybox from the get go that other distros have to cram into they're current workflow. It'll be a while before this rounds out, but with the embedded world using these libs, the skill of the main folks involved, and the "I've had it" crowd that include shmos like me, this distro is gonna move VERY quickly. I'd say if you're in my "no man's land" level of Linux skill, getting your current set of apps up in Sabotage will lead to a VERY tight system that the journey will result in a level of control you're not gonna get in a cookie cutter distro(again I love 'em and couldn't have gotten here without 'em). Or, come back and take a look every couple months and you'll get to have followed the progress of something that'll work for you soon(in Linux time...) Sorry for the long email, but it'll be helpful for my "too rock for country too country for rock n roll" Linux brothers and sisters at my level. Will On Sat, Nov 22, 2014 at 3:21 PM, John Spencer <maillist-musl@...fooze.de> wrote: > will cunningham wrote: > >> By request I recreated the qt4 build problem to get the build log error. >> Remember this happens when trying to build qt4 before installing xorg. >> Here are the last few lines of build_qt4.log: >> >> [ ... ] > >> Basic XLib functionality test failed! >> You might need to modify the include and library search paths by editing >> QMAKE_INCDIR_X11 and QMAKE_LIBDIR_X11 in >> /src/build/qt4/qt-everywhere-opensource-src-4.6.4/mkspecs/linux-g++-64. >> > > thanks. judging from this, it seems adding a dep on libx11 should probably > be sufficient. > > >> As I move forward tell me other things you want me to try/test as I'm >> approaching this project as not just getting my core apps working but >> understanding/taking control of the OS so I'm VERY interested in how this >> all fits together. For example I'd never heard of mdev/edev but I'm >> reading up on them as I get x pumping, very interesting, and exciting libs >> to be putting into/expanding practical use of. >> > > cool. understanding the system as a whole and being able to modify every > component is exactly what sabotage linux is about. > i didn't have the opportunity to dig into mdev deeply yet, so i'd be glad > if someone could come up with a solution that fully replaces (e)udev for > desktop usage (as laid out in henrique's mail). > unfortunately, other major packages like mesalib start depending on > libudev these days so we may have to write patches to be able to stay > mdev-only... > > --JS > > Content of type "text/html" skipped
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.