Page 3 of 3

Re: The LinuxBBQ Extrawurst (Wish-A-Spin)

Posted: Mon Oct 28, 2013 4:11 pm
by machinebacon
I'm thinking about mixing this with the existing "StudEX" release and make it full-blown.
- Office Suite (I have tested Kingsoft WPS and found it excellent in handling Microsoft documents)
- LaTeX for some serious work
- lyx as frontend GUI
- Emacs anyway (org-mode for all!)
- the translators kit from tuxtrans, not all - but largely
- some flashcard app
- bibliography management
- if this already loads qt4 heavily, add VLC as media player and skype
- this and that, like WINE and Java

I would call it "Gekko" just for the sake of it :D

Re: The LinuxBBQ Extrawurst (Wish-A-Spin)

Posted: Mon Oct 28, 2013 4:13 pm
by GekkoP
For flashcards I only used Anki, not too bad actually.
"Gekko"? Would be greatly proud!

Re: The LinuxBBQ Extrawurst (Wish-A-Spin)

Posted: Mon Oct 28, 2013 4:38 pm
by machinebacon
See, anki is qt4 so probably we could go for a lxde-qt

Re: The LinuxBBQ Extrawurst (Wish-A-Spin)

Posted: Mon Oct 28, 2013 4:43 pm
by GekkoP
Damn Qt!
Seriously, go for whatever it's simpler for you. Just happy you're thinking about it ;)

Re: The LinuxBBQ Extrawurst (Wish-A-Spin)

Posted: Mon Oct 28, 2013 4:46 pm
by machinebacon
The fuck about qt is that many interesting apps depend on it, and we at the grill are usually focusing on gtk2 (if ever). So I think we should give qt4 (or soon-to-be qt5) a fair chance - maybe as a bare-bones release.

Of course if you ask me, I would go for LXDE-Openbox or XFCE4, or even MATE (though that one is already too fat as base to build something like the Translators Edition on top)

Re: The LinuxBBQ Extrawurst (Wish-A-Spin)

Posted: Mon Oct 28, 2013 4:50 pm
by GekkoP
Totally with you, I was thinking about LXDE-Openbox too.
If just Anki is heavy on Qt, leave it out and go gtk2.
Whenever they'll need Anki, they'll get the Qt-bloat needed and live happily with it. Or maybe there's another flashcard tool gtk-friendly I don't know.

Re: The LinuxBBQ Extrawurst (Wish-A-Spin)

Posted: Mon Oct 28, 2013 4:52 pm
by machinebacon
Really depends. There's no reason to prefer gtk over qt, both are equally "fantastic" (notice the irony please :D)

Re: The LinuxBBQ Extrawurst (Wish-A-Spin)

Posted: Mon Oct 28, 2013 4:53 pm
by GekkoP
lol.
About gtk, I found these two: iGNUit and gmemorize. Don't know if they're any good though.

Re: The LinuxBBQ Extrawurst (Wish-A-Spin)

Posted: Fri Nov 22, 2013 6:40 am
by DebianJoe
You know what I'd REALLY like to see? A linux kernel plus BSD's userland. I have heard this idea come up a few different times, but to the best of my knowledge (and PLEASE correct me if I'm mistaken), it hasn't materialized yet.

systemd + expanded driver support + non-GNU/non-BusyBox userspace just sounds like fun. Assuming that I ever finish some of the things I'm working on, I may start trying to build the BSD source and replace the GNU stuff on one of our cli spins.

Re: The LinuxBBQ Extrawurst (Wish-A-Spin)

Posted: Fri Nov 22, 2013 12:09 pm
by machinebacon
^ sounds feasible, and shouldn't be a problem as stage3 tarball.

Re: The LinuxBBQ Extrawurst (Wish-A-Spin)

Posted: Sat Nov 23, 2013 1:25 am
by pidsley
DebianJoe wrote:You know what I'd REALLY like to see? A linux kernel plus BSD's userland.
Have you seen this: https://bbs.archlinux.org/viewtopic.php?id=135612

(that thread also inspires me to try completely replacing coreutils with busybox, just because)

Re: The LinuxBBQ Extrawurst (Wish-A-Spin)

Posted: Sat Nov 23, 2013 6:06 am
by DebianJoe
No, I hadn't...and that's the guy I normally pull cwm from, wow. It looks like some of the things that I'd been thinking might be an issue are. Having to rely on glibc creates some issues, and I've been reading about using uclibc linking from some of the gentoo guys. They've at least tried it.

Thanks for the link. My interest in the project started from looking at a side-by-side comparison of how "cat" is written by gnu and bsd. The BSD stuff is significantly more "direct", if that's a good term for it. Their stuff actually makes sense.

Edit: I had a few errors with building the entire package as all warnings (regarding parameters) from bmake are being treated as fatal errors. I'm going through each of the files right now to see where the issues are arising from. This is very cool, thanks again for the link.

2nd Edit: https://github.com/chneukirchen/obase/issues/3 should you decide to go this route, expect this. I've tried the build on both i686 and x86_64 bases, but there's an issue with how libevent is parsing attributes, and what would generally be a "warning" from gcc is flagged to exit as an error. Not done with this yet, and if I come up with an answer I'll provide a patch.

/on-topic O_o