p.s.: this project has some spam accounts too btw., scroll through top_users.php and you will see them. As there is most likely no scheduler running, that's sure HTML bot work.

Not that BOINC is a project, but OK. :)
I forwarded that to the people with database access above us. Hopefully they'll delete them. As soon as any of them tries to post here on the forums, we'll ban them till 2038.

---

As soon as any of them tries to post here on the forums, we'll ban them till 2038.

Is 2038 the maximum time you can ban them? I should report that as a bug. 2038 is the Unix equivalent of the Y2K bug.

As soon as any of them tries to post here on the forums, we'll ban them till 2038.

Is 2038 the maximum time you can ban them? I should report that as a bug. 2038 is the Unix equivalent of the Y2K bug.

As I understand it that's the end of Unix time. 9999999999 or so something seconds, right?

But yes, 18 January 2038 is the maximum.

---

January 19, 2038 03:14:07 GMT is equivalent to January 01, 1970 00:00:00h plus the highest number of seconds that a signed(!) 32bit timestamp can hold.

That's why the limit is not any number of 9s.

Afaik. it is 2147483647 or x7FFFFFFF or b01111111111111111111111111111111, the highest positive value you can stuff into 31 bit (the missing bit is the sign bit)


hmmm ... the decimal value looks messy and chaotic but the PC doesn't need its fingers for counting so it can handle that stuff quite well ;-)

As soon as any of them tries to post here on the forums, we'll ban them till 2038.

Is 2038 the maximum time you can ban them? I should report that as a bug. 2038 is the Unix equivalent of the Y2K bug.

As I understand it that's the end of Unix time.

In the 32-bit world. If the timestamp was a 64-bit integer (still meaning "seconds since Jan 1st 1970") the limit would be beyond the estimated collapse of the universe.

... If the timestamp was a 64-bit integer (still meaning "seconds since Jan 1st 1970") the limit would be beyond the estimated collapse of the universe.

Roughly calculating a year as 365.25 days, that would be in the year 1970 + 292271023045 - I guess no bugs for Unix will be reported anymore by then *g

Thanks for that. Skipping all the 9s.

---

p.s.: this project has some spam accounts too btw., scroll through top_users.php and you will see them.

David has removed most of them. I just sent in 9 more that I found in the first 2160 accounts (top 2903, bottom 2149). If you find more, please PM me and I'll send them on.

---

As soon as any of them tries to post here on the forums, we'll ban them till 2038.

Is 2038 the maximum time you can ban them? I should report that as a bug. 2038 is the Unix equivalent of the Y2K bug.

As I understand it that's the end of Unix time.

In the 32-bit world. If the timestamp was a 64-bit integer (still meaning "seconds since Jan 1st 1970") the limit would be beyond the estimated collapse of the universe.

Here's an interesting little script.

Run on one of my 32bit boxes

trogdog@Athlon ~ $ ./2038.pl 
Tue Jan 19 03:14:01 2038
Tue Jan 19 03:14:02 2038
Tue Jan 19 03:14:03 2038
Tue Jan 19 03:14:04 2038
Tue Jan 19 03:14:05 2038
Tue Jan 19 03:14:06 2038
Tue Jan 19 03:14:07 2038
Fri Dec 13 20:45:52 1901
Fri Dec 13 20:45:52 1901
Fri Dec 13 20:45:52 1901

Not that this box will still be running then though :)

---

CIC1=CC=C(C2=N[C@@H](CC(OC(C)(C)C)=O)C3=NN=C(C)N3C4=C2C(C)=C(C)S4)C=C1

1. is to teach Akismet what is SPAM and what isn't. At this moment it doesn't know, so posting URLs, even pointing to a thread elsewhere on the same forum, is considered spam.

Akismet is actively kicking in on Ralph since they upgraded the forum SW. Regarding the (disallowed) URLs, I've found out that if the leading http://boinc.berkeley.edu/ is replaced by :/, then at least local URLs are working without Akismet noticing it.

And we can get something like (you will see it when replying to my post).

BTW, does this notation mean anything special in HTTP or BBcode, like a local URL relative to the web page's root?

Peter

PS: I'm noticing one small problem. It works with IE7, but not with SeaMonkey :-(

...
PS: I'm noticing one small problem. It works with IE7, but not with SeaMonkey :-(

Maybe IE7 (IE6 does not!) tries to interpret it as a relative URL, like

<img src="/dev/img/head_20.png">

would lead to that image on the current server or

<img src="head_20.png">

would lead to that image in the current web directory

(as long as no "base href" is specified)

IE often accepts things that allow illegal HTML code instead of giving up on the page. That's why so many web pages are so crappy and work only on certain browsers.

Maybe IE7 (IE6 does not!) tries to interpret it as a relative URL, like

<img src="/dev/img/head_20.png">

would lead to that image on the current server or

<img src="head_20.png">

would lead to that image in the current web directory

(as long as no "base href" is specified)

IE often accepts things that allow illegal HTML code instead of giving up on the page. That's why so many web pages are so crappy and work only on certain browsers.

Both of your examples are valid HTML (well, would be if they had the alt="" attribute which is required by specs).

What Pepo did with [img]:/dev/stuff[/img] is getting converted by the forum software into http://:/dev/stuff which is an invalid URL.

---

Here's an interesting article in a symantec blog:
Pharming Pharmaceuticals
Posted by Vikram Thakur on November 27, 2007 03:37 PM

About spammers using university fora for getting higher ranking in google e.a.

---

Gruesse vom Saenger

For questions about Boinc look in the BOINC-Wiki

How do you think they got their links into the source code of the page being displayed without the links being visible to ordinary visitors to the forum or blog?

Probably inserted as metacode, which is seen by 'bots, but not the average human, who doesn't bother looking at the source code of a page.

And another problem is showing up, negating the effect of "captchas": PC stripper helps spam to spread

Maybe IE7 (IE6 does not!) tries to interpret it as a relative URL, like

<img src="/dev/img/head_20.png">

would lead to that image on the current server or

<img src="head_20.png">

would lead to that image in the current web directory

(as long as no "base href" is specified)

IE often accepts things that allow illegal HTML code instead of giving up on the page. That's why so many web pages are so crappy and work only on certain browsers.

Both of your examples are valid HTML (well, would be if they had the alt="" attribute which is required by specs).

What Pepo did with [img]:/dev/stuff[/img] is getting converted by the forum software into http://:/dev/stuff which is an invalid URL.

That's exactly my point. Crappy IE7 treats an invalid URL as if it was one of those relative URLs.