[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAFPCfQzozAsFMoaCyiW5EFVjSXfpU2tT=nbW2tAVcZ7QKpXGcA@mail.gmail.com>
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.
