| 03:05.29 | *** join/#brlcad Twingy (n=justin@74.92.144.217) |
| 13:38.14 | *** join/#brlcad clock_ (i=clock@84-72-60-48.dclient.hispeed.ch) |
| 14:36.06 | clock_ | brlcad: you might be interested in my autogenerated BRL-CAD videos |
| 14:41.10 | brlcad | clock_: howdy |
| 14:41.13 | brlcad | i probably would |
| 14:42.09 | clock_ | There was a problem with pixhalve that it is usable only with gamma=1 |
| 14:42.17 | clock_ | but gamma=1 degrades the pixel depth so it's unusable |
| 14:42.31 | clock_ | gamma=2.2 is correct for rendering video, but without pixhalve the videos are jagged |
| 14:42.57 | clock_ | So I wrote my own tool that supports arbitrary spatial resampling (up/down), and temporary downsampling given by an integer |
| 14:43.05 | clock_ | and outputs into YUV4MPEG2 and PPM stream |
| 14:43.43 | clock_ | I put it into my Ronja makefiles so now I get a 576x576x50Hz video with a sound loop background (7.2 sec) and an animated gif @10Hz which is temporary subsampled |
| 14:43.44 | brlcad | your pix-y4m tool? |
| 14:43.57 | clock_ | everything is calculated correctly, gamma correctly handled, calculations done in 16 bits |
| 14:44.03 | clock_ | yes it's an upgrade of the pix-y4m |
| 14:44.11 | clock_ | I took the resampler from Links :) |
| 14:44.43 | clock_ | it generates Ogg Theora, DivX and WMV |
| 14:44.47 | clock_ | and also bzipped YUV4MPEG2 |
| 14:44.51 | clock_ | and an animated GIF |
| 14:45.05 | brlcad | that tool would make a nice addition, though there are a few hopefully minor changes/additions that would be needed and one other somewhat signficant change |
| 14:45.35 | brlcad | generates ogg/divx/wmv manually? or links to eternal libs? |
| 14:45.53 | clock_ | from the YUV4MPEG2 it's generated by transcode and libtheora encoder example |
| 14:46.04 | clock_ | the pix-y4m produces YUV4MPEG2 |
| 14:46.09 | brlcad | ah |
| 14:46.24 | brlcad | i was going to say.. damn |
| 14:47.23 | clock_ | See http://ronja.twibright.com/3d/ at the bottom - tetrax |
| 14:48.30 | brlcad | that's freaking awesome :) |
| 14:49.02 | clock_ | Now I just add names like "holder" or "tetrax" into one place of my makefiles and add couple of hours and I can get other videos :) |
| 14:49.05 | clock_ | thanks |
| 14:49.18 | brlcad | at least on the ogg :) |
| 14:49.34 | clock_ | that's not porno music that's CC-BY-SA Xcyril: Hip Hop |
| 14:49.42 | brlcad | uh huh ;) |
| 14:49.55 | clock_ | can you play in a loop? |
| 14:50.36 | clock_ | I could replace the loop with amiga-style chiptune from the Supertux game |
| 14:50.46 | clock_ | it has a period of 7 seconds that's very close to 7.2 |
| 14:51.12 | brlcad | yeah, I can loop it in quicktime |
| 14:51.21 | clock_ | does it loop seamlessly? |
| 14:51.48 | brlcad | the animation is seamless |
| 14:52.03 | brlcad | the audio on theora is a little disjoint |
| 14:52.54 | clock_ | and divx and wmv? |
| 14:54.36 | brlcad | ahh, somehow i missed the audio on the divx .. it's identical |
| 14:54.49 | clock_ | is there a notch in the audio? |
| 14:55.15 | brlcad | it's not so much a notch as just a nit-pick on the blend |
| 14:55.30 | clock_ | maybe the driver has to flush the audio buffer or so |
| 14:55.40 | clock_ | I calculated the length in audacity exactly to 7.2 sec |
| 14:55.48 | clock_ | When I blend the audios in audacity, it's perfectly seamless |
| 14:55.55 | clock_ | so it must be the encoding process or your player |
| 14:56.12 | clock_ | my player (mplayer, vlc) produces absolutely horrible stutter at the seam |
| 14:56.17 | brlcad | or different expectations |
| 14:56.21 | brlcad | it does loop nicely |
| 14:58.03 | brlcad | but going from the fluttering at the end to the beat at the start just isn't what I'd personally call "seamless" |
| 14:58.37 | brlcad | it could very well be what you intended -- you'd have to hear it for yourself :) |
| 14:59.17 | clock_ | it's like this in the original music |
| 14:59.51 | clock_ | xcyril: hip hop you can download for free on jamendo |
| 15:02.56 | clock_ | Now Ronja compiles several hours :) |
| 15:03.16 | clock_ | But still I consider the raytracer to be fast - when it calculates all the shadows etc. |
| 15:04.43 | brlcad | how many fps are you rendering? |
| 15:04.50 | brlcad | for the animation |
| 15:05.18 | clock_ | 0.3fps |
| 15:05.23 | clock_ | 1152x1152 |
| 15:05.32 | clock_ | depends on scene comoplexity too |
| 16:09.25 | clock_ | Why does material=0 cause ridiculously high mass like 10^289kg? |
| 16:11.05 | brlcad | probably getting a division by zero because there's no density set |
| 16:11.18 | brlcad | s/zero/near zero/ of course |
| 16:11.48 | brlcad | or there's an indexing issue there -- supposed to index from 1 up |
| 16:13.03 | clock_ | Maybe it's a bug? |
| 16:13.38 | clock_ | If I set the density in the density file to 0 (material=256, density 0) then it calculates correctly |
| 16:13.45 | clock_ | Can I put a line with 0 into the density file? |
| 16:14.10 | brlcad | i'm frankly not sure that's been tried |
| 16:14.16 | brlcad | again, not the design :) |
| 16:14.21 | brlcad | but go ahead and try .. |
| 16:14.40 | clock_ | Why is it called "GIFT_MATERIAL"? |
| 16:14.58 | brlcad | that's ancient heritage |
| 16:15.34 | brlcad | gift material codes are what the DoD uses/used to define material properties |
| 16:15.47 | clock_ | So it's retro |
| 16:16.38 | brlcad | GIFT was the "Geometric Information from Targets" |
| 16:16.57 | brlcad | basically the precursor to 'rt' in a way |
| 16:17.42 | brlcad | evolved from the magi ray-tracer iirc |
| 16:19.05 | brlcad | ahh, here we go.. |
| 16:19.20 | brlcad | a 1987 paper on the topic: http://ftp.arl.mil/~mike/papers/86scotland/joined.html |
| 16:21.00 | clock_ | Yes it calculates correctly even with index 0 |
| 16:24.08 | brlcad | good to know |
| 16:37.37 | clock_ | whast is REGION_CODE? Can it be all 1000 for all parts? |
| 16:38.06 | clock_ | no sorry REGION_ID |
| 16:47.43 | clock_ | Now the 0'th index doesn't work |
| 16:49.04 | clock_ | printf("%s",NULL) isn't something a program should do: |
| 16:49.08 | clock_ | <PROTECTED> |
| 16:49.09 | clock_ | <PROTECTED> |
| 16:49.09 | clock_ | <PROTECTED> |
| 16:49.09 | clock_ | <PROTECTED> |
| 16:49.09 | clock_ | <PROTECTED> |
| 16:49.11 | clock_ | <PROTECTED> |
| 16:49.14 | clock_ | 11142320660329766197282404428822493103453219925682332085413596211029096794472640917136021704128167472701500262605140476594536144399399667268753079654421883418581083831198838033283297124246427098575741106021024097346550934083463016754241736963503981200105259980151084013000927862654594585192530136845516800.000 0 100 (null) 0.0000 /chimney/chimney.r |
| 16:53.40 | clock_ | When it worked it was caused by chance |
| 16:54.08 | ``Erik | hum |
| 17:20.36 | clock_ | the rtweight produces random numbers even when I use 256 for the part that doesn't count |
| 17:21.39 | clock_ | It produces random numbers even when I make the numbers in the .density file continuous |
| 17:21.50 | clock_ | <PROTECTED> |
| 17:21.50 | clock_ | <PROTECTED> |
| 17:21.50 | clock_ | <PROTECTED> |
| 17:21.50 | clock_ | <PROTECTED> |
| 17:21.50 | clock_ | <PROTECTED> |
| 17:21.53 | clock_ | <PROTECTED> |
| 17:21.55 | clock_ | 5471996131684330201384988641922329570258652293616177422983661606387605959185699572608651675799621548161907052971545040885199431982865401592260667493913974039383458518276186681799389570084070369563361732356774012177516296118005292214198201381758086484754586844743669147989428832905491120128.000 6 100 Doesnt_count 0.0000 /chimney/chimney.r |
| 17:22.00 | clock_ | <PROTECTED> |
| 17:22.03 | clock_ | Sometimes it happens, sometimes not |
| 17:22.05 | clock_ | run from run |
| 17:23.08 | clock_ | The problem seems to be the 0 weight of the material |
| 17:23.14 | clock_ | when I replace with 0.00000001 it's OK |
| 17:24.02 | clock_ | Where is the source for rtweight? |
| 17:24.32 | clock_ | There is only rtweight_vers.c and it's almost empty |
| 17:27.04 | clock_ | if (density<0) something else if (density>0) something else |
| 17:27.55 | clock_ | OK let's try to recompile and make some spaghetti |
| 17:34.04 | brlcad | source is in src/rt/view_weight.c |
| 17:34.10 | clock_ | now it seems to work |
| 17:34.33 | brlcad | a density of 0 would be invalid |
| 17:34.43 | clock_ | Invalid is <0 |
| 17:34.53 | clock_ | <0 prints a message "no density specified" |
| 17:34.56 | clock_ | >0 calculates the density |
| 17:34.59 | clock_ | 0 throws dice |
| 17:35.06 | clock_ | And I need density of 0. |
| 17:35.45 | brlcad | a density of zero would be a pure vaccuum in space |
| 17:36.05 | brlcad | even air has a non-zero density |
| 17:36.08 | clock_ | or an object whose weight is not to be taken into account |
| 17:36.52 | clock_ | Do you want to keep the current throw-dice-at-zero behaviour? |
| 17:37.05 | brlcad | well, of course not -- that's just bad behavior |
| 17:37.22 | clock_ | At least you are not like the Linux kernel or Ekiga developers |
| 17:37.29 | clock_ | who are always right no matter how crappy it behaves |
| 17:38.22 | brlcad | nah, i'm not defending it -- from a design standpoint it is behaving as garbage-in->garbage-out .. but it should still behave sensibly |
| 17:38.31 | clock_ | that's also why I am not wasting time with projects like that and poke at BRL-CAD instead |
| 17:38.58 | brlcad | and whether it should support zero is another question -- i can see a use there, so good to mod to support it |
| 17:38.59 | clock_ | Negative is good too |
| 17:39.05 | clock_ | if you model a body submerged in water |
| 17:39.34 | brlcad | hmm, interesting |
| 17:39.54 | clock_ | just subtract the density of water |
| 17:40.03 | brlcad | though the density of the object itself wouldn't be changed |
| 17:40.17 | brlcad | that might be better managed at a higher level where you can do the physics better |
| 17:40.27 | clock_ | this does the physics perfectly |
| 17:40.50 | brlcad | which is probably where you could also deal with objects whose weight you didn't want to take into account too |
| 17:41.12 | clock_ | That would make the makefiles too complicated |
| 17:41.19 | brlcad | it just does a simple density/mass calculation for you ;) |
| 17:41.23 | clock_ | and now it works even when the zero entry is at index 0 ;-) |
| 17:42.15 | clock_ | Are you going to include pix-y4m? |
| 17:42.42 | brlcad | i'd like to, but there are a few things that would need to be addressed |
| 17:43.20 | clock_ | And you would like me to re-program it? |
| 17:43.57 | brlcad | no no, the code does what it does and is useful |
| 17:44.08 | brlcad | the things to be addressed are more inclusion issues |
| 17:44.23 | brlcad | docs, integration |
| 17:44.48 | brlcad | aside from a manpage would be nice, presently contributions request assignment of copyright to be included |
| 17:46.04 | brlcad | you can still retain authorship, and get full credit for the work -- but for licensing purposes, there's only one copyright for the non-public-domain portions |
| 17:47.08 | brlcad | this makes it easier to relicense the code as needed down the road, since you don't have to hunt down every contributor (and understandably, some don't like that, but presently it's the project position) |
| 17:48.34 | brlcad | it's particularly relevant for what you wrote even as there are design plans to turn the image processing tools into a "universal converter" library |
| 17:49.26 | brlcad | in support of that kind of design change, all of BRL-CAD's GPL code (which is presently all the front-end applications) is going to change to LGPL |
| 17:53.27 | clock_ | In Czech Republic there is nothing like copyright therefore it's not possible to assign it |
| 17:53.39 | clock_ | There is only authorship and that's given by definition and cannot be changed |
| 17:53.45 | clock_ | How it's in Switzerland I don't know |
| 17:54.47 | brlcad | if there's nothing like copyright, then why does the code have a copyright clause? |
| 17:55.16 | brlcad | most licenses are based in copyright law, especially GPL/LGPL/BSD, etc -- even internationally |
| 17:55.45 | clock_ | I write (c) <year> <author> everywhere - this is the copyright clause? |
| 17:56.01 | brlcad | also, this isn't anything new -- there are lots of major international projects that require copyright assignment |
| 17:56.08 | brlcad | yes, that is exactly what the (c) means |
| 17:56.23 | clock_ | I didn't know this means anything special legally |
| 17:56.38 | clock_ | In CZ it definitely doesn't mean anything it's just a text string without any legal meaning |
| 17:56.58 | clock_ | I saw it being used so I did the same by example ;-) |
| 17:57.28 | brlcad | I'm sure cz actually does have some form of copyright protection |
| 17:57.36 | clock_ | It has author right |
| 17:57.47 | clock_ | if you create something, a right is implicitly created |
| 17:58.29 | brlcad | same holds in most places |
| 17:58.42 | clock_ | but that right is not transferrable |
| 17:58.47 | clock_ | you can only give licence to use |
| 17:59.10 | clock_ | and that right is created by the act of creation itself you don't have to write any (c) anywhere |
| 17:59.26 | clock_ | if you write (c), it's like if you didn't write anything - you have the right regardless |
| 18:00.14 | brlcad | it's the same in most places, even in the U.S., you don't *have* to write (c) -- it's automatic -- but the legal basis is weaker if you actually have to defend something in a court |
| 18:01.08 | brlcad | regardless, i'm not going to believe that czech doesn't have a means to allow copyright assignment, though, without a solid reference |
| 18:01.12 | brlcad | not that it's relevant for this |
| 18:01.40 | clock_ | all you can do is give a non-exclusive licence or an exclusive licence |
| 18:01.45 | clock_ | including a licence to sublicence |
| 18:02.03 | clock_ | but you cannot get rid of that copyright (in Czech terms it's called Author's right) |
| 18:02.18 | brlcad | again, i doubt that, highly doubt that as business interactions generally require authorship transfer |
| 18:02.37 | brlcad | unless you have a link to share that shows otherwise |
| 18:03.26 | clock_ | My GPL code is taken from Links and it's tainted by Mikulas's code |
| 18:03.33 | clock_ | the overalloc() is written by Mikulas |
| 18:03.40 | clock_ | so now it already involves two people ;-) |
| 18:03.59 | brlcad | i'm educating myself, hold on ;) |
| 18:04.00 | clock_ | I cannot change to LGPL by myself |
| 18:06.24 | brlcad | looks like Article 26(1) of cz copyright will let you grant all rights use with unrestricted scope -- that would be sufficient for a purpose like this |
| 18:06.38 | brlcad | though like you said, you've already got joint authorship going so you can't change it regardless |
| 18:06.53 | clock_ | I wouldn't grant anyway |
| 18:07.12 | brlcad | which means it really can't be included then unfortunately, unless you changed to LGPL or BSD |
| 18:07.13 | clock_ | unrestricted scope? That's ridiculous |
| 18:07.34 | clock_ | what if I change to BSD but don't grant unrestricted scope? |
| 18:07.44 | clock_ | BSD still has some (minimal) restrictions |
| 18:07.55 | brlcad | the domain of the scope is still just that contribution ;) |
| 18:08.07 | brlcad | not sure what you think it means |
| 18:08.19 | clock_ | but then you could take my contribution and sell it to Microsoft ;-) |
| 18:08.58 | clock_ | Or you can include one program under GPL ;-) |
| 18:09.03 | brlcad | technically, that's what copyright assignment means too -- changes are provided in good faith that the copyright holder wouldn't ever do that |
| 18:09.18 | clock_ | Or make a public version that will include the GPL program and your contractors will get only the LGPL |
| 18:09.45 | brlcad | contractors? |
| 18:13.12 | clock_ | "this makes it easier to relicence the code" |
| 18:13.40 | brlcad | here's a rather public project that you might be familiar with that has a decent write-up on the issues |
| 18:13.44 | brlcad | http://www.gentoo.org/proj/en/devrel/copyright/index.xml |
| 18:14.02 | brlcad | pretty much the same concerns and motivations here |
| 18:14.06 | clock_ | Why do you want me to licence under LGPL? |
| 18:14.38 | brlcad | well in particular because the code would be likely made part of a LGPL library if it is included |
| 18:15.03 | clock_ | Is the whole BRL-CAD going to switch to LGPL? |
| 18:15.12 | brlcad | very soon |
| 18:15.20 | brlcad | the portions that are GPL, that is |
| 18:15.34 | clock_ | what licence are the other portions? |
| 18:16.14 | brlcad | the build infrastructure, benchmark suite, various scripts, and a few contributed tools are BSD licensed |
| 18:16.39 | clock_ | Why are you switching to LGPL? |
| 18:16.43 | brlcad | the documentation that isn't already public domain is dual-licensed GPL/GFDL (you choose) |
| 18:17.20 | brlcad | brl-cad's libraries have to remain lgpl or bsd because of the user base |
| 18:17.31 | clock_ | What does it mean because of the user base? |
| 18:18.06 | clock_ | I hate this free software / open source politics ;-) |
| 18:18.09 | brlcad | there are government, educational, and commercial entities that use brl-cad for various purposes, linking to brl-cad's geometry engine and ray-trace library for functionality |
| 18:18.25 | brlcad | in codes that cannot be made open source, but are distributed |
| 18:18.30 | clock_ | Do they use them in proprietary software? |
| 18:18.49 | brlcad | some do, yes |
| 18:19.23 | brlcad | some are classified codes with security implications (and not just U.S., several nations) |
| 18:19.38 | clock_ | Why should I allow proprietary software to link my code? |
| 18:19.45 | brlcad | you don't have to |
| 18:19.48 | brlcad | that's your right |
| 18:19.54 | clock_ | with LGPL or BSD you allow |
| 18:20.03 | brlcad | but to be included in brl-cad, it would be required |
| 18:20.54 | brlcad | lgpl and bsd let the closed codes utilize the functionality they require, and provide a mutual benefit by promoting the software, giving credit of use, being part of the user base, etc |
| 18:21.36 | brlcad | we don't exist to push a political software agenda, my main concern is the open flexibility and usability of brl-cad by anyone |
| 18:22.24 | clock_ | classified codes and security implications |
| 18:22.41 | clock_ | I can't see their codes, they won't be able to use my software ;-) |
| 18:23.13 | brlcad | as you currently have it licensed, for a distributed code, that's true |
| 18:23.27 | brlcad | if it's not distributed, even gpl doesn't prevent them from using your code, though |
| 18:23.30 | clock_ | why do they need to classify anything? Good nations don't have anything to hide ;-) |
| 18:23.56 | clock_ | that's right |
| 18:24.31 | clock_ | but what they cannot do is that Army Subcontractor X makes an add-on nuke-calculating package and then sells it to US Army under classified code blah blah |
| 18:25.14 | clock_ | and then US Army calculates up better nukes and will make grins at other nations who can't calculate their nukes so well |
| 18:25.17 | brlcad | just about every subcontractor is explicitly required to assign copyright to the government, as well as all rights |
| 18:25.32 | clock_ | When they are going to calculate nukes with my code, then at least everyone will have the same opportunity |
| 18:26.01 | brlcad | actually, wouldn't they just be making pretty animations of the nukes with your code? |
| 18:26.22 | clock_ | whatever, but it will help them save time ;-) |
| 18:26.31 | clock_ | today the nukes aren't relevant anymore |
| 18:26.39 | clock_ | they have been technically overcome by terrorism |
| 18:27.06 | brlcad | there are biothreats considerably more dangerous than nukes |
| 18:27.59 | clock_ | like old salad sauces? |
| 18:28.18 | brlcad | but I digress .. so back to the point, if you do happen to relicense the code to bsd or lgpl, it can be reconsidered .. but it sounds like a non-starter on both sides for now |
| 18:28.44 | clock_ | I don't really like the idea of relicensing the code |
| 18:28.53 | brlcad | i understand, that's fine |
| 18:30.18 | clock_ | Is it legally possible to distribute almost all files in BRL-CAD with LGPL and one source code under GPL, while the source code and the rest don't mutually link? |
| 18:30.19 | brlcad | could add it as one of our "contributed" codes, but then you'd need a build file, documentation, a pressing demand, and other tidbits to be included |
| 18:30.33 | clock_ | what is the pressing demand? |
| 18:31.09 | brlcad | I looked into that a while back, from my reading -- you can't incorporate gpl code into a lgpl library without it becoming a gpl library |
| 18:31.24 | clock_ | but my code is standalone it doesn't require any library |
| 18:31.51 | brlcad | what I said earlier |
| 18:32.05 | clock_ | do you want to put my code into a library? |
| 18:32.29 | brlcad | there's going to be a "universal" image converter library made out of ost of the image processing tools |
| 18:32.43 | brlcad | so you can have an api to go to/from any image format to another |
| 18:32.59 | brlcad | similar to magick's convert tool, though we could also expand into geometry too |
| 18:33.29 | brlcad | aside from just having it as a generic conversion library in itself for reading/writing dozens of formats |
| 18:33.46 | brlcad | so yeah -- if it was included, I'd want to make it part of that library |
| 18:34.00 | clock_ | but that's in long-termm isn't it? |
| 18:34.01 | brlcad | wouldn't make sense to leave it out (other than the legal problem) |
| 18:34.13 | clock_ | and my code is not much universal |
| 18:34.53 | brlcad | your code doesn't have to be, that's the beauty of the library |
| 18:36.08 | brlcad | e.g. there's a png-pix and a pix-y4m but obviously not a png-y4m, the library would give you that functionality by tying them together for you |
| 18:37.49 | brlcad | anyways, going to LGPL is only one aspect.. like http://www.gentoo.org/proj/en/devrel/copyright/index.xml mentions, there are other legal issues like defending the code in court against litigation, to be able to protect against misuse and go after violations of the copyright |
| 18:38.10 | clock_ | <PROTECTED> |
| 18:38.10 | clock_ | <PROTECTED> |
| 18:38.26 | clock_ | Can you find it in the viewweight.c this way or do I have to make a patch? |
| 18:38.37 | clock_ | the >= was originally only > and that was the problem |
| 18:40.31 | clock_ | Hehe with LGPL my code could be incorporated into a proprietary package and that sold to North Korea :) |
| 18:41.54 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/src/rt/viewweight.c: allow an index of 0, even if the density is going to be 0 so that objects can be treated as having no mass (thx clock) |
| 18:42.02 | clock_ | good :) |
| 18:42.21 | brlcad | again, that's pushing a political agenda that you have there -- I couldn't care less about the political aspect :) |
| 18:43.08 | brlcad | i don't pick licenses for the politics, i pick them on it helping collaboration and allowing flexible use (by anyone for any reason) |
| 18:43.11 | clock_ | I publish my code not because I don't value my work, but because I agree with the idea of GPL. |
| 18:43.45 | brlcad | that's what it's there for, more power to you |
| 18:43.49 | clock_ | Otherwise I could give them into public domain easily. |
| 18:43.51 | brlcad | you don't happen to run debian do you? |
| 18:43.56 | clock_ | no |
| 18:43.59 | clock_ | OpenBSD ;-) |
| 18:44.25 | brlcad | surprising |
| 18:44.28 | brlcad | most BSD users aren't too fond of the GNU philosophy |
| 18:44.31 | clock_ | do I talk like a debianist? |
| 18:44.36 | brlcad | yep |
| 18:44.50 | brlcad | debian is a gnu propaganda machine :) |
| 18:44.55 | clock_ | lol :) |
| 18:45.01 | clock_ | According to my experience, debian is crap |
| 18:45.06 | brlcad | heh |
| 18:45.07 | clock_ | I didn't get farther than the boot CD :) |
| 18:45.37 | brlcad | ubuntu gets much of the same done without the bull-headed political motivations that debian has |
| 18:45.39 | clock_ | I used to use linux from scratch, gentoo, and recently (like 1 year?) OpenBSD |
| 18:45.41 | brlcad | and is considerably easier to use |
| 18:46.05 | clock_ | I don't care about the politics I care more about whether the system works |
| 18:46.17 | clock_ | Linux has half of the manpages missing, too hard to use for me |
| 18:46.24 | clock_ | 10 years of Linux was enough ;-) |
| 18:46.33 | brlcad | you care at least a little bit about the politics it sounds |
| 18:46.36 | brlcad | at least for your own code |
| 18:46.57 | clock_ | yes |
| 18:46.58 | brlcad | if you have a problem with proprietary software, you care about the politics |
| 18:47.07 | clock_ | I couldn't care less that I am using something that's BSD ;-) |
| 18:47.37 | clock_ | I don't like the idea of proprietary software, because people sacrifice efficiency of human work for monetary gain |
| 18:47.41 | brlcad | spent a LONG time weighing the impact of just making all of BRL-CAD licensed under BSD |
| 18:48.48 | brlcad | anyways, I gotta run off to lift |
| 18:48.53 | brlcad | cya |
| 18:49.01 | clock_ | What I can do is take BRL-CAD, add it to pix-y4m and then publish as Twibright Labs Enhanced BRL-CAD, am I right? |
| 18:49.22 | clock_ | cu |
| 18:51.24 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/NEWS: Karel points out a mod that allows material ID of zero in rtweight, fixes index bug. |
| 18:51.46 | brlcad | probably not, as there's a trademark on the name BRL-CAD -- but you could make the Twibright Labs CAD system (if it were BSD) |
| 18:52.36 | brlcad | it just wouldn't get you much -- about as fruitful as if you forked OpenBSD |
| 18:53.14 | brlcad | the project generally has to be doing something really wrong (e.g. XFree86 -> X11) to get a major code to fork successfully and rebrand with a maintained user group |
| 18:56.12 | brlcad | anyways, really off now -- cheers |
| 19:26.18 | clock_ | What does the LOS mean? |
| 19:26.24 | clock_ | When it's 0 and not 100 it doesn't work :) |
| 21:37.50 | *** join/#brlcad docelic (n=docelic@212.15.172.167) |