[FFmpeg-devel-irc] IRC log for 2010-08-13

[irc at mansr.com]

[00:27:47] <lu_zero>  
[00:31:15] <spaam>  
[00:32:37] <lu_zero> =_=
[00:32:48] <lu_zero> still having a faulty cable
[00:33:09] <spaam> time to get a new one ? :)
[00:33:21] * lu_zero is experiencing the _fun_ and joy of dgram unix socket...
[00:33:43] <lu_zero> and the fact ffmpeg proto interface sucks =_=
[00:34:56] <spaam> make it better then ;) patch welcome like we say in lighty ;) hohoho ;P
[00:37:28] <lu_zero> spaam: trying to right now
[00:39:16] <lu_zero> sigh
[00:39:32] <lu_zero> seqpacket looks even more broken than dgram...
[00:40:19] <lu_zero> interesting now even strace crashes..
[01:20:47] <saintdev> peloverde: ping
[02:02:26] <j0sh> lu_zero: unix domain sockets as a ffmpeg protocol?
[02:02:50] <j0sh> i looked into doing something like that about 6 months ago
[02:03:04] <CIA-93> ffmpeg: darkshikari * r24791 /trunk/libavcodec/vp8.c: Remove some stray +s in VP8
[02:03:55] <j0sh> iirc, just ended up using named pipes
[02:18:10] <lu_zero> j0sh: implemented it, quite disappointed by the result
[02:18:34] <lu_zero> named pipes would work better I'm afraid
[02:18:45] <j0sh> aye
[05:18:46] <todd-m2n> Can someone explain why ffmpeg file creates valid ogg, while pipe: creates invalid ogg?
[05:18:47] <todd-m2n> ffmpeg -i input.mpg -vcodec libtheora -f ogg -acodec libvorbis output-file.ogg; ogginfo output-file.ogg | grep WARN | wc
[05:18:47] <todd-m2n>       5      30     182
[05:18:47] <todd-m2n> ffmpeg -i input.mpg -vcodec libtheora -f ogg -acodec libvorbis - > output-pipe.ogg; ogginfo output-pipe.ogg | grep WARN | wc
[05:18:47] <todd-m2n>    1293   18095  116681
[05:22:43] <kshishkov> probably because pipe output cannot be seeked and something is not written properly. Read ogginfo output insted of counting lines in it
[05:23:31] <todd-m2n> WARNING: Hole in data (1085 bytes) found at approximate offset 67500 bytes. Corrupted Ogg.
[05:23:31] <todd-m2n> WARNING: Hole in data (145 bytes) found at approximate offset 67500 bytes. Corrupted Ogg.
[05:23:31] <todd-m2n> <and so on>
[05:24:39] <todd-m2n> I will look into the source for pipe: specific oddity...
[05:25:29] <todd-m2n> ogginfo doesn't show corrupted for file out, but has thousands of corrupted lines in a 10 second mpg with - > pipe redirection.
[07:05:43] <superdump> i thought we could handle rtp input...
[07:06:40] <superdump> ah, we do
[07:06:44] <superdump> good good
[07:16:31] <kshishkov> just don't tell lu_zero ;)
[07:17:12] <pJok> god morgon, kshishkov
[07:17:28] <kshishkov> god morgon
[07:23:05] <pJok> still dreaming of cheeses?
[07:23:27] <kshishkov> also of Trocadero and berries
[07:23:47] <kshishkov> and Ramlösa
[07:24:15] <pJok> Ramlösa is danish ;)
[07:24:34] <kshishkov> only by owner, not by location
[07:24:43] <superdump> isn't it just water?
[07:25:05] <kshishkov> it's one of the best mineral waters in the world
[07:25:09] <superdump> "Ramlösa is a brand of carbonated mineral water from a source in Ramlösa Brunnspark in the southern part of Helsingborg, Sweden."
[07:25:19] <superdump> i don't really like carbonated water
[07:25:43] <pJok> kshishkov, what i mean is, Carlsberg owns the Ramlösa brand ;)
[07:25:49] <kshishkov> and I hate still water after being in Denmark
[07:26:00] * pJok often drives past Ramlösa
[07:26:11] <kshishkov> pJok: it also owns most of Swedish breweries as well, I'm aware of that
[07:26:40] <pJok> since its about 10 minutes north of where i live
[07:28:04] <kshishkov> you can also point out that Skania belonged to Denmark once
[07:29:12] <pJok> along with Halland and Blekinge, yes
[07:29:16] <pJok> im trying to take it back to denmark ;)
[07:29:57] <pJok> btw, kshishkov: http://humoncomics.com
[07:30:02] * kshishkov would prefer Sweden to take a bit of Denmark and make it more civilised
[07:30:29] <kshishkov> for instance, compare Helsingor and Helsinborg
[07:31:06] <pJok> the only thing left from danish times in Helsingborg is Kärnan
[07:31:34] <pJok> but then again, skania isn't sweden nor denmark
[07:31:52] <pJok> its somewhere inbetween
[07:32:32] <kshishkov> yet, please compare those two towns, they are conveniently located in opposite sides of the Sound and even have similar names
[07:33:17] <pJok> you know why?
[07:33:40] <pJok> to protect the sound
[07:33:40] <kshishkov> first part obviously means "strait"
[07:33:52] <kshishkov> yes, that's obvious
[07:35:19] <kshishkov> yet I heard from one guy who've been in both places that Danish town looks less appealing
[07:36:10] <kshishkov> also I wonder if superdump recognized the place where certain Hamlet was described to live
[07:36:27] <pJok> hehe
[07:37:02] <pJok> well, if you ever make your way up here, i'll give you a tour of greater copenhagen
[07:37:34] <kshishkov> I've been there for a day. Nice architecture
[07:38:25] <Tjoppen> a demuxer can leave lots of codec values unset and have the codec figure them out, right? I'm looking at LXF, and it doesn't seem to store the resolution (among other things)
[07:38:34] <kshishkov> I'd even say outstanding architecture, especially spires
[07:38:41] <pJok> i find it interesting that i live in a city that is older than most current countries
[07:38:54] <kshishkov> Tjoppen: it can hardcode stuff sometimes
[07:39:20] <kshishkov> pJok: yes, not older than Ukraine though :(
[07:39:43] <pJok> how old is Ukraine?
[07:39:49] <pJok> as current state that is
[07:39:55] <Tjoppen> indeed. however it can store normal mpeg-2 video, which can be pretty much any resolution
[07:40:12] <kshishkov> pJok: current state is from 1991, original one is from 882
[07:40:35] <Tjoppen> unlike dv25 and dv50, which have fixed resolutions (it can signal the use of either, and whether it's PAL or NTSC)
[07:40:36] <kshishkov> Tjoppen: MPEG-2 video stores resolution and framerate inside IIRC, so no worries
[07:40:41] <pJok> thought so
[07:40:42] <pJok> :)
[07:40:47] <pJok> time to flee and catch a bus
[07:40:48] <Tjoppen> cool. then I only have to worry about the raw video cases
[07:41:33] <Tjoppen> it can store KRGB (K = chroma key) and 16-bit K. I guess I could have it peek at the first video packet, look at its size and guess the resolution based on that
[07:42:29] <kshishkov> could be stored at the beginning of packet
[07:43:43] <Tjoppen> nope. it only stores the size in bytes and what type of frame it is
[07:44:15] <kshishkov> silly
[07:44:28] <Tjoppen> but I guess I could get away with if(pix_fmt == PIX_FMT_ARGB && size == 1658880) { width = 720; height = 576; }
[07:45:11] <kshishkov> not if you try to submit it for inclusion ;)
[07:45:12] <Tjoppen> I only have samples containing good old DV so far
[07:45:46] <Tjoppen> well, look at all the hacks other demuxers do, like flic.c :)
[07:46:02] <kshishkov> those are too old to be used for reference
[07:47:00] <Tjoppen> true. I assume leaving certain codecs unsupported is fine though
[07:47:07] <kshishkov> indeed
[07:47:15] <Tjoppen> or possibly just setting codec_ic and have the user guess the resolution instead
[07:48:08] <Tjoppen> it's such a wonderful "spec".. just a header with one big struct consisting of a nested horror of unions and bitfields
[07:48:21] <kshishkov> you can just try to guess it by looking if it's multiple of something {640,704,720} and bail otherwise
[07:48:48] <Tjoppen> that's what the above does though, kinda
[07:49:13] <kshishkov> just make it a bit more generic and it'll be fine
[07:49:22] <Tjoppen> hm. maybe there's an aspect ratio in there somewhere
[07:52:08] <Tjoppen> nope. oh well. I need to wait for samples anyway. next week :)
[07:57:42] <todd-m2n> FILE WORKS:
[07:57:42] <todd-m2n> ffmpeg -i input.mpg -vcodec libtheora -f ogg -vb 1024k -acodec libvorbis out.ogg ; ogginfo out.ogg | grep WARN | wc
[07:57:42] <todd-m2n>       0       0       0
[07:57:42] <todd-m2n> PIPE ERRORS:
[07:57:42] <todd-m2n> ffmpeg -i input.mpg -vcodec libtheora -f ogg -vb 1024k -acodec libvorbis - > out.ogg ; ogginfo out.ogg | grep WARN | wc
[07:57:43] <todd-m2n>    4334   60271  390009
[07:57:43] <todd-m2n> Adding sameq (which I believe disables seeking, but yields poor quality video):
[07:57:44] <todd-m2n> ffmpeg -sameq -i input.mpg -vcodec libtheora -f ogg -vb 1024k -acodec libvorbis - > out.ogg ; ogginfo out.ogg | grep WARN | wc
[07:57:44] <todd-m2n>       0       0       0
[07:57:45] <todd-m2n> How can I get ffmpeg/theora to keep a pipe buffer for seeking rather than being written and causing errors?
[07:59:43] <Dark_Shikari> sameq has absolutely nothing to do with seeking.
[08:00:34] <todd-m2n> sorry, I might have used the wrong term, but adding -sameq renders good OGG, but the video is pixelated
[08:00:45] <Dark_Shikari> sameq has absolutely nothing to do with ogg.
[08:00:52] <Dark_Shikari> it has absolutely no effect on the container structure.
[08:01:03] <Dark_Shikari> what's with people and sameq, this is like the 3rd person today to decide that sameq means something completely unrelated to what it actually does.
[08:01:38] <todd-m2n> removing -sameq is sporadic errors in the theora (ogginfo) and holes appearing. but good video quality otherwise.
[08:01:50] * elenril blames tfm
[08:01:53] <todd-m2n> correct not ogg (not container)
[08:02:00] <todd-m2n> it is in theora
[08:02:09] <Dark_Shikari> "holes"?
[08:02:17] <todd-m2n> ogginfo says "Hole in theora"
[08:02:23] <Dark_Shikari> I have no idea what that means.
[08:02:43] <todd-m2n> sure, the question is more about ffmpeg than the theora error.
[08:02:48] <todd-m2n> my question is...
[08:02:58] <todd-m2n> writing to a file... no corruption
[08:03:06] <todd-m2n> writing to a pipe... corruption
[08:03:08] <Dark_Shikari> what is "corruption"
[08:03:10] <Dark_Shikari> be more specific
[08:04:23] <todd-m2n> corrupted file:
[08:04:25] <todd-m2n> WARNING: Hole in data (829 bytes) found at approximate offset 90000 bytes. Corrupted Ogg.
[08:04:25] <todd-m2n> WARNING: Hole in data (30 bytes) found at approximate offset 90000 bytes. Corrupted Ogg.
[08:04:25] <todd-m2n> WARNING: Hole in data (486 bytes) found at approximate offset 90000 bytes. Corrupted Ogg.
[08:04:30] <Tjoppen> todd-m2n: maybe the ogg muxer simply isn't designed for streaming output? I see a couple of seeks in there
[08:04:30] <todd-m2n> that is from ogginfo
[08:05:05] <todd-m2n> it does stream the output fine, and we get good playback at < 656k vb
[08:05:27] <todd-m2n> I get one or two "holes in theora" during playback but very rare.
[08:05:32] <Dark_Shikari> That's likely an ogg muxer issue
[08:05:37] <todd-m2n> > 656k the "holes" increase.
[08:05:39] <Dark_Shikari> and the bitrate just happens to trigger it
[08:05:56] <todd-m2n> but writing to a file there are no errors
[08:06:01] <Tjoppen> my guess it has to do with the size of the seek buffer. it can't seek too far back (a few k) to update the crc
[08:06:11] <todd-m2n> it only occurs at bitrates > 656k when writing to a pipe
[08:06:16] <Tjoppen> yes, because with a file you can seek wherever
[08:06:26] <todd-m2n> yes, I think seek too.
[08:06:41] <todd-m2n> so my question above is... can I create a seek buffer while using a pipe?
[08:06:58] <Tjoppen> try increasing IO_BUFFER_SIZE in aviobuf.c
[08:07:17] <todd-m2n> ooh, that is very much worth a shot...
[08:17:30] <lu_zero> mru: ping
[08:21:51] <pJok> hmm
[08:21:53] <pJok> fourcc SIRF
[08:22:23] <pJok> ah yes
[08:22:25] <pJok> Softimage
[08:24:43] * kshishkov thought that SIRF may have something to do with GPS
[08:37:15] <todd-m2n> Tjoppen: you nailed it! IO_BUFFER_SIZE increase has allowed me to have a seek buffer and pipe. Thank you.
[08:37:36] <pJok> kshishkov, could've been... we use SIRF files all the time here, but since ffmpeg doesn't support them, we have to get around that by either using avisynth or no ffmpeg at all ;)
[08:40:42] <kshishkov> blasphemy!
[08:46:36] <lu_zero> mru: unping
[08:46:50] <lu_zero> the configure is smarter than I'd expect
[08:46:58] <Tjoppen> todd-m2n: cool :)
[08:47:23] <Tjoppen> maybe that could be useful as a CLI option?
[08:47:43] <Tjoppen> or maybe just fix the ogg muxer
[09:59:54] <lu_zero> uh the newer libvpx decoder seems faster now
[10:00:57] <Tjoppen> healthy competition?
[10:01:17] <lu_zero> yup =)
[10:02:11] <spaam> faster then ffvp8 ?
[10:02:20] <lu_zero> apparently
[10:12:38] <Dark_Shikari> lu_zero: "new"?
[10:13:00] <Dark_Shikari> It's most definitely nowhere near faster here...
[10:13:10] <Dark_Shikari> are you testing with threads vs without threads?
[10:13:34] <lu_zero> http://code.google.com/p/chromium/issues/detail?id=50811
[10:13:47] <lu_zero> I'm just reading
[10:14:28] <Dark_Shikari> it says 30% faster
[10:14:35] <Dark_Shikari> ffvp8 is 30% faster, that is.
[10:14:56] <Dark_Shikari> also that thread is by fbarchard
[10:15:01] <Dark_Shikari> a complete clueless idiot
[10:15:40] <cartman> lol
[10:16:48] <lu_zero> at least he's trying
[10:16:59] <Dark_Shikari> no, I would prefer if he didn't try
[10:17:04] <Dark_Shikari> his version of "trying" is comparing audio encoders using PSNR
[10:17:09] <Dark_Shikari> and thus concluding ffvorbis is better than libvorbis
[10:17:11] <Dark_Shikari> Yes he actually did this
[10:17:41] <lu_zero> uh
[10:17:57] <lu_zero> interesting way to test...
[10:18:35] <lu_zero> psy and psnr don't mix that well =P
[10:19:09] * lu_zero re-reads the last post
[10:19:41] <Dark_Shikari> fucking hell, someone ripped off my asm code in libvpx
[10:19:49] <lu_zero> uhm?
[10:19:56] <Dark_Shikari> they basically copy-pasted my asm code
[10:19:58] <lu_zero> who did?
[10:20:02] <lu_zero> which lines?
[10:20:16] <Dark_Shikari> e4fe866949951c8eb79c5ebdb0a6dab37cef37a9
[10:20:28] <Dark_Shikari> No credit
[10:20:30] <Dark_Shikari> not even "inspired by"
[10:20:57] <elenril> doesn't that violate gpl or something like that
[10:21:30] <lu_zero> yup
[10:22:48] <lu_zero> where is that part in ffmpeg?
[10:23:10] <Dark_Shikari> vp8dsp.asm or whatever
[10:23:13] <Dark_Shikari> just grep for the ssse3 functions
[10:23:31] <Dark_Shikari> arguably, it's not really a GPL violation, as there's only one way to write it sanely
[10:23:39] <Dark_Shikari> but they did outright rip off my algorithm without giving credit.
[10:23:49] <lu_zero> ask for it
[10:23:59] <lu_zero> usually they do comply
[10:24:09] <Dark_Shikari> I asked for them to add "LGPL" to the license header.
[10:24:33] <lu_zero> when?
[10:24:50] <Dark_Shikari> right now.  =p
[10:26:24] <lu_zero> =)
[10:56:05] <Honoome> mru: which insane system does not use bitwise 0 for NULL?!
[13:23:27] <cartman> since you guys know ARM better than me
[13:23:33] <cartman> if I debug-break an ARM program
[13:23:44] <cartman> I see, andeq       r0, r0, r0
[13:23:46] <cartman> lots of them
[13:23:51] <cartman> why would that be?
[13:24:02] <kshishkov> nop
[13:24:58] <cartman> yeah, a nop but...
[13:25:01] <cartman> the program is simply
[13:25:18] <cartman> while(true) { a +=1 ; msleep(10); }
[13:25:19] <kshishkov> thry objdump'ing it instead
[13:25:25] <cartman> shouldn't it break inside of there
[13:25:28] <cartman> instead of a nop?
[13:25:53] <kshishkov> it may be just sleeping routine :)
[13:26:14] <cartman> I can never break inside some useful code :)
[13:26:24] <cartman> is there a way to assure that?
[13:26:34] <kshishkov> disassemble you file first
[13:26:45] <kshishkov> (with objdump, IDA or whatever)
[13:26:49] <kshishkov> look at result
[13:26:56] <kshishkov> find a good breakpoint place
[13:27:16] <cartman> I am able to stop at a breakpoint
[13:27:21] <cartman> just break all behaviour puzzles me
[13:28:01] <cartman> oh right
[13:28:13] <cartman> removing the sleep makes Break All righr
[13:28:19] <cartman> so its just cpu idling
[13:29:41] <cartman> kshishkov: can we say nops happen when cpu is idle?
[13:29:53] <kshishkov> could be
[13:29:57] <Dark_Shikari> wrong
[13:30:05] <Dark_Shikari> most cpus have dedicated idle instructions
[13:30:17] <Dark_Shikari> e.g. a "wait until the next interrupt" instruction
[13:30:17] <cartman> why does this thing nop in sleep then? :)
[13:30:20] <Dark_Shikari> which lets them save power
[13:31:30] <cartman> Dark_Shikari: what could be the reason for these nop blocks? Dissassembly shows lots of nops, when I break the execution
[13:31:53] <Dark_Shikari> dunno.
[13:32:14] <cartman> I am on Windows CE, so danger Will Robenson applies I guess
[13:32:23] <cartman> who knows what msvc is after
[13:32:45] <kshishkov> Steve Ballmer?
[13:33:09] * cartman wants cegcc
[13:37:19] <Tjoppen> is there a way to signal that a demuxer accepts seeking to pkt->pos? I'm not entirely sure how it works, but I understand that field is for automatic index generation
[13:37:48] <Tjoppen> I realized that with that I can make my experimental LXF demuxer seekable with no extra work
[13:41:27] <kshishkov> IIRC it may do so without defined seek function
[13:41:57] <kshishkov> just call that function for adding index entry
[13:42:16] <Tjoppen> I saw ".flags = AVFMT_GENERIC_INDEX," elsewhere. let's see what that does
[13:42:42] <Tjoppen> of course, this probably only allows seeking backwards
[13:43:07] <kshishkov> of course
[13:47:26] <Tjoppen> nope, didn't work
[13:56:24] <kshishkov> have you marked packets with PKT_POS_KEY?
[13:56:57] <kshishkov> err, AV_PKT_FLAG_KEY
[14:09:23] <Tjoppen> hrm.. no :o
[14:09:30] <Tjoppen> but now I did, and still no luck
[14:11:03] <Tjoppen> I'm saving url_ftell() before reading the packet header, then I set pkt->pos to that value later
[15:16:14] <BBB___> how do I reset my dependency files?
[15:16:16] <BBB___> (.d)
[15:17:02] <peloverde> Usually I just delete them if i'm having problems with them
[15:17:26] <BBB> I ws hoping there was a make command to do that
[15:17:31] <BBB> without having to type all dir names
[15:18:02] <cartman> BBB: find . -name "*.d"|xargs rm
[15:28:29] <KotH> cartman: find -name '*.d' -exec rm {} \;
[15:28:39] <KotH> cartman: works also with files that contain spaces :)
[15:28:51] <cartman> KotH: bah ;)
[15:29:05] * KotH applies some 10kV to cartman
[15:29:12] * cartman runs home
[15:29:15] <cartman> see you!
[15:29:33] <KotH> there is always an engineering solution to it ;)
[15:37:19] <lu_zero> to cartman?
[15:37:45] <lu_zero> BBB: make clean?
[15:37:49] <lu_zero> make depend?
[15:38:11] <janneg> find -name '*.d' -delete
[15:39:15] <twice11> KotH: "find -name '*.d' -print0 | xargs -0 rm" also works with spaces, and is faster.
[15:39:23] <BBB> I love you guys
[15:39:30] <twice11> But it requires GNU find/xargs.
[15:39:47] <BBB> lu_zero: make depend fails because the dependnies of the current build aren't satisfied
[15:39:53] <BBB> so it breaks before rebuilding the deps :-p
[15:39:55] <BBB> a catch 22
[15:40:18] * KotH notes, unix is quite perl'ish: there is always more than one solution
[15:40:33] <KotH> BBB: make distclean?
[15:40:49] <BBB> I already fixed it
[15:40:58] <BBB> I'm back at svn HEAD already, had to bisect where a bug was introduced
[15:41:03] <BBB> found it, already back at HEAD
[15:41:04] <BBB> :-p
[15:41:54] * KotH notes, BBB can go "there and back again" faster than bilbo
[15:41:59] <twice11> -delete seems to be a GNU extension, too, if I read the flashrom man page correctly.
[15:42:13] <twice11> Argh, the "find" manpage.
[15:42:21] <twice11> Should not talk in different channels the same time.
[15:42:25] <KotH> twice11: and it seems to have some nasty side effects
[15:42:48] <KotH> twice11: looks like you havent learned how to multitask while chatting yet ;)
[15:44:49] <janneg> twice11: yes, -delete is a gnu extension
[15:45:58] <janneg> KotH: yes, don't try `find / -delete -name "this_file_can_be_safely_deleted.bak~"`
[15:47:29] <twice11> find / -print -name "..." will also not do what you want, but it's not as dangerous, though.
[17:03:28] <CIA-93> ffmpeg: rbultje * r24792 /trunk/libavformat/mmst.c:
[17:03:28] <CIA-93> ffmpeg: Fix wrong command prefix for timing test in MMST protocol.
[17:03:28] <CIA-93> ffmpeg: Patch by Zhentan Feng <spyfeng gmail com>.
[17:10:00] <CIA-93> ffmpeg: rbultje * r24793 /trunk/libavformat/mms.c:
[17:10:00] <CIA-93> ffmpeg: Set fixed chunksize for ASF header in MMS streams, as per MSDN documentation.
[17:10:00] <CIA-93> ffmpeg: This fixes playback of at least one MMST stream.
[17:10:00] <CIA-93> ffmpeg: Patch by Zhentan Feng <spyfeng gmail com>.
[17:28:26] <mru> ping swedes
[17:29:54] * kshishkov waves just in case
[17:31:05] <CIA-93> ffmpeg: rbultje * r24794 /trunk/libavformat/ (mms.c mmst.c mms.h):
[17:31:05] <CIA-93> ffmpeg: Remove use of MAX_STREAMS in MMSContext->streams[] array. Instead, dynamically
[17:31:05] <CIA-93> ffmpeg: allocate the array.
[20:07:08] <CIA-93> ffmpeg: rbultje * r24795 /trunk/libavformat/rtpdec_asf.c: Prevent overflow on random input.
[20:43:55] <spaam> mru: http://marc.info/?l=openbsd-misc&m=128171974314955&w=2  you are not a real hacker =(
[20:46:38] <kierank> except awk and nc won't build because the right headers aren't there
[20:51:23] <spaam> kierank: what mta do you use? ;)
[21:02:37] <cartman> "Solaris is the #1 Enterprise Operating System."
[21:02:38] <cartman> lol
[21:02:41] <cartman> Oracle is funny
[21:06:09] <spaam> you did read about http://sstallion.blogspot.com/2010/08/opensolaris-is-dead.html ? :)
[21:07:35] <cartman> spaam: yeah
[21:07:47] <cartman> it was Slowaris anyway
[21:08:07] <kierank> spaam: outlook express
[21:08:17] <spaam> kierank: Nice
[21:08:45] <spaam> cartman: maybe . but they got a nice fs :)
[21:09:15] <cartman> yeah works nice in theory
[21:10:27] <spaam> it works nice on my fileserver . but im using fbsd on that one ,D
[21:11:28] <cartman> fbsd has a nice release engineering team