You can subscribe to this list here.
2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(20) |
Dec
(3) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2004 |
Jan
(23) |
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
(16) |
Sep
(7) |
Oct
(2) |
Nov
(3) |
Dec
(2) |
2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
(3) |
Nov
|
Dec
|
2006 |
Jan
|
Feb
|
Mar
(3) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2010 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2014 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
From: R0B R. <wit...@gm...> - 2014-12-17 13:36:29
|
Error 503 Service Unavailable Service Unavailable Guru Meditation: XID: 1360591448 ------------------------------ Varnish cache server http://blackboxwm.sourceforge.net/BlackboxAddons |
From: Balthasar I. <ba...@in...> - 2014-03-07 04:33:49
|
Hi guys, I'm trying to learn about add ons and configuring blackboxwm, but clicking on the respective links on the site results invariably in these types of messages: Error 503 Service Unavailable Service Unavailable Guru Meditation: XID: 804628512 The rest of the website works fine. Cheers - Balt |
From: Steve B. <sbr...@gm...> - 2010-04-29 23:42:59
|
I am really ignorant. I like Blackbox as a browser, and connecting via wire is no problem, but connecting wirelessly defeats me. Would someone walk me through how to hook up wirelessly in Blackbox? There are questions asked that I don't have any idea what the answers are. Please give me a hand with this |
From: Garcia F. <Ma...@bi...> - 2005-10-15 10:26:58
|
Forever young, forever on SPUR-M! Go on, give it a try. You'll sure enjoy it! SPUR-M: http://www.geocities.com/z02ksdk1op7uqd/ Discreet, unmarked packaging. |
From: Ciprian P. <ci...@zu...> - 2005-10-06 18:10:12
|
On Thu, 06 Oct 2005 14:45:03 +0200 Bradley T Hughes <bh...@tr...> wrote: > -------- Original Message -------- > Subject: SOURCEFORGE.NET: Notice to project admins regarding MySQL 4.1=20 > service Got it, I'll look it up. --=20 Ciprian Popovici |
From: Bradley T H. <bh...@tr...> - 2005-10-06 12:45:10
|
-------- Original Message -------- Subject: SOURCEFORGE.NET: Notice to project admins regarding MySQL 4.1 service Date: Thu, 6 Oct 2005 05:26:06 -0700 (PDT) From: SourceForge.net Team <no...@so...> To: bh...@tr... (All SourceForge.net project admins are getting this mail. We send this type of mailing out from time to time to make sure project admins are well-informed about major service changes.) Greetings, SourceForge.net project admin, Announcement of new MySQL 4.1 service: Recently, many projects have noted performance problems with our project web service and project database service (based on MySQL 3.23.x). It is our pleasure to report that these performance problems have been resolved and we have launched a new project database service offering, available now. This new service offering, based on MySQL 4.1.x, will replace our existing MySQL 3.23.x service. An overview of this, and other recent enhancements has been posted to our Site Enhancements list at: https://sourceforge.net/docs/A03/ Details of our new database offering: * Provides MySQL 4.1.x (the latest production release of MySQL) service to projects, in a manner that will allow us to more readily scale to meet future capacity needs. * Allows projects to create multiple databases, and provides three user accounts to access these databases (one each with read-only, read-write, and admin access). * Provides a centralized install of phpMyAdmin, allowing easy management of project databases, and eliminates the need for projects to maintain their own phpMyAdmin install. * This service is available for project use immediately and documented at: https://sourceforge.net/docs/E07/#mysql Notes on migration: To free additional resources to improve our MySQL 4.1.x service offering, we plan to discontinue MySQL 3.23.x service. Projects are responsible for migrating any existing database applications to the new MySQL 4.1.x service. A list of major features added since MySQL 3.23.x is available at the following URLs: http://dev.mysql.com/doc/mysql/en/nutshell-4-1-features.html http://dev.mysql.com/doc/mysql/en/nutshell-4-0-features.html As migration of data is application-specific, you may need to do some research in order to make the switch. We encourage you to review the documentation that comes with your applications, and contact the groups that develop those applictions if you need assistance. Changes to MySQL from 3.23.x to 4.1.x are detailed at: http://dev.mysql.com/doc/mysql/en/upgrading-from-3-23.html http://dev.mysql.com/doc/mysql/en/upgrading-from-4-0.html Notice of planned shutdown of MySQL 3.23 service: MySQL 3.23 service will be shut down on 2005-11-01. MySQL data remaining in these databases will be removed at that time. Please migrate your data and applications to our MySQL 4.1.x service prior to 2005-11-01, if desired. We'll handle the clean-up of old MySQL 3.23 data -- no need to do any house cleaning on the old database before we shut down that service. We believe our new MySQL service offering is a dramatic improvement, and will meet the needs of most projects. Questions or concerns (if not answered in our Site Documentation), please submit a Support Request at: https://sourceforge.net/tracker/?func=add&group_id=1&atid=200001 If you believe you have received this message in error, please contact us by Support Request (link above). Thank you, The SourceForge.net team --- Tame your development challenges with Apache's Geronimo App Server. Download it for free--and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php --- Questions or concerns about this mail, please submit a Support Request: https://sourceforge.net/tracker/?func=add&group_id=1&atid=200001 . -- Bradley T. Hughes - bhughes at trolltech.com Trolltech AS - Waldemar Thranes gt. 98 N-0175 Oslo, Norway |
From: <in...@qs...> - 2005-07-14 19:52:50
|
$BDL>o$NM-NA7O$N%5%$%H$G$b9b3[$J@A5a$r$5$l$kD>EE!&D>%a$N8r49$b$3$3$G$OL5NA!*(B $B$b$A$m$s<L%a!<%kBP1~$@$7!"CO0h$d%W%m%U%#!<%k$GAj<j$r8!:w$9$k$N$b40A4L5NA!*(B $B$7$+$bCK@-2q0w$N2r6XA0$K=w@-2q0w$r@h9TEPO?$9$k$3$H$K$h$j8=:_CK=wHf$,(B2$B!'(B8$B!*(B $B$@$+$i$[$H$s$IF~$l?)$$>uBV!*!*$I$s$I$sD>EE!&D>%a#G#E#T$7$A$c$C$F$/$@$5$$!*(B $B%5%$%H$O$3$A$i$+$i"-(B http://www.ya2dic.com?num=8416 |
From: Ciprian P. <ci...@zu...> - 2004-10-12 10:37:50
|
For those of you who contribute to the wiki, here's a heads up: I've implemented a rudimentary human check in the page edit form. It's a simple additional text field where you must now enter a code. The code is provided in very simple plain text, not in an image or such, but I've implemented it to be easily extensible to that if need arises. Alternatively, I can make the save script issue a HTTP password challenge with a very simple (for humans and fellow Blackbox fans) user+password as the answer. But let's see if the code works for now. Why so rudimentary: 1) I suspect some or all of the spammers who have affected the wiki in the last few days are actually humans. Against humans it's useless to implement fancy image codes. 2) Obscurity. The wiki engine we're using has been heavily modified by me. Chances are no wiki spambot out there expects this code check. Either way, we'll find out whether the spammer is human or robot shortly. Against humans we have the good old IP range bans and editor legwork to counter them with. Thanks to all the wiki contributors, keep up the good work. -- Ciprian Popovici |
From: Ciprian P. <ci...@zu...> - 2004-09-06 15:11:28
|
Quoting Ciprian Popovici <ci...@zu...>: > Quoting Bradley T Hughes <bh...@tr...>: > > Sounds good... this is also probably another area where alternate sty= le=3D > =3D20 > > sheets would help. Everyone is different, right? >=20 > Of course. Except that it's a bit more complicated to go down into > such details as opposed to changing the stylesheet altogether. I mean > if you want to change two things you'd have 4 variants. I'll explore > the options more sometime later. The JS changer can be done rather > easy I believe. ...and here it is. I've posted 3 styles (red, blue and green) each with accordingly colored links and certain font changes too. You can change th= em using the links under the search box. If by any chance you use Firefox it has a style changer down on the statusbar which works without JS. Hopeful= ly between the 3 colors and the different fonts we can satisfy most people. Oh, and the choice is stored in a cookie and remembered even if you close the browser. It's nice to see we've already had a few valuable contributions from rand= om people today. --=20 Ciprian Popovici |
From: Ciprian P. <ci...@zu...> - 2004-09-06 10:29:20
|
Quoting Bradley T Hughes <bh...@tr...>: > Sounds good... this is also probably another area where alternate style= =20 > sheets would help. Everyone is different, right? Of course. Except that it's a bit more complicated to go down into such details as opposed to changing the stylesheet altogether. I mean if you want to change two things you'd have 4 variants. I'll explore the options more sometime later. The JS changer can be done rather easy I believe. > > Saw your edit BTW. :) I'll shortly update the code to display IP's > > too in the history, because up until now anybody could set their name > > to BradleyHughes and the history would only show the name. Now you > > have the IP to refer to too. >=20 > Not a bad idea. Also note that I've locked some pages which there's little use of people editing, such as WikiChanges. I've tried to keep the locking down to a minimum, it's rather against the spirit of a wiki. > > We've also had out first little vandal early last night, right after > > the wiki went live. He/she messed with a couple of words on the > > homepage. I've restored the previous clean page version, naturally. >=20 > Oh? How funny... I expect spammers to make an appearance sometime when the wiki will becom= e well known. Well, it's all part of the wiki experience. We should probably announce the wiki on the user list too. Last time I ch= ecked the website list had only 4 people on it, it's probably just the develope= rs. --=20 Ciprian Popovici |
From: Bradley T H. <bh...@tr...> - 2004-09-06 08:44:27
|
On Monday 06 September 2004 10:35, Ciprian Popovici wrote: > Quoting Bradley T Hughes <bh...@tr...>: > > - the red link color is horrible. I would suggest something a > > little less 'violent' > > I'll try blue shades instead, will see how it goes. Actually, this is > a good 1st idea for alternative stylesheets (red vs blue). alternate stylesheets might be an option... i'm a bit partial to green-tones (since they are so easy on the eyes... I use the 'Green' style from CVS) > > - as mentioned before, serif fonts look best on paper, is there a > > way to change the font to something sans-serif? i have trouble > > reading the content, even when blowing up the font size. > > I'll set the precedence to Bitstream Vera Sans, Verdana, Tahoma, > Arial, sans-serif, in this order. Sounds good... this is also probably another area where alternate style sheets would help. Everyone is different, right? > Saw your edit BTW. :) I'll shortly update the code to display IP's > too in the history, because up until now anybody could set their name > to BradleyHughes and the history would only show the name. Now you > have the IP to refer to too. Not a bad idea. > We've also had out first little vandal early last night, right after > the wiki went live. He/she messed with a couple of words on the > homepage. I've restored the previous clean page version, naturally. Oh? How funny... > I'm still doing little fixes and improvements here and there, as you > can probably see from the CVS commits. Yup... I haven't looked at the code, since I don't know php (or whatever that is) -- Bradley T. Hughes - bhughes at trolltech.com Trolltech AS - Waldemar Thranes gt. 98 N-0175 Oslo, Norway |
From: Ciprian P. <ci...@zu...> - 2004-09-06 08:36:19
|
Quoting Bradley T Hughes <bh...@tr...>: > - the red link color is horrible. I would suggest something a little=20 > less 'violent' I'll try blue shades instead, will see how it goes. Actually, this is a good 1st idea for alternative stylesheets (red vs blue). > - as mentioned before, serif fonts look best on paper, is there a way t= o=20 > change the font to something sans-serif? i have trouble reading the=20 > content, even when blowing up the font size. I'll set the precedence to Bitstream Vera Sans, Verdana, Tahoma, Arial, sans-serif, in this order. Saw your edit BTW. :) I'll shortly update the code to display IP's too in= the history, because up until now anybody could set their name to BradleyHugh= es and the history would only show the name. Now you have the IP to refer to= too. We've also had out first little vandal early last night, right after the = wiki went live. He/she messed with a couple of words on the homepage. I've res= tored the previous clean page version, naturally. I'm still doing little fixes and improvements here and there, as you can probably see from the CVS commits. --=20 Ciprian Popovici |
From: Bradley T H. <bh...@tr...> - 2004-09-06 08:13:17
|
This is great... I'll have to see about adding some stuff here at some point. Also, if I may be a bit nit-picky: - the red link color is horrible. I would suggest something a little less 'violent' - as mentioned before, serif fonts look best on paper, is there a way to change the font to something sans-serif? i have trouble reading the content, even when blowing up the font size. -- Bradley T. Hughes - bhughes at trolltech.com Trolltech AS - Waldemar Thranes gt. 98 N-0175 Oslo, Norway |
From: Bradley T H. <bh...@tr...> - 2004-09-03 07:28:49
|
On Friday 03 September 2004 09:08, Ciprian Popovici wrote: [snip] > We'll go live sometime during the weekend. Brad, expect an email with > the admin user+password shortly after that. WHOO! -- Bradley T. Hughes - bhughes at trolltech.com Trolltech AS - Waldemar Thranes gt. 98 N-0175 Oslo, Norway |
From: Ciprian P. <ci...@zu...> - 2004-09-03 07:08:17
|
Sorry for the delay. I've tried to fix some (IMO) annoying feature shortcomings in the wiki engine, in order to make it more easy to use. I've given up on the side menu. It was hardcoded and one of the biggest gripes with the old site was having to commit to CVS when you were actually adding content to the site. So now our wiki will look like most wiki's out there, as pages with no tables or side menus, only toolbars at top and bottom. The other alternative was to make the side menu a regular page which would get rendered inside another page, but I really didn't know where that would take me. The home page will have to cover for the menu and offer pointers to all the major regions of the wiki. I'm almost done with the content I wanted to have for the beginning. I've also done a lot of reading on C2 and Meatball, trying to clarify some of the finer aspects of wiki's and their philosophy, and I've even written a WikiSpirit page. I've decided not to lock any page but I may change my mind regarding a few pages which hold useful tools for the wiki. We'll go live sometime during the weekend. Brad, expect an email with the admin user+password shortly after that. --=20 Ciprian Popovici |
From: Bradley T H. <bh...@tr...> - 2004-08-31 11:56:10
|
On Tuesday 31 August 2004 13:48, Ciprian Popovici wrote: > Quoting Bradley T Hughes <bh...@tr...>: > > On Tuesday 31 August 2004 11:58, Ciprian Popovici wrote: > > > Second, we should probably register the new PHP site engine in > > > the website CVS. Whether as a branch of the current website code > > > or as a new project (can we do that?) it's up to you. I've > > > modified the Tavi code we'll be using quite extensively and I'll > > > keep on doing so whenever possible or needed. > > > > We can tag the old website in CVS, and simply put the new one in > > the 'website' module. > > OK, I'll tag it something like "static" or "pre_wiki". There are > quite a few tags in there already for just 4 files, we might consider > removing some of them too. "pre_wiki" sounds good... and there's no reason to remove the other tags... just tag the current files, remove them and then add the wiki stuff > > > Third, should I assume we're going to try the non-violent > > > approach first and go with no user authentication at all? We can > > > also implement the minimal effort variant: HTTP auth only on the > > > edit pages, with a "trick" question as a hint towards the > > > user+pass ie. Q: "what's the Blackbox dock called?" A: slit/slit. > > > > I say to go for no auth to begin with and increase the required > > auth effort as needed. > > At the very least we're still going to need a user+password for the > admin page of the wiki, which offers access to 2 features: > [un]banning visitors by host mask and [un]locking pages. More on that > as soon as I have a working .htaccess in place, with the credentials > sent privately to you. > > Well, I'll expect more to the point issues will be raised once the > wiki is up and running. Which will happen in a couple of days or so. Excellent :) -- Bradley T. Hughes - bhughes at trolltech.com Trolltech AS - Waldemar Thranes gt. 98 N-0175 Oslo, Norway |
From: Ciprian P. <ci...@zu...> - 2004-08-31 11:48:57
|
Quoting Bradley T Hughes <bh...@tr...>: > On Tuesday 31 August 2004 11:58, Ciprian Popovici wrote: > > Second, we should probably register the new PHP site engine in the > > website CVS. Whether as a branch of the current website code or as > > a new project (can we do that?) it's up to you. I've modified the > > Tavi code we'll be using quite extensively and I'll keep on doing > > so whenever possible or needed. >=20 > We can tag the old website in CVS, and simply put the new one in the=20 > 'website' module. OK, I'll tag it something like "static" or "pre_wiki". There are quite a few tags in there already for just 4 files, we might consider removing some of them too. > > Third, should I assume we're going to try the non-violent approach > > first and go with no user authentication at all? We can also > > implement the minimal effort variant: HTTP auth only on the edit > > pages, with a "trick" question as a hint towards the user+pass ie. Q: > > "what's the Blackbox dock called?" A: slit/slit. >=20 > I say to go for no auth to begin with and increase the required auth=20 > effort as needed. At the very least we're still going to need a user+password for the admin page of the wiki, which offers access to 2 features: [un]banning visitors by host mask and [un]locking pages. More on that as soon as I have a working .htaccess in place, with the credentials sent privately to you. Well, I'll expect more to the point issues will be raised once the wiki is up and running. Which will happen in a couple of days or so. --=20 Ciprian Popovici |
From: Bradley T H. <bh...@tr...> - 2004-08-31 10:36:43
|
On Tuesday 31 August 2004 11:58, Ciprian Popovici wrote: > Quoting Bradley T Hughes <bh...@tr...>: > > So, I'll go take my medication now... let me know what's stopping > > us doing the wiki. If there's nothing stopping us, then let's do > > it :) > > The main issue is access to the MySQL database. I need a host, > username and password, both for loading the initial dump for > the Tavi engine, and for telling the engine the credentials so > it can use the database. I setup the MySQL db a while back... I'll resend the details in a private mail. > Second, we should probably register the new PHP site engine in the > website CVS. Whether as a branch of the current website code or as > a new project (can we do that?) it's up to you. I've modified the > Tavi code we'll be using quite extensively and I'll keep on doing > so whenever possible or needed. We can tag the old website in CVS, and simply put the new one in the 'website' module. > Third, should I assume we're going to try the non-violent approach > first and go with no user authentication at all? We can also > implement the minimal effort variant: HTTP auth only on the edit > pages, with a "trick" question as a hint towards the user+pass ie. Q: > "what's the Blackbox dock called?" A: slit/slit. I say to go for no auth to begin with and increase the required auth effort as needed. > Fourth, the content is still not up to par yet. We may have to keep > the pages locked for the first week or so while I have a chance to > add some minimal content, just to give the people a starting point. > It's harder to start a wiki with just blank pages; too much freedom > can be puzzling. Indeed. Of course, I have no problems typing stuff into the wiki. I know more about it than anyone else, most likely ;) -- Bradley T. Hughes - bhughes at trolltech.com Trolltech AS - Waldemar Thranes gt. 98 N-0175 Oslo, Norway |
From: Ciprian P. <ci...@zu...> - 2004-08-31 09:58:13
|
Quoting Bradley T Hughes <bh...@tr...>: > So, I'll go take my medication now... let me know what's stopping us=20 > doing the wiki. If there's nothing stopping us, then let's do it :) The main issue is access to the MySQL database. I need a host, username and password, both for loading the initial dump for the Tavi engine, and for telling the engine the credentials so it can use the database. Second, we should probably register the new PHP site engine in the website CVS. Whether as a branch of the current website code or as a new project (can we do that?) it's up to you. I've modified the Tavi code we'll be using quite extensively and I'll keep on doing so whenever possible or needed. Third, should I assume we're going to try the non-violent approach first and go with no user authentication at all? We can also implement the minimal effort variant: HTTP auth only on the edit pages, with a "trick" question as a hint towards the user+pass ie. Q: "what's the Blackbox dock called?" A: slit/slit. Fourth, the content is still not up to par yet. We may have to keep the pages locked for the first week or so while I have a chance to add some minimal content, just to give the people a starting point. It's harder to start a wiki with just blank pages; too much freedom can be puzzling. --=20 Ciprian Popovici |
From: Bradley T H. <bh...@tr...> - 2004-08-31 08:07:48
|
I manually updated the website in CVS and online to contain an announcement about the beta release. FWIW, this was a rather painful process. I would have certianly liked to do it in a wiki. I want a wiki. GIVE ME MY WIKI! So, I'll go take my medication now... let me know what's stopping us doing the wiki. If there's nothing stopping us, then let's do it :) -- Bradley T. Hughes - bhughes at trolltech.com Trolltech AS - Waldemar Thranes gt. 98 N-0175 Oslo, Norway |
From: Ciprian P. <ci...@zu...> - 2004-08-29 11:34:09
|
Here's a recap of what seems wrong or could use improvement with styles in 0.70: * Menu (frame, title, active) and window titlebars ignore sunken and use raised instead. * Are menu bullets still customizable? menu.bullet and menu.bullet.position don't seem to have any effect. * I seem to recall there's no window.frame anymore? If so, what controls the border for the space directly surrounding the window contents? There has to be something, because if the titlebar or the handle+grips have border, it will make them a bit wider than the contents area. Why no frame anymore, anyway? * Having marginWidth: 0 and slit and/or toolbar set to autohide will render them unreachable, because there's nothing passing the screen edge you can grab unto. * window*marginWidth seems to be restricted by something else and I can't figure out what that something is. Even if you explicitly set it to some arbitrary value it won't take effect ie. it won't grow wider but wider than what? If you do *marginHeight: 10 it does affect titlebars too, so what's that thing limiting them when you do this to them alone? * buttons don't respect the marginWidth perfectly, they're always a pixel bigger. With marginWidth=2 they come to within 1 pixel of the margin and so on. There are several more issues, some of which I've addressed in some patches a while back. I could keep on hacking into them, but the question is, is it the right moment? Is the code stable enough so that I won't risk patching a moving target? -- Ciprian Popovici |
From: Ciprian P. <ci...@zu...> - 2004-08-28 10:36:18
|
On Fri, 27 Aug 2004 12:57:26 -0700 (PDT) "Jeremy C. Reed" <re...@wc...> wrote: > On Fri, 27 Aug 2004, Bradley T Hughes wrote: > > of course, as you say, if there is a problem with so-call spammers, > > then we'd have to find a different solution. > > Password protect. Give all known blackbox community a password. Change it > monthly or when needed. > > I think a wiki for blackbox would be good too. That's also doable by using HTTP authentication for the edit feature only. But its success depends on what you understand by the "Blackbox community" and how you can get the current password out to them conveniently fast enough. I mean, is it feasible to post it to the main list? How often? It is ok for the list to be the only means to get the password? If I had to subscribe to a list and then ask for a password just because I've noticed a typo on a webpage... you get the idea. The LyX wiki has a interesting idea: it protects the edit page with HTTP auth, and the password prompt dialogue offers a hint as to what the user+pass are: "your favorite latex editor" or something like that. The answer is, of course, lyx/lyx. :) It's harmless enough and at the same time the casual spammer may have some trouble with it. -- Ciprian Popovici |
From: Jeremy C. R. <re...@wc...> - 2004-08-27 19:51:34
|
On Fri, 27 Aug 2004, Bradley T Hughes wrote: > Agreed... it would be interesting to see how other projects with wikis > manage this. for example, how do rox and freedesktop manage it? by > requiring registration? or is it just open to the general public? freedesktop.org requires registration. It uses HTTP authentication with a "WikiName". They use TWiki. It seemed fine for me when I updated some webpages there back in February. (Well that may depend on the particular wiki since they host several projects.) > of course, as you say, if there is a problem with so-call spammers, then > we'd have to find a different solution. Password protect. Give all known blackbox community a password. Change it monthly or when needed. I think a wiki for blackbox would be good too. Jeremy C. Reed http://www.reedmedia.net/ http://bsd.reedmedia.net/ -- BSD news and resources |
From: Ciprian P. <ci...@zu...> - 2004-08-27 12:18:53
|
Quoting Bradley T Hughes <bh...@tr...>: > > If things should take a turn for the worst, we can always > > lock all the pages and only allow trusted persons acces to > > the lock/unlock facility. We'd still be better off then we > > are now, since the wiki would at least serve as an excellent > > content management system. >=20 > Agreed... it would be interesting to see how other projects with wikis=20 > manage this. for example, how do rox and freedesktop manage it? by=20 > requiring registration? or is it just open to the general public? They make registration mandatory. Everyone who wants to contribute has to get an account. In FDO's case the accounts have to be manually approved by an administrator. With RoX they both allow anonymous contribs and also implement some kind of authorization levels which restrict access to some pages. While this may deter some spam&run hits, it will also deter legit contributors. Personally I was successful contributing anonymously to a certain RoX page, but not to a restricted page. I found myself giving up the latter attempt after a couple of annoying failures and error messages. > of course, as you say, if there is a problem with so-call spammers, the= n=20 > we'd have to find a different solution. There's always a problem with spammers. Once in a while someone _will_ come along and post a bunch of links to some sites just to get the referers and show a few more ads. It's the most common problem I've seen. I haven't witnessed spiteful defacements myself, although I'm sure such a thing can happen. Let me summarize my thoughts on the wiki issue. Ultimately, you can't really control a wiki unless you're going to keep all pages locked or thoroughly verify contributors by making them get accounts and such. Which defies the entire purpose of the wiki IMO. I've read what is supposed to be the philosophy of the wiki and I tend to agree with it: forgive and forget. Escalating protection will only lead to escalating violence between the admins and the evil doers, while peace loving people will stay away. No matter what protection we employ, a determined spammer will go through it, while normal people may not. Making it hard to do evil may prove to be some kind of incentive. Make it extremely easy may turn away some evil people who still have a shred of dignity left in them. Tavi (like most wikis) implements a thorough history of all past versions of all pages. Restoring a proper version after a defacement is as simple as 1-2-3: view the page history; locate the clean version; restore it. Of course, the evil person can do it too. :) Past versions do expire and dissapear, but after a custom set interval. If we set it high enough we can safely presume that there's no need for them anymore. This is the "forget" part in "forgive&forget", with the lack of authentication being the "forgive" part. Having a wiki with no authentication is akin to a 5yr old playground. One can step in and steal or break their ball, then do it again once they get a new ball. But there's absolutely no challenge and you'd have to be a real jerk to keep doing that. IMO that's the most effective defence a wiki can hope to adopt. There are lots of truly free wikis out there (the Tavi site included) that prove that this philosophy works, with nothing worse than the occasional spam occuring. These being said, I did consider the authentication and mandatory accounts and I'm prepared to implement them should we choose to. --=20 Ciprian Popovici |
From: Bradley T H. <bh...@tr...> - 2004-08-27 08:43:39
|
On Friday 13 August 2004 10:50, Ciprian Popovici wrote: [snip] Hi Ciprian, > If you got a chance to read either the user list or the > website list, you may have noticed my proposal to make a > wiki out of the Blackbox website. I've been on vacation, and have just now been getting back up to speed. [snip] > I wanted to get your opinion on this idea before we commit > to it. As things stand, a wiki offers a big advantage (a > very quickly evolving site) over a traditional site, even if > it comes with the possible downsize of virtually anybody > messing with it. I actually kind of like the idea of a wiki... we use one here at work for all of our development/support process stuff... we just go in and add/modify/remove stuff as needed. it's great :) > If things should take a turn for the worst, we can always > lock all the pages and only allow trusted persons acces to > the lock/unlock facility. We'd still be better off then we > are now, since the wiki would at least serve as an excellent > content management system. Agreed... it would be interesting to see how other projects with wikis manage this. for example, how do rox and freedesktop manage it? by requiring registration? or is it just open to the general public? of course, as you say, if there is a problem with so-call spammers, then we'd have to find a different solution. all in all though, i think it's a great idea :) -- Bradley T. Hughes - bhughes at trolltech.com Trolltech AS - Waldemar Thranes gt. 98 N-0175 Oslo, Norway |