00:00:21 * kipple is backing up as much as possible before low-level formatting his server
00:02:05 <GregorR-L> pgimeno: If you're still up, give <pre> and <script> a shot.
00:05:36 <pgimeno> oh, found it, this quote's for kipple: http://www.formauri.es/personal/pgimeno/misc/labyrinth.php?q=ba+ba+ba#quote
00:06:07 <pgimeno> I wrote a Labyrinth movie quoter
00:06:53 <pgimeno> there are so many real life aspects that remind me of moments in the movie...
00:13:52 <pgimeno> hehe, the previous formatting has been undone
00:16:12 <pgimeno> when editing, the line breaks have been lost
00:16:25 <pgimeno> it doesn't matter as long as it works well next time
00:18:33 <pgimeno> now if it does not convert entities it will be almost perfect
00:22:50 <pgimeno> I know, it's just that it's annoying to re-change them again and again on each edit
00:27:09 <pgimeno> yuck, too late for me, g'nite
00:33:50 <GregorR-L> Well, just fixed the entities problem :P
00:42:20 -!- wooby has joined.
00:46:07 <wooby> that cfdg program is incredible
01:08:42 -!- GregorR-L has quit ("Leaving").
03:02:45 <CXI> for the record, there's no particular risk of esolangs being deleted at the moment, this is just generally trying to work out a solution to the problem
03:06:12 <CXI> a fair few of them are likely to be deleted at some point or another for being not terribly relevent to anyone outside the esolang community
03:16:32 <GregorR> Poor 2L, we hardly new ye :P
03:20:23 -!- kipple has quit (Read error: 110 (Connection timed out)).
04:00:30 -!- wooby has quit.
06:28:15 -!- GregorR-L has joined.
07:59:59 -!- clog has quit (ended).
08:00:00 -!- clog has joined.
09:31:33 <pgimeno> GregorR[-L]: it works perfectly now! good work
09:40:05 -!- GregorR-L has quit (Read error: 60 (Operation timed out)).
11:50:18 -!- kipple has joined.
13:14:40 <pgimeno> okay, the text is ready; I have posted it in my web though because it's too long
13:15:20 <pgimeno> http://www.formauri.es/personal/pgimeno/misc/server.html
13:15:55 <pgimeno> all that is left is to put the link in the ML
13:17:06 <kipple> in the paragraph about wikipedia you should mention that most of the langs there constantly face the threat of deletion.
13:18:44 <pgimeno> I'll copy what CXI said in that respect:
13:18:56 <pgimeno> <CXI> for the record, there's no particular risk of esolangs being deleted at the moment, this is just generally trying to work out a solution to the problem
13:18:56 <pgimeno> <CXI> a fair few of them are likely to be deleted at some point or another for being not terribly relevent to anyone outside the esolang community
13:22:00 <pgimeno> so that's not such a constant threat actually
13:22:10 <kipple> it has happened already that some langs have been deleted (i.e. homespring), so it could happen anytime...
13:22:31 <kipple> anyway. very nice text. good work!
13:22:44 <kipple> could we have a link to it in topic?
13:22:50 <pgimeno> hm, maybe it's worth mentioning, you're right
13:22:54 <CXI> well, I was trying to say that while there's no particular reason a language would be deleted now as opposed to later, the threat's still there
13:27:46 <pgimeno> I've changed it adding the part in parentheses in this sentence: "Before removal of any Wikipedia stuff (which is a constant threat) an alternative place..."
13:29:13 <kipple> anybody know who can set channel topic here? (I think Keymaker can)
13:29:30 <pgimeno> try by yourself, I think it's not locked
13:29:48 <kipple> ah. Have no idea how to do that
13:31:58 <kipple> OT: it sure takes time writing 160 billion zeroes....
13:33:21 -!- pgimeno has set topic: Another brainfuck site (http://www.bf-hacks.org/) is open! ~ http://chriscoyne.com/cfdg/ ~ Esolang Preservation project info: http://tinyurl.com/d3fk5.
13:33:45 <kipple> ha, the topic is getting crowded...
13:34:54 <CXI> huffman encode it
13:34:54 <CXI> then it'll be much shorter ;)
14:25:37 <kipple> I've written a short entry about what we have discussed in the Talk section of the esolang list in the Wikipedia. Hopefully we'll get some response there as well.
14:26:17 <pgimeno> (I'm preparing the actual message to the list, btw)
14:30:28 <pgimeno> very good; hopefully that will prevent further deletions
15:09:57 <pgimeno> is it correct in English to say "there's nothing carved in stone" (idiomatic saying meaning nothing is definitive)?
15:11:25 <kipple> or is it "set in stone"? not sure
15:11:35 <CXI> standard usage is "nothing's carved in stone" but yeah
15:11:43 <CXI> (or set in stone)
15:11:58 <CXI> actually, set is probably more common
15:24:47 -!- comet_11 has joined.
15:27:38 -!- CXI has quit (Nick collision from services.).
15:27:40 -!- comet_11 has changed nick to CXI.
15:45:14 -!- malaprop has joined.
16:00:35 -!- wooby has joined.
17:03:04 -!- comet_11 has joined.
17:10:07 -!- CXI has quit (Read error: 60 (Operation timed out)).
17:54:40 -!- GregorR-L has joined.
17:57:40 <GregorR-L> Hmm, while I have no problem with viral licenses (I prefer them even), I don't like the GFDL.
17:58:55 <kipple> well, I don't think we should impose a certain license
17:59:28 <GregorR-L> Yeah, certainly the wiki software should not impose a license, that's illogical.
17:59:52 <kipple> different esolangs are under different licences, and we should be able to host them all
18:00:10 <GregorR-L> Like ASP, under the shared source license.
18:00:15 <kipple> but are there any wiki software in question that impose a license?
18:00:39 <kipple> that is not a software. that is a hosting service.
18:00:48 <kipple> we can still use MediaWiki on our own servers
18:00:52 <GregorR-L> OK, OK - a possible option then ;)
18:01:22 <pgimeno> so far there's only calamari's
18:01:46 <GregorR-L> I've got an Apple Workgroup Server running Debian at home, but no hostable connection :P
18:02:06 <kipple> (not on my home server, but something more stable )
18:02:17 <wooby> i run a server, i'd be willing to share resources
18:02:36 <wooby> its a usermode linux thing out in california running slackware
18:03:14 <wooby> what do you guys need to do?
18:03:44 <kipple> agree on a wiki platform :)
18:03:51 <pgimeno> have you read the link at the topic, wooby?
18:04:18 <pgimeno> it's a good starting point :)
18:04:40 <wooby> na i'm just sort of babbling
18:05:42 -!- wooby has quit ("My damn controlling terminal disappeared!").
18:06:00 -!- wooby has joined.
18:06:25 <wooby> the 'ole client flipperoo
18:08:01 <GregorR-L> Cool, cool. Heard the rumors about Apple switching to Intel?
18:08:18 <wooby> yeah i saw some hubub about that
18:08:57 <pgimeno> well, we need three things: 1) mirror sites (one of them, still to decide, will be the central server), 2) editors, 3) agree on a wiki software
18:08:58 <wooby> i don't really care what chip they use
18:09:02 <wooby> i just bought mine to look cool :)
18:09:19 <GregorR-L> Seems unlikely to me - though I can definitely see them switching to centrino laptops. There would be a huge issue with platform compatability if they only half-changed though.
18:11:18 <wooby> the one calamari picked looks nice... the wiki software, that is
18:11:18 <malaprop> I can offer hosting/mirror. Been on the list a few years, didn't know the channel existed.
18:11:36 <wooby> yeah i can do the mirror thing too
18:12:08 <kipple> great. looks like we have plenty of hosting options.
18:12:30 <GregorR-L> wooby: MoinMoin is nice, but python - if all the hosts have python, it quite wins.
18:13:03 <kipple> anybody have problem running a wiki which requires python or mysql?
18:13:14 <pgimeno> malaprop: can you offer python?
18:13:16 <GregorR-L> kipple: Doesn't MoinMoin use flat files?
18:13:17 <kipple> I mean, you who just now offered hosting?
18:13:29 <malaprop> I can run Python CGI, but not mod_python or more esoteric frameworks.
18:14:05 <kipple> MediaWiki (my favorite) requires mysql
18:14:22 <malaprop> MediaWiki is also my favorite, but I don't have a strong preference.
18:15:25 * kipple dislikes when the links use CamelCase (i.e. BrainfuckDerivativeProgammingLanguages)
18:15:48 <GregorR-L> Though I use that in programming all the time :P
18:16:07 <malaprop> OK, MoinMoin does support CGI. Will not be fast that way, but it has other, faster frontends like FastCGI, Twisted, and mod_python.
18:16:30 <malaprop> So if MoinMoin is picked, I can be a backup but not primary.
18:16:47 <wooby> i'd prolly do the fastcgi thing, because i just have a preference for lighttpd
18:16:53 <wooby> so in any case it's runnable
18:17:26 <kipple> hmm. is there an easy way to check if a web server supports mod_python or similar?
18:17:44 <malaprop> grep mod_python /path/to/httpd.conf
18:21:22 <kipple> and if I don't know where httpd.conf is? or if I even have read access...
18:21:44 <wooby> or /etc/httpd, /etc/apache... osmething like that
18:21:59 <kipple> yeah, that was what I was looking for, but no....
18:22:27 <GregorR-L> Sometimes the 404 error page will show mod_* in the banner.
18:23:44 <GregorR-L> If it doesn't say "python" anywhere, you probably don't have it. But you probably still can do python CGI.
18:27:15 <GregorR-L> find / -name (whatever) takes a long time ;)
18:27:43 <kipple> no httpd.conf, apache.conf or apache2.conf. ah, well. not important
18:30:18 <GregorR-L> lol, somebody should write a BF parser for some wiki, so your input can be BF if you want :P
18:30:40 <wooby> or lets just write a whole wiki in BF, and run BF cgi :)
18:31:18 <malaprop> Heh, I was tempted to write a Befunge CGI gateway.
18:31:22 <GregorR-L> The total lack of file I/O could be an issue.
18:32:05 <pgimeno> kipple: probably the file is not indexed; try (as root): find /etc -name "httpd.conf"
18:32:42 <kipple> umm. I do not have root access... If it were my server it wouldn't a problem
18:33:02 <malaprop> You could write an extension for MediaWiki that would take anything between tags like <bf></bf> and run it through an interpreter.
18:33:32 <pgimeno> kipple: hm, then I don't know if 'find' can enter the dirs where httpd.conf is
18:33:48 <wooby> malaprop: or perhaps an extension that supported arbitrary esolang parsing
18:33:53 <kipple> i have a feeling I wont be allowed to view it anyway..
18:34:02 <kipple> that would be very cool
18:34:27 <malaprop> wooby: It'd need customization for each language to hook up to the interpreter. And there'd be security concerns for any esolang with network/file i/o.
18:34:35 <kipple> <eso lang="bf"> </eso>
18:34:41 <wooby> oh of course it's a completely... esoteric notion :)
18:34:47 <pgimeno> probably something like <?bf +++[>+++<-] etc ?>
18:35:12 <pgimeno> hm, I also like kipple's idea
18:35:19 <malaprop> pgimeno: For MediaWiki extensions, tags are all <tag></tag>.
18:35:36 <pgimeno> malaprop: oh ok, didn't know that
18:39:14 -!- wooby has quit.
18:40:22 <pgimeno> my thought was more like using bf as a php substitutive
18:41:23 <kipple> I've thought of that as well. but it's not going to be very usable....
18:42:34 <pgimeno> what's the prob? BF is a wonderful language for text expansion :P
18:42:39 <kipple> well, I've written a BF program that I actually use
18:43:45 <pgimeno> BF for real life? go away, you freak!!!
18:44:31 <kipple> it takes a BF program and reomoves all non BF-chars and outputs it in nice 80 chars per line :D
18:44:32 <GregorR-L> Hmm .. would have been good if I did that right.
18:44:58 <kipple> can't say I use it every day, though
18:45:46 <GregorR-L> It would be nice if there was some way to inject PHP into a wiki but safely ... reject a large class of functions, etc.
18:47:09 <lindi-> depending on the functions that can be impossible to solve
18:47:29 <GregorR-L> Since it's a constantly increasing count.
18:48:00 <lindi-> i was refering to Rice's theorem
18:48:22 <lindi-> GregorR-L: http://en.wikipedia.org/wiki/Rice's_theorem
18:49:24 <kipple> I guess you could parse the injected PHP and compare it to a function white-list
18:49:50 <malaprop> kipple: That's what MediaWiki's TeX extension does in a nutshell.
18:55:08 <kipple> anybody know if any of the wiki's allows java applets in some way?
18:55:28 <kipple> I guess it is easy to write a MediaWiki extension to do it, but how about the others?
18:55:41 <GregorR-L> If you allowed uploads of .jar, you could do it in Giki.
18:56:08 <kipple> yes, because that allows any HMTL, right?
18:56:54 <kipple> there are a few java applet (and java script) online interpreters out there. would be nice to include them
18:57:18 <GregorR-L> Same problem as allowing PHP, right?
18:57:31 <GregorR-L> Suddenly people can freely post unsafe code that can destroy the server.
18:57:46 <kipple> java applets and scripts cannot (normally) affect the server
18:58:04 <GregorR-L> OHOH, I misinterpreted your sentence.
18:58:16 <GregorR-L> I thought you meant an interpreter for Java(Script) on the server :-P
18:58:24 <GregorR-L> Which seemed weird, since those are both client-side :P
18:58:37 <GregorR-L> But you meant an interpreter for a given langugae in Java(Script)
18:58:57 <kipple> several esoteric pages have them
19:56:29 -!- calamari has joined.
19:57:35 <calamari> pgimeno: great job on the writeup! hopefully we'll see some discussion on the mailing list
19:58:48 <kipple> do you know if it is possible to include stuff like Java applets in the MoinMoin wiki?
19:59:40 -!- wooby has joined.
20:03:02 <wooby> so the domain esolangs.org is available
20:03:45 <calamari> kipple: no idea.. if Wiki! uses html, then it'd be possible there
20:03:52 <wooby> calamari: whats up!
20:04:21 <wooby> pumped about the idea of this preservation site
20:08:07 <calamari> kipple: with the java applets, I assume you're thinking of live language demos?
20:08:28 <kipple> javascript would also be nice
20:08:40 <kipple> in Wiki! and MediaWiki that should be easy
20:09:00 <calamari> I'll ask in #moin.. they are very helpful
20:13:43 -!- GregorR-L has quit (Read error: 113 (No route to host)).
20:14:56 <calamari> kipple: doesn't look like there's a good way to do it.. raw html can be allowed.. but there are risks involved with that (javascript redirects, for example)
20:15:53 <kipple> how about extensions/plugins?
20:16:00 <calamari> the way they said to do it was to save the java applet as an attachment, and reference it with the html
20:16:29 <kipple> you mean for download?
20:17:04 <calamari> yes & no.. I think it would show up as a clickable download.. but the html would run it like you see in other pages
20:17:21 <kipple> not sure what yuu mean
20:17:38 <kipple> upload both HTML file and applet?
20:17:39 <calamari> well, the java applet jar has to be stored somewhere
20:17:55 <calamari> so it will be downloadable like any other attachment
20:18:03 <malaprop> If you can't put an <embed> or <object> tag in a page's source, you can't have a Java applet on the page.
20:18:09 <calamari> then html code will be used to run the java applet
20:18:55 <calamari> malaprop: yep.. what I'm hearing is that there is a way to allow html in moinmoin pages
20:19:09 <calamari> so it'd work.. but it's a bit unsafe
20:19:29 <wooby> or maybe we could hack it to pop up a separate window, with the applet inside
20:19:50 <wooby> then you could tool around with the applet and read the article on the side
20:21:05 <calamari> it might be possible to hack moinmoin to add the necessary embedding code as another keyword
20:21:16 <calamari> then we don't have to enable html
20:21:32 <wooby> yeah that would be the best way
20:21:48 <kipple> looked a bit a plugins. I think it could be done as a Macro plugin
20:21:54 -!- andreou has joined.
20:22:10 <kipple> http://moinmoin.wikiwikiweb.de/MoinDev/PluginConcept
20:22:17 <malaprop> So moving MySQL dumps around is bad, but a patch to the wiki that'll have to be maintained for all the versions is OK?
20:22:39 <kipple> I have no problems with MySQL dumps
20:23:11 <kipple> but for MediaWiki you also have to sync uploaded files/images
20:23:51 <calamari> they say that a one line macro plugin is possible
20:23:53 <kipple> and we would need to add an extension to MediaWiki as well if applets are to be possible
20:25:40 <kipple> in MoinMoin I think that if you rsync the entire directory hirearchy you would get all patches as well
20:25:44 <calamari> malaprop: don't get bent out of shape.. nothing has been decided yet ;)
20:26:32 <calamari> yeah, rsync sounds good.. didn't even know such a program existed until the other day in here :)
20:26:54 <wooby> rsync is supersweet
20:27:07 <kipple> it works on MySQL dumps as well :) (unless they are zipped)
20:27:39 <calamari> http://lilly.csoft.net/~jeffryj/cgi-bin/moin.cgi/HelpOnMacros
20:29:40 <calamari> I need to leave.. but I can take a look at that later on.. I'm decent with Python, so maybe I can put something together
20:29:57 -!- calamari has quit ("Leaving").
20:37:43 <pgimeno> I'll ignore the "oh no" then :)
20:40:37 <lament> i meant: oh no, you missed calamari
20:44:37 <pgimeno> the security risks are minimized by only allowing editing by registered people IMO
20:45:21 <pgimeno> (about calamari's concerns with the security risks of allowing JavaScript)
21:04:34 -!- andreou has quit ("i be novel.").
21:21:46 -!- graue has joined.
21:22:25 -!- wooby has quit (Remote closed the connection).
21:24:19 <graue> so, we're all excited about preserving esoteric languages, eh?
21:38:57 <kipple> hey graue. It's you who has that wiki on voxelperfect isn't it?
21:40:24 <kipple> ah, yes it is (just saw your mail on lang)
21:41:58 <pgimeno> if my VNC desktops weren't a mess I would have read it before :)
21:42:36 <GregorR> Well, I implemented a plugin system on the way to work :P
21:43:10 <GregorR> And a plugin to do a simple wikisyntax (with bold, italic, underline, headers, lists and tables)
21:43:14 <pgimeno> hope you don't drive your way to your work :)
21:44:57 <pgimeno> graue: I think we need fully functional mirror servers
21:45:28 <pgimeno> I have checked your work and I agree with you that it's better than Wikipedia's approach
21:46:09 <pgimeno> the content you've added is perfect; now the question is whether to continue with MediaWiki or to switch to a different one
21:47:47 <pgimeno> GregorR: I'm not sure we're finally going to use Wiki!
21:49:15 <pgimeno> if rsync can handle MySQL databases and the mirrors can use rsync, probably that covers all needs despite my initial doubt about MySQL
21:49:26 <GregorR> pgimeno: I'm fully aware of that, but that doesn't mean that I won't be using it ;)
21:50:06 <GregorR> rsync of a MySQL dump would be equivilant to downloading the entire database every time I think ... the advantage of rsync on flat files is it only downloads the updated files.
21:51:41 <GregorR> So why use rsync instead of just scp ;)
21:52:00 <pgimeno> apparently rsync also updates the local database
21:52:16 <pgimeno> that's what I understood from previous discussion at least
21:52:37 <pgimeno> I'm not fully convinced about MySQL anyway because it's just another possible point of failure
21:53:07 <malaprop> pgimeno: How many 9s of uptime do we need? MySQL is common and stable.
21:53:12 <GregorR> Wait ... through MySQL? No, rsync just does files, it doesn't plug in to MySQL anyway...
21:54:15 <malaprop> can mysqldump to files in any case
21:54:20 <pgimeno> malaprop: well, from time to time I see a message in Wikipedia about a database server restart
21:54:53 <GregorR> pgimeno: Yeah - though there is an rsync protocol, so perhaps there is a program that uses the rsync protocol with MySQL?
21:55:01 <malaprop> They have a much different, larger architecture with many masters and slaves. I would be surprised if this ever even required a dedicated MySQL server.
21:55:23 <pgimeno> GregorR: not sure, I thought so as per a previous discussion with calamari
21:56:23 <malaprop> As a counter-example, here at work the .pro GTLD backends to MySQL and we have a contract with ICANN requiring so 99.87 to 99.999% uptime on various things. We've never had an issue.
21:56:54 <pgimeno> malaprop: well, I'm not against it, I just have my doubts but will accept it as a final decision
21:57:41 <malaprop> pgimeno: What else causes you to doubt MySQL uptime? I'm not trying to have an argument, you're just the first person I've met to consider it unreliable.
21:58:31 <pgimeno> being a database server, not just for being mysql, has a few issues
21:59:13 <malaprop> So you'd just rather see a filesystem backend instead of a db?
22:00:08 <pgimeno> partial recovery in case of disaster is easier with files than with a monolithic database file
22:01:48 <GregorR> Plus, using a relational database with a wiki is sort of overkill. And by sort of ... I mean entirely.
22:01:50 <pgimeno> space growth can be a problem too, I don't know how MySQL handles that but I think it's the smartest in that sense
22:03:40 <graue> i could make a site managed as flat files through subversion
22:03:48 <GregorR> Oh, just remembered. About patches for "Wiki!" - wouldn't we want the wiki software itself to rsync down with everything else, regardless of what software it is? I mean, all software has versions ...
22:03:52 <malaprop> GregorR: Things like backlinks benefit greatly from a deb structure.
22:04:17 <GregorR> Also overkill in my opinion, but *cough* :P
22:04:33 <GregorR> Yeah, I can see your point, that is.
22:05:13 <pgimeno> graue: the main question with the subversion approach is that we need decentralization
22:06:21 <pgimeno> using svn is good for projects that are centralized in one server
22:08:13 <GregorR> pgimeno: s/deb/DB/ I think
22:17:51 <pgimeno> what do you mean, malaprop?
22:19:10 <malaprop> pgimeno: btw, no wiki runs decentralized -- can have multiple frontends (apaches), but one backend (db, fs). So all mirrors will be read-only regardless of wiki.
22:19:59 <kipple> um. the point here is to have each mirror be COMPLETE. whether they use fs or db
22:21:04 <malaprop> Ya, and that's possible, but all but one need to be read-only. Otherwise the different wikis will get out of sync.
22:21:46 <kipple> anyway, i looked up in the rsync man pages: "the rsync remote-update protocol is used to update the file by sending only the differences"
22:21:58 <kipple> I think it will work fine on a mysql-dump
22:22:40 <pgimeno> malaprop: ok, but can a read-only mirror become read-write in case the read-write one fails? that's the point
22:23:00 <graue> pgimeno, with a full mysql dump, yes
22:23:04 <malaprop> Ya, just need to have humans making sure the right one is read-write and at the right times. :
22:23:20 <kipple> but a mysql-dump is not enough
22:23:33 <kipple> uploaded files and images must also be backed up
22:23:43 <graue> those would be in the database, if they're part of the wiki
22:24:00 <malaprop> graue: No, MediaWiki stores images/files on disk in images/
22:24:39 <kipple> so they have to be rsync'ed as well
22:24:44 <pgimeno> that's no problem as long as everything is sync'ed
22:25:25 <kipple> if you put them in the same hierarchy as where the db-dumps are one call to rsync is enough
22:26:01 <pgimeno> regarding r/w vs r/o, the only caution to have is to update the mirrors to point to the new server before letting it be read-write
22:26:02 <kipple> then there is the issue of Wiki settings
22:26:20 <pgimeno> aren't these in the database too?
22:26:26 <kipple> MediaWiki stores some settings in a php file
22:27:15 <pgimeno> mmh... can that file be included in the pack?
22:27:20 <malaprop> So putting the mysqldump into wiki/ and making wiki/ the target of rsync will keep everything in sync all the time. All the PHP, images, files, db.
22:27:34 <graue> wiki/ is actually empty
22:27:38 <graue> the php, images, etc. are in w/
22:27:38 <kipple> yes. that's the way to do it probably
22:27:54 <malaprop> graue: wiki/ is the default name IIRC, is no biggie
22:27:54 <graue> also, most of LocalSettings.php is site-specific (e.g., the MySQL user/password)
22:28:13 <graue> no, the default, and how wikipedia is set up, has all the files in w/
22:28:28 <graue> wiki/ is an empty directory and urls within it are rewritten with mod_rewrite
22:28:53 <kipple> the problem is site specific settings
22:29:20 <pgimeno> perhaps that file doesn't need to be transferred
22:29:39 <kipple> but it has some settings that should be used...
22:29:45 <graue> LocalSettings.php controls cosmetic stuff and skins and the license (public domain in our case)
22:29:52 <graue> it doesn't seem to have anything relevant to the content
22:31:24 <GregorR> Even so, download everything then run a script over any settings to make them local, that's not too tough.
22:31:57 <malaprop> As hosts should fail fairly infrequently, is not a big hassle.
22:32:27 <kipple> rsync can be told to exclude file patterns, so no biggie
22:32:37 <pgimeno> well, revealing the mysql username/password is not a good idea :)
22:32:48 <pgimeno> a sed script or something should be used to hide them
22:33:33 <kipple> the files which contains "secrets" should have their permissions set properly, and it wont be a problem
22:34:28 <GregorR> Oh, there's a problem I realized with ALL file-based systems - generally, the files are created by (and hence owned by) the web server user (such as "apache"), and hence would not be writable by the user doint the updates.
22:35:28 <GregorR> Actually, lemme think about this ... if on the only editable node, they're owned by apache and readable by the user, and on the other nodes they're owned by the user and readable by apache, is there a problem? Hmm...
22:35:53 <kipple> I don't see the problem...
22:37:35 <GregorR> Well, rsync would be run by the user with the cronjob. However, the httpd itself would be running under a different user, usually "apache." So, when a file is created in the wiki, it's owned by apache, not the user. If the user (through cron) then runs rsync, it won't be able to write over that file, since that user doesn't own it.
22:37:58 <malaprop> That's an issue for local apache configuration.
22:38:23 <GregorR> But many mirrors won't be able to configure their apache (not because of incompetance, but because of access)
22:39:02 <malaprop> Think of those as 'off-site backups' instead of 'live mirrors' then.
22:39:26 <GregorR> Yeah, I was thinking along that line when I made that second post.
22:39:37 <GregorR> The problem would be if we needed to change the master.
22:39:43 <GregorR> Since then files would need to change users.
22:46:50 <pgimeno> rsync can download the files from 127.0.0.1 through wget
22:49:57 <GregorR> rsync will already make them be owned by the user - that wouldn't change that.
22:50:22 <GregorR> If there was a web UPLOAD interface, that would work, but would be a whole lot of complexity for a relatively simple problem :P
22:50:31 <pgimeno> then curl can upload them through wget :)
22:50:41 <pgimeno> then curl can upload them, that is
22:51:29 <pgimeno> I think that that must have been solved, maybe there's an apache rsync module or something
22:52:48 <GregorR> Well, I don't think it would cause as much of an issue as I'm thinking - on the main server, it would be owned by apache and readable by the user (all it needs to serve them) and on the others, it would be owned by the user and readable by apache (all apache needs to wiki-fy them)
23:03:32 <pgimeno> graue: what do you think on the idea of rotating the main server every couple of months? I reckon you had first the idea and did the actual work of setting up a server for preservation of esolangs, so your opinion is important
23:04:40 <kipple> What's the purpose of this rotation?
23:04:51 <kipple> seems like just extra work to me
23:05:17 <GregorR> Speaking of the only situation where my users problem comes into play :P
23:06:13 <pgimeno> well, it will prove the mirrors to be fully functional and refresh the memory of how to do the change
23:07:47 <pgimeno> it will expose the problems that mirrors may have such as the potential issue that GregorR mentions
23:10:40 <graue> i think the languages should be esoteric and the wiki should not be
23:11:05 <graue> esoteric.voxelperfect.net is not doing anywhere, and if it does, a mysql dump and a .tar.gz of the uploaded files are all that will be required to save the content
23:11:10 <graue> why make it any harder than that?
23:12:43 <GregorR> AH! I've got the solution to my problem! If the rsync commands were written as a PHP or CGI script, cron would wget http://127.0.0.1/whatever.php , and then it would trigger the APACHE user to download! Hoopla :)
23:13:11 <pgimeno> I'm sometimes a bit paranoid :)
23:13:24 -!- kipple_ has joined.
23:14:03 <pgimeno> but you're right, graue - the KISS philosophy is by far the most effective one
23:16:32 <kipple_> I'm all for using graue's wiki
23:17:46 <kipple_> but downloading files as a tar.gz is not ideal
23:18:07 <kipple_> if people upload specs in pdf it can quickly become several megs
23:18:30 <pgimeno> however rsync has the same problem as python
23:18:45 <pgimeno> it needs support from the server
23:23:40 -!- wooby has joined.
23:24:00 <GregorR> rsync uses SSH to communicate - if I'm not mistaken (and I could be) it can connect to any server running OpenSSH.
23:24:00 <kipple_> about licencing: graue's wiki says content is public domain. How about adding content from pages that use GPL or similar.... Isn't that (in theory) problematic?
23:24:21 <kipple_> GregorR: as long as both machines have rsync installed
23:24:47 <GregorR> But there doesn't need to be an rsync daemon per se.
23:25:01 <kipple_> no. the daemon is not required.
23:25:31 <GregorR> It's bad for the wiki to say that the content is under ANY particular license, even public domain, since indeed posting GPL utilities could become illegal.
23:26:22 <kipple_> couldn't it say "Content is Public Domain, except where otherwise noted" or something?
23:28:12 <kipple_> IANAL but I think that might cover it
23:30:08 -!- kipple has quit (Read error: 110 (Connection timed out)).
23:33:24 <graue> well, the problem then is, some jerk can just add a paragraph to a page and say "Everything on here is now (c) me all rights reserved, ha ha ha!!!!!" and infect the page with viral copyright
23:33:57 <graue> i was thinking of a files repository separate from the wiki, actually, like what's at http://esoteric.voxelperfect.net/files/
23:34:56 <GregorR> If it stores history, one could just restore from before that like one would if somebody posted "PEEPEEPEEPEEPEEPEE" over content./
23:35:06 <pgimeno> grue: btw, I don't know if you're aware that Cat's Eye Technologies is back online
23:35:24 <graue> pgimeno, the wierd page there wasn't working when i checked, though
23:36:21 <pgimeno> it's working perfectly right now
23:36:37 <pgimeno> anyway it's a good idea to mirror it
23:37:14 <pgimeno> however that's the whole point of one of my last sentences about asking for permission to the authors
23:40:28 <pgimeno> Martijn van der Heide, the webmaster from www.worldofspectrum.org, is making a huge effort of gathering permissions to distribute everything he can for the 5000+ Speccy files he's hosting
23:41:17 <kipple_> I think licencing is only an issue for file up/downloads. The text in the wiki should be able to be PD
23:42:28 <pgimeno> he did kind of "cheat": he hosts the files and asks for permission; when someone denies it, he removes the files
23:42:44 <graue> heh, that's hardly a huge effort
23:43:22 <kipple_> anyways, Wikipedia contains copyrighted images and stuff, so can't be that big a problem
23:45:07 <GregorR> Hmm, how about "All text on this page is in the public domain, hosted files may include licensing information."
23:45:36 <graue> i added a short paragraph at http://esoteric.voxelperfect.net/
23:48:11 <wooby> i've gotten esolangs.org somewhat working, message me if you'd like a shell
23:48:18 <wooby> i can mirror whatever wiki we decide on
23:50:32 <pgimeno> graue: what version of MediaWiki is that?
23:51:30 <pgimeno> wooby: can you try to install MediaWiki?
23:51:47 <pgimeno> there's the issue of versions too, btw
23:51:53 <wooby> oh, what are we going with?
23:53:21 -!- calamari has joined.
23:53:34 <pgimeno> it's kind of a experiment to see if it may work.
23:54:07 <calamari> hi pgimeno, good job on that writeup :)
23:54:36 <pgimeno> graue is the owner of esoteric.voxelperfect.net
23:55:19 <calamari> is he interested in the whole mirroring thing? he didn't really say one way or the other
23:55:56 <calamari> hmm, seems I need to read more carefully
23:57:01 <pgimeno> well, he kind of proposes a KISS kind of philosophy: just a DB backup and a collection of files; no mirrors
23:57:42 <kipple_> um. with a db dump and the files, you can make as many mirrors you want, can't you?
23:59:21 <kipple_> provided that really is all you need... which we will hopefully soon find out