Having more stats for threads

[littleCJelkton]

Currently under the threads their are 2 stats; # Replies, and # Views. Is it possible to have more detailed stats as to like

#Views

-# Viewed by # members

# Replies

-# Replied by # members

I think this will help navigate through the forum a little quicker by allowing you to skip the threads where just 1 member is replying to his/her own thread, or help those threads which have are by subject/wording/and who created them entice certain members to view and reply to them. If there is a way to increase the information about threads I think it will help navigate the garden on top of navigation by subject style already in place.

[spot]

There are no statistics gathered on how many different logged-in members have viewed a thread, nor even on how many discrete IP addresses have viewed a thread. The increased load on the database would be significant if that were to be recorded.

The number of members replying to a thread is shown currently by clicking on "Replies" and totalling the lines returned. The advantage of clicking is that is shows the number of posts made by each member who's contributed to the thread. We could do the count inside the search module (that's the bit of code which displays the Recent Posts) but it would increase the data access workload on the server by perhaps a factor of ten. That's a major allocation of the server to just changing "Replies:142" into :Replies(15):142" which would baffle most users anyway. Adding half again to the length of the page to put the extra information onto a third line isn't really a desirable outcome either.

Clicking on "Reply:" gives you more information than just how many members have posted in the thread, it breaks down the weighting and tells you who they are. I think it's who they are which counts most in whether it's an interesting thread or not.

There are very few members who regularly post repetitively into a thread rather than alternately in the form of a discussion, if you exclude the Journals where it's a necessity. Once you eliminate Dutch and Truthbringer, who do you have left?

[littleCJelkton]

spot;1357184 wrote: There are no statistics gathered on how many different logged-in members have viewed a thread, nor even on how many discrete IP addresses have viewed a thread. The increased load on the database would be significant if that were to be recorded.

The number of members replying to a thread is shown currently by clicking on "Replies" and totalling the lines returned. The advantage of clicking is that is shows the number of posts made by each member who's contributed to the thread. We could do the count inside the search module (that's the bit of code which displays the Recent Posts) but it would increase the data access workload on the server by perhaps a factor of ten. That's a major allocation of the server to just changing "Replies:142" into :Replies(15):142" which would baffle most users anyway. Adding half again to the length of the page to put the extra information onto a third line isn't really a desirable outcome either.

Clicking on "Reply:" gives you more information than just how many members have posted in the thread, it breaks down the weighting and tells you who they are. I think it's who they are which counts most in whether it's an interesting thread or not.

There are very few members who regularly post repetitively into a thread rather than alternately in the form of a discussion, if you exclude the Journals where it's a necessity. Once you eliminate Dutch and Truthbringer, who do you have left?


Pahu, and Mickel though Mick is a little better at conversation, Bahgdad where ever he went liked to hear himself talk or in this case read his own threads though he lliked to debate and belittle a lot more than Mick or Pahu who don't even respond to anything but themselves, then there are also a good number of those who start the religious threads though since the creation of the "is the bible a lie" thread they have died down.

[spot]

Anyone with "el" at the end of their name can perhaps be predicted to be Nawubian and extremely full of idiosyncratic words, so they're excused because Malachi Z York allowed them.

[Nomad]

spot;1357184 wrote:

We could do the count inside the search module (that's the bit of code which displays the Recent Posts) but it would increase the data access workload on the server by perhaps a factor of ten. That's a major allocation of the server to just changing "Replies:142" into :Replies(15):142" which would baffle most users anyway. Adding half again to the length of the page to put the extra information onto a third line isn't really a desirable outcome either.


This is my favorite part. Do it again!

[spot]

Nomad;1357552 wrote: This is my favorite part. Do it again!


I bought a computer today, off eBay. I'm at another desk cautiously tailoring its hardware before the distribution I'm intending to install on it gets released. I've swapped a 500GB drive in which I set aside a year ago as a long-term backup, it's done what it was meant to, it's time it went back to work. I'm musing over whether to use a 64-bit operating system or not. It's not a simple decision.

So I'm wandering back here to grab a coffee and check FG and what do I get? Taunted, that's what I get. I tried hard to answer a tech Q with as non-tech a reply as would give a sensible answer, I might just as well have whistled Lilliburlero which is something I've tried hard to avoid over the years.

Pah.

[Nomad]

spot;1357555 wrote: I've swapped a 500GB drive / I'm musing over whether to use a 64-bit operating system or not


I need a cigarette.

[spot]

Nomad;1357654 wrote: I need a cigarette.


Do you know how to securely erase a drive, before you pass it out of your possession? I thought I did but it takes the best part of a day, it's called Darik's Boot And Nuke. It turns out I was only part-way right.

There's an outfit in California who practically test these things from a position of knowing what to look for. There's also an inbuilt secure erase command built into every desktop PC disk made in the last ten years. Getting at the erase command has been almost unbelievably difficult, it's as though Microsoft actively want people not to have a way of securing their old disks. I've no idea why there's not just a click-option under Accessories / System Tools.

Anyway. That page at the Center for Magnetic Recording Research, University of California, San Diego is worth bookmarking. For one thing they provide a simple DOS utility to access the secure erase triggers, for another they tell you the background to secure erasing. I'm not going to use their program but I was very pleased to read their paper.

[Bryn Mawr]

spot;1357655 wrote: Do you know how to securely erase a drive, before you pass it out of your possession? I thought I did but it takes the best part of a day, it's called Darik's Boot And Nuke. It turns out I was only part-way right.

There's an outfit in California who practically test these things from a position of knowing what to look for. There's also an inbuilt secure erase command built into every desktop PC disk made in the last ten years. Getting at the erase command has been almost unbelievably difficult, it's as though Microsoft actively want people not to have a way of securing their old disks. I've no idea why there's not just a click-option under Accessories / System Tools.

Anyway. That page at the Center for Magnetic Recording Research, University of California, San Diego is worth bookmarking. For one thing they provide a simple DOS utility to access the secure erase triggers, for another they tell you the background to secure erasing. I'm not going to use their program but I was very pleased to read their paper.


Why is that better than the commonly available software (?CCLEANER?) that will block over-write all unused areas of a drive. It sounds like the inbuilt "enhanced" command does exactly the same function but for all areas of the drive (so delete all files first?).

[spot]

Bryn Mawr;1357679 wrote: Why is that better than the commonly available software (?CCLEANER?) that will block over-write all unused areas of a drive. It sounds like the inbuilt "enhanced" command does exactly the same function but for all areas of the drive (so delete all files first?).Running a free-space wipe is a good way of wiping free-space, yes. What it will miss is those few areas which have one-time user data but got marked as bad blocks, for example. It would also be a great deal slower. As the people at the Center for Magnetic Recording Research point out, users are more likely to run something that takes three hours than one taking a day and a half, and when you're looking at 1TB drives that's what wiping involves.

The solution (again discussed on their site) is whole disk encryption performed by the disk itself, and they're arriving on the market. Secure deletion of the entire content is a ten-second replacement by the drive controller of the encryption key by a new one. The key never goes out of the drive so it's easy to wipe, it's short and the whole drive content becomes meaningless without it, you just have a drive in need of a quick-format.

[Bryn Mawr]

spot;1357691 wrote: Running a free-space wipe is a good way of wiping free-space, yes. What it will miss is those few areas which have one-time user data but got marked as bad blocks, for example. It would also be a great deal slower. As the people at the Center for Magnetic Recording Research point out, users are more likely to run something that takes three hours than one taking a day and a half, and when you're looking at 1TB drives that's what wiping involves.

The solution (again discussed on their site) is whole disk encryption performed by the disk itself, and they're arriving on the market. Secure deletion of the entire content is a ten-second replacement by the drive controller of the encryption key by a new one. The key never goes out of the drive so it's easy to wipe, it's short and the whole drive content becomes meaningless without it, you just have a drive in need of a quick-format.


Sounds like a real conflict of interests there - this is a zero benefit process until you come to scrap the drive (it's a built in key used for all accesses so adds nothing to normal data security) so it has to add pennies to the price and not compromise performance so you cannot have high level cryptography but the encryption must be unbreakable because whoever gets the disk after it's been scrapped has as long as they need to break it.

OK, if the key to the data has to be supplied externally every time the system is started with the other half of the key being held within the drive (a normal encrypted drive) and wiped on command then, I grant you, there is a user benefit but not a great deal - it just removes the danger of the attacker guessing the passphrase the user has set up.

[Bryn Mawr]

Different thought, if all the new command does is change the encryption key within a standard algorithm, how safe is it?

It is fairly certain that all of the normal encryption routines have back doors into them so what do you achieve by changing the key?

[spot]

There are different ways of running hard drive encryption. You can set it to encrypt without ever asking the user for a password. The reason for doing that is so you can secure-wipe the contents by removing the drive's key. As for any performance hit, one would have to suck it and see. The uncrackability is the same issue for any alleged cipher - is there a back door either in the implementation or in the preset values of the technique itself. One would assume yes to both, of course, but it's a double-edged sword for the spy. If too many people can use it then it would become public knowledge, consequently to small fry like you and me it doesn't have the slightest practical effect. Were I a government intelligence agency I'd worry more.

[spot]

Bryn Mawr;1357697 wrote: It is fairly certain that all of the normal encryption routines have back doors into them so what do you achieve by changing the key?Some techniques are very short, very simple and you compile them yourself from code that many people have inspected. I doubt the ability of any agency to have corrupted those with back door access. Your prime risk is a keylogger catching your typed password[1]. I agree that on a hard drive you've not compiled it and it's capable of holding a back door but to what purpose? No commercial entity is going to know how to use it. No intelligence agency would dare pass on what they find as a result. The existence of the back door would be a bigger secret than they'd be disclosing.



[1] eta: or a compiler which inserts the back door, of course. Far harder to detect.