Brief look at FigOS and upgrade to ascii

According to the “officially official” devuan forum administrator, FigOS is not a Devuan derivative because it is also based on Refracta and another distribution (puppy).  I run FigOS live, the latest version 2.6 and I really was looking for the puppy aspects of it, since it is not Devuan, which I have been keeping a distance of.  I am not too much of a fun of iceWM and gdm and xfce4 stuff, so I transfromed every desktop part into my familiar openbox.  I left everything else in tact.  It installed as reliably and easily as anything utilizing the Refracta tools marvel.  Nothing else works as reliably as this installer. 

The active repositories in this 2.6 version are all devuan, actually the older ones before pkgmaster.   No other repositories that were active were found, and nothing from puppy.  As far as we can tell at least.  There were a few inactive repositories of non-systemd software that have yet to be explored.  There were also a few “local” programs stored in /usr/local/bin that seemed very useful in any distribution and one can be surprised they are not in many.  But more details on the FigOS peculiarities will come later after a more careful inspection.  All 32bits of it seem definitely interesting.

In its Refracta nature and whether its modifications would last through upgrades we did the following test.  We shifted Jessie into ascii (currently testing but promised to be stable, soon.).  Before much of upgrade took place we first upgraded apt, which will be doing the upgrade.  With upgrades in larger leaps we believe it is best to do this first, otherwise a first massive upgrade will require a second upgrade after apt has been altered itself.  We also installed eudev, in place of devuan’s udev (a hybrid of eudev), libeudev, and also OpenRC, which we believe is a step forward in the classic sysvinit system.  The system rebooted as instructed by OpenRC and replacing sysv-rc and run, before it actually was in ascii.  Most of it was still in its jessie structure.  A good sign of resilience.  Then we upgraded to ascii which took a while.  Then we installed the latest linux 4.9 i686-pae and headers and rebooted.  The system booted faster and cleaner than jessie.

So, the moral of the story is that FigOS is refracta at heart, despite of any modifications, and its 1 year old age (2.6) does not show any problems in rolling as a release.  Yes it takes time to upgrade as expected, and is as capable at least as any Refracta would be.  But, officially it is not Devuan.  We could produce an iso and publish it ourselves as a fork, and someone might say it is not refracta because it is based on FigOS, which is not Devuan.  But we are not in the distro producing business.

We are users testing and communicating to and with users.  And this one is exactly what we thought, despite of what Devuan may say about it.  Whether users like to combine useful aspects of various distributions, and not care about disto-clean pedigree and certification, is the true nature of unix/linux systems.  We believe that FigOS is trying to teach some this when it seems to have been forgotten.  If it is open and it is free it should be encouraged to develop your own system.  Just don’t expect much of support in hybrids when things break down.  This is the part of free we understand in open and free gnu linux.

We might take a step backawards, back to 1.8-1.9 which we believe FigOS was equally as much puppy or refracta.  And we will talk about that one too.  Enjoy!


14 thoughts on “Brief look at FigOS and upgrade to ascii

  1. there were a few statements that sounded incorrect at first, though upon rereading them i couldnt argue with anything said here. the part about devuan repos, is actually true– in the build process some debian repos are used directly, but they are version-specific and not enabled after (nor during) installation.

    to confirm what you said, simply grep the entire thing for the word “sources.” /etc/sources is never modified– it comes straight from refracta, untouched.

    i note with sadness that some of the packages 2.6 tries to download (evince is the one i know about for sure) are no longer in the debian repos. this is version-specific, we are not using apt-get in a chroot. i know this because i was working on 2.7 last night.

    the puppy iso that fig os gets its puppy capabilities from is entirely removed from 2.7– not to encourage people to reconsider its status as a derivative (some people just dont let themselves get swayed by facts) but because as long as it has used part of puppy, it has downloaded TWO isos as sources. any lauding of this as a hybrid is no longer something that benefits it. it was a neat trick, which affected the design and goals of fig os permanently (this trick resulted in fig os existing in the first place) but no one really cares about this aspect of fig os– including its author at this point.

    certainly i will not be deleting old versions, if anyone is interested in forking an older version. but they wont be. and yet, the option remains. meanwhile, there is one very large file that fig os no longer needs to download. i havent published 2.7 yet, its still being worked on. i do want to point out that part of it was tedious, but overall what i thought would be FAR more trouble was really done faster than expected. i added openbox too (installed, not setup as default) so we will find out if that helps.


  2. The devuan repositories, if you browse through them, they have a devuan and a merged repository. Devuan is just devuan and the other is what amprolla mixes up between /devuan and /debian.
    What if you substitute every /merged with /devuan and then add straight debian repositories of the same distribution.
    It shouldn’t affect anything, right? It would be like an mx/antiX styled distribution. With numeric and source preference anything that comes from devuan can not be upgraded with a debian package. Anything with an -rc at the end or -vuan or devuan will always be fresher than debian. When a security patch for a package is accepted it flows down sid, testing, stable, old-stable. If it is a devuan edited package you might not see it for another 6 months or till some devuan developer gets to repackage their version of it. Let’s say for “security reasons” you like to sandbox an application, or containerize it, and your sandboxing software has a security hole discovered and patched. In devuan it may take a while before you see the benefit. In antiX you get it immidiately unless it is a systemd related and dependent package.

    Does this make any sense? I hope so.


  3. What if you substitute every /merged with /devuan and then add straight debian repositories of the same distribution.
    It shouldn’t affect anything, right?

    it totally should. devuan isnt designed for that. one lets you look at their local stuff, and the other is what apt needs for a working distro.

    any complaints about “shady” merging, afaict, should be easy to refute by simply checking the “local” repo– if its in there, thats what you will get. if its not, you will get stuff from a debian mirror. autoselection of debian mirrors, as far as i know, did not originate with devuan. not that you shouldnt be able to create a configuaration that somehow pins devuan and goes to a specific debian mirror otherwise– but once again, devuan decided not to trust pinning. given the debacle about pinning changing right around the time everyone was pinning to keep sysd out, they still had enough reason to do this (imo.) devuan has not made it impossible to pin, they just went with a different tack (sorry, pun.)


  4. sorry, i get what youre saying now. only with very strategic pinning would that be possible. devuan decided not to do pinning around the time that debian appeared (at least) to sabotage the way pinning worked for most people. there was a new way to pin but the lesson was clear: if you rely on pinning, apt or related tools might let you down unless they are forked too. so they just made this amprolla thing. i do not know if they figured this would happen and created amprolla ahead of time or if they created it later. most users i believe, do not pay amprolla much attention, they just use the right repos. that was, to be fair– the most likely point of doing it that way. sophisticated pinning was never required. point for or against? i think most would say “for.”


  5. it would help quite a lot to have a better idea of how antix works their magic. despite any personal misgivings, i maintain that theyve done good work on the sysd-mitigation front. i know more (and even then, only what i know) about how devuan approaches it. despite having modified antix, i still dont know the details of how they do it.

    if i did know, perhaps i could apply it to fig os. i dont mean today, especially if it involves using other repos. if i could open and repackage packages– that may ultimately prove to be a better approach for keeping things like sysd out (and i believe devuan still does this, if slowly.)

    i do feel like a lot of our conversation about this moves around the premise that sysd only attacks package deps and the occasional library, when it is still (presently) being used to deprecate frameworks and things as completely unrelated to init as the debian menus. are they going to replace apt, too?

    freedesktop is a plague. i remove “machine-id” and the pdf viewer stops working. because of dbus or something.

    theyre coupling everything. pretty soon its like youll need to install systemd to use leafpad, or to use df. why not? im sure theres code for df in sysd somewhere that (while buggy) is certainly *newer* than some feature of something. so deprecating df would make perfect sense


  6. oh i didnt mean to imply that i knew what was going on with evince– mkfigos 2.7 (more recent than the comment) switches from evince_3.14.1-2+deb8u1_i386.deb to evince_3.14.1-2+deb8u2_i386.deb and im not really surprised thats all it was. however with deps on things like dbus or machine-id for things like atril, its easy to get cynical. thanks for checking on this.


  7. Here is an enlightening discussion,
    Would you care to comment?

    I have also converted my FigOS installation to instead of using the … ascii to use the … ascii PLUS the stretch repositories. In my minimalist installation I have not yet identified discrepancies, as I had previously though there were, but a few pkgs that have been rebuilt by devuan have been kept back without really identifying how they were dependent on systemd and associated libraries. The same specific package in antix is used straight from debian without problems, and antix does not have systemd-dummy libraries.

    The quest for truth shall continue.


  8. don’t have a list but several packages I hve looked for lately are missing from testing repository at debian. All or all except one, they ARE in the sid repo but are absent from testing repo. I mean it’s like they’re trying to f*ck with us, strongarm bully us into not (finding and) using certain packages….. then of course they’ll claim those (hidden away) packages weren’t “”popular”, few installed them, as ammo justifying why those packages should be removed.

    Top of this list is consolekit. It’s Not available from testing repository. Same foes for libck-connector0. F*ck you You will use programs that depend on the libsystemd-login0 stack or you will go hungry. OR you will just go away, away from debian. I mean, you could waste time figuring it out, making it work by looking in sid and grabbing same, hasn’t changed, consolekit package from sid. But the bullies are counting on most of us not figuring that out, and so either “gettin with the program” or getting the hell out.


  9. youre assuming that theyre removing packages theyre in the process of deliberately breaking just to have them missing– when the fact is that theyre probably just working on breaking them further. one is insidious and new, the other is the same thing theyve done since before debian 8 went stable. either way, the evince issue was in the stable repo. no one using apt-get would have noticed, but i was using the actual url– version and all. and the url was a year old, so it needed updating. this really only affected evince out of all others for me.


  10. mx (and knoppix and LFS) are doing the right thing, the best thing, they are preserving user choice. If a given program has been packaged such that it installs “.service” files just in case, jsut to make it suitable in a systemd environment, well antix in some cases does and devuan would (hold onto that thought) priggishly enforce “no, f*ck you. cannot be installed”. Devuan has been re-packaging at a rate which could only be admirable from the point of view of someone accustomed to eternally waiting for the hurd kernel, so it’s really a cruel joke on the user.

    It’s like: How many programs are packaged to require libatk accessibility toolkit? Wait, I’m not blind. I don’t want that unnecessary crap. So I leave out libatk on my system. Okay now I gotta deal with or try to overlook|ignore warning messages spammed to console and logfiles “accessibility bus not found”. It’s like that EXCEPT .service files are not reasonably objectionable, they add no session overhead and take up near zero storage space. But go ahead, devuan I’m lookin at you, paint yourselves and your users into the corner. Go ahead and sit in your corner, and holler across the room to the fsf prigs, boasting about how “preserving freedom by denying user choice” is the mostest bestest cheese-filled crust thing to do.

    After that debian forum 3page discussion you linked to, there was a dev1galaxy discussion and fsithred told golinux that he checked and devuan system actually has more .service files than an antix system. WTF? People are sitting around counting .service files? For starters, that stupidly only considers how many are found on a fresh installed system, doesn’t consider what can or cannot be installed by the user and whether or not my chosen packages will or will not install .service files so basically a pointless and meaningless comparison. But if counting keeps ’em out of the bingo halls, more power to em, right?

    All in all, people don’t understand what to do with choice, when the choice is preserved for them. People installing mx wind up crying OMG! Waiter, there’s a lumpy .service file in my soup! Or they stupidly (okay maybe innocently) install something which drags in systemd, then cry OMG! update removed half my system, broke my system. So, it’s a fine line. On one hand, can’t protect against stupid. On the other hand, ability to choose, to have a choice, is precious.


  11. “The same specific package in antix is used straight from debian without problems, and antix does not have systemd-dummy libraries.”

    If you post the name of a specific package, I’ll try to investigate “why” its systemd encumbered. Best to give the exact name or url to retrieve the package so I can check the sourcefiles.

    Liked by 1 person

  12. this is not exactly what devuan is doing, particularly with regard to .service files.

    personally, i suggested (more than a year or two ago) that a hook get added to remove unnecessary .service files. the idea that “theyre just a little bloat” doesnt sway me, if every single package comes with a file that isnt needed unless you are running systemd. OF COURSE the hook should be turned off if someone installs systemd. thats trivial to check using apt, and thats the right way to do it. perhaps.

    thats moot however, since i manually remove .service files from refracta whenever i can. i am certain that refracta gets them devuan, rather than introducing them.

    why do i remove them? to find out what it breaks when theyre not there (alternatively, to prove they are required. which they should not be.)

    devuan leaves them in. refracta leaves them in. i cannot remove all of them, things like udisks will break. this is not a case of devuan removing something– it simply does not get removed. also, if you remove the .service files from devaun, stuff will break. i would love to know why that is. ive wanted to know for years now.


  13. It was firejail,

    Also on something you were saying about pkgs being withdrawn from debian, I noticed a while back that gksu/gksudo seems to be deprecated as debian is trying to force that all applications needing root privileges that start fro user-menus, must be handled and allowed by desktop-policy-kit (synaptic, gparted)


If your comment is considered off-topic a new topic will be created with your comment to continue a different discussion. This community is based on open and free communication, meaning we must all respect all in minimizing the exercise of freedom to disrupt such communication. Feel free to post what you think but keep in mind the subject matter discussed. It is just as easy to start a new topic as it is to dilute the content of an existing discussion.

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.