Re:It's not quite that bad. Depending on the size
on
Are CRTs History?
·
· Score: 1
I may be a wimp but I call that insane. Maybe 14" is less dangerous than 17" and the devices you dealt with have probably not been connected to a power-line for a couple days but I'm willing to bet that even a 14" that was recently plugged in can kill you - if only on a bad day.
You should really take a look at a more recent LCD. They're improving all the time and the viewing angle problem has been kinda solved a few months (maybe a year?) ago.
You have to move your head really far into any direction before the colors on a modern LCD start fading.
I, personally, have very good expirience with BENQ LCDs (sitting in front of a FP931 right now). Try to check one out at a shop near you, you might be surprised (and they're cheap, too!).
Dude, when giving such advice ("insert a long screwdriver directly into the potentiometer through vent hole") you should really fucking stress "CAREFULLY" a bit more. "Lethal demons" sounds cute but is IMHO a very poor methaphor for 35.000 volts.
Touching a wrong part inside a CRT is not like touching a wrong part while screwing in a lightbulb. You will likely survive a lightbulb-accident. You will not survive a CRT-"accident".
Read this before messing around with high voltage equipment.
Well, while your approach sounds sensible;-), I want to make clear that I don't encourage that way of dealing with it.
I really think just posting these names will be enough. Not so that people can go and beat the kids up (I doubt anyone would bother anyways!) but more as a blunt message to the DDoS kids saying "We are paying attention and we know who you are".
Once your name shows up on such a list you'll probably re-think whether your hobby is really worth the potential backlash.
what can we do after we've detected them? we often know who they are, and even where they live
Easy. Make a public list. Put up a description of all incidents and all related information (IP-Address -> ISP -> personal info) that you have gathered.
The kids don't like to read their real name on a website.
Whether the story is bullshit or not. IF it happened like that then the company deserved what they got and it had nothing to do with what media they used (be it dvd, tape or papyrus scrolls) but rather their backup strategy was faulty.
A single media can fail at any time so if you don't have multiple full backups available at any given time then either your data is not worth backing up or your IT team has no clue.
I don't know of a single "real" database that doesn't have cursors in their high-level language and per-row callbacks in their C interface. You're dealing with an external system, get used to an event-driven interface. Otherwise, go and hack the source yourself.
Cursors and per-row callbacks, at least the implementations that I have seen, trigger *after* the query has been processed. There is no means to tell a JOIN to "stop and go no further" when a certain condition is met. There is no way to perform loops, searches or complex mutations on intermediate sets beyond what SQL has to offer.
What you're asking for exists and does not require reinventing the DB engine. And if you need a different type of engine, there are things like "tick databases" made for storing and fetching truly massive amounts of log-type data quickly (usually stock quotes). There are even SQL databases that are real time and used in industrial automation.
Yes, I know there are tick databases, bibliographical databases and quite a few others. What do they have to do with the shortcoming of most SQL databases that I described? Are you saying that instead of thinking about how to improve a tool that "almost fits" I should rather go and start with one that was made for an entirely different purpose?
Expand your horizons before judging the entire field.
Make sure you comprehend the question before talking down like that?
I'm by no means claiming to be a database guru or that I know things better than the smart people who actually design these things. If I sounded like that then I apologize, it was not intended.
I just wondered why an obviously *possible* and probably very useful bit of flexibility has not been considered yet.
Feel free to enlighten me on database theory and why manual setup of execution plans is much more difficult than it may appear to me by looking at the output of "explain analyze" but don't point me to a motorbike (which is fine for certain purposes) when I'm looking to pimp my car...
Three months later someone moving the dvd platter dropped it on the way to the vault. The DVD's that hit the floor and got scratched up was data that was not replaceable. But the time they figured out what they lost it was too late.
So, and you sold them that solution? Sounds like a great idea. Let's write data to a single disk, delete it from everywhere else and pretend we're fine.
Well, you mentioned the exact thing that I'd be interested in:
launch into some exhaustive, grandiose search logic
...because some queries could be tackled quite easily with a little script once the relevant rows have been fetched to memory. as it is, some things that cannot be expressed well in SQL would be deadsimple if you could throw a little "while"-loop in the mix. I know most RDBS have some kind of scripting language but the syntax is usually horrible (I have only tried postgres, i think they call it plsql) and its still closely tied to SQL, as in you can usually only operate on the result-set of a query, not on the intermediate steps.
In other news, virus victim associates with milk producers to print distributed-RC5-crack workunits on the back of milk cartons. "Please solve this puzzle and help this guy to get back at his data"
I bet many of these are already in most cracker dictionaries, at least the obvious patterns. But then again, its definately still harder than just a dictionary word with a number at the end...
Well, you have a point. (I'm responding because I wrote a post quite similar to the one you replied to)
But it's really just that, why is none of the dbs letting us do our own execution plan (and do mutations on the intermediate sets)?
In my environment the number of queries that need to run frequently is relatively limited. Squeezing the last bit of performance out of them would definately be reasonable. More reasonable than starting from square one (sleepycat) or below.
Why is it that we have these powerful, mature database backends in open source but the only means to trigger their magic remains so limited?
I don't claim to grasp much of the underlying hard math. But I do realize when I run into a corner case that could be resolved with a minor tweak.
100M rows, for example, is a lot of data, any way you look at it. If you've got 100 bytes per row (remarkably small in many cases), that's 10G of data. If you're shuffling through all that data every time, yeah, it's gonna be slow. Ya might want to look into reorganizing, or archiving.
10G is a lot of data? Well, when you know how to treat it it doesn't have to be. My problem with SQL databases is that they often refuse to do what I want them to do. They refuse to use an index for some obscure reason or take another, entirely wrong approach. When that happens you're down to hinting the query optimizer (which rarely worked for me) or drag the stuff through various temp tables which works faster than the initial query but still not remotely as fast as it could be if i could just tell the damn thing exactly what to do and in what order.
When a temp_table is involved most RDBMS will do the first query (read/process/write), second query (read/process/write) etc. With more control over the actual processing steps taking place after the first "read" I could often save quite a few of them. Stupid query optimizers tend to waste *a lot* of precious RAM and once they hit the boundary of physical mem it usually means: game over (as in: "let's try to do this with yet another intermediate step"...)
Just freaking program the database instead of waving chicken bones at it.
Best quote about databases I have read in a long time. Is it by you?
We have, too, hit the ceiling on our reporting SQL database (postgres) a while ago and it's slowly becoming a pain to work with it.
There are adjustments that we can make to the schema to improve the situation (drastically even) but its quickly approaching a point where the sheer amount of data makes some of the more interesting queries less and less feasible because of the performance hit.
The next step (after improving the schema) will be to throw more hardware at it (currently: dual-xeon, 3GB ram, fast scsi disks) but still, sometime not far in the future we'll have to switch some of the interesting questions to custom stuff (like grepping/scripting on huge files, cdb, custom stuff) or consequently reduce the working set (like, only process a month instead of three) because the damn queries don't scale lineary but more exponentially.
Instead of rolling most of that custom stuff on our own we'd much prefer to have a toolkit available - just as you suggested. Let *me* decide how to get to the data. Yes I *do* know better than any query optimizer how to approach *my* problem.
I think this is a huge market gap (think goatse only bigger!) since any friggin website is database driven nowadays. And anything based on a SQL DB that grows to any noteworthy size very quickly regrets to be SQL based in first place. Don't underestimate the overhead of clustering (in addition to the overhead of a SQL database in itself).
There are many situations where the flexiblity of SQL is just unnessecary and the waste of ressources unjustified. In these situations it would to not be forced to write it *all* from scratch but just to use something that has been time-tested, peer-reviewed and definately works. I know many people who would pay serious money for such a thing.
In my expirience it's more like 9 out of 10 times can you swap (or even hot-swap) a failed drive.
Out of 5 drive failures that I have expirienced only one brought the machine to a halt (assume the failed drive did something strange to the ide bus). In all other cases the raid degraded gracefully and the machine could be shutdown cleanly to swap in a new drive.
It *should* be even better with server-grade SCA (hot-swap SCSI) drives because since these are built for hot-swap they are even less likely to confuse the bus when they go down.
So, as you might have guessed, I don't agree with you. Swapping in a new disk is usually much less hassle than restoring from backup. Even if the machine halts when a disk fails - at least you still have your data.
Slashdot Mirror
I may be a wimp but I call that insane. Maybe 14" is less dangerous than 17" and the devices you dealt with have probably not been connected to a power-line for a couple days but I'm willing to bet that even a 14" that was recently plugged in can kill you - if only on a bad day.
You should really take a look at a more recent LCD. They're improving all the time and the viewing angle problem has been kinda solved a few months (maybe a year?) ago.
You have to move your head really far into any direction before the colors on a modern LCD start fading.
I, personally, have very good expirience with BENQ LCDs (sitting in front of a FP931 right now). Try to check one out at a shop near you, you might be surprised (and they're cheap, too!).
Dude, when giving such advice ("insert a long screwdriver directly into the potentiometer through vent hole") you should really fucking stress "CAREFULLY" a bit more. "Lethal demons" sounds cute but is IMHO a very poor methaphor for 35.000 volts.
Touching a wrong part inside a CRT is not like touching a wrong part while screwing in a lightbulb.
You will likely survive a lightbulb-accident.
You will not survive a CRT-"accident".
Read this before messing around with high voltage equipment.
Captcha
Well, while your approach sounds sensible ;-), I want to make clear that I don't encourage that way of dealing with it.
I really think just posting these names will be enough. Not so that people can go and beat the kids up (I doubt anyone would bother anyways!) but more as a blunt message to the DDoS kids saying "We are paying attention and we know who you are".
Once your name shows up on such a list you'll probably re-think whether your hobby is really worth the potential backlash.
There's also robert miles.
You beat me to it.
what can we do after we've detected them?
we often know who they are, and even where they live
Easy. Make a public list.
Put up a description of all incidents and all related information (IP-Address -> ISP -> personal info) that you have gathered.
The kids don't like to read their real name on a website.
Man, you guys really type out --purge all the time?
I just use dpkg -P.
Dude, how do you drop a platter of DVDs in a way so that each and every one of them is irrecoverably destroyed?
Did they drop it from the 4th floor?
Whether the story is bullshit or not. IF it happened like that then the company deserved what they got and it had nothing to do with what media they used (be it dvd, tape or papyrus scrolls) but rather their backup strategy was faulty.
A single media can fail at any time so if you don't have multiple full backups available at any given time then either your data is not worth backing up or your IT team has no clue.
I don't know of a single "real" database that doesn't have cursors in their high-level language and per-row callbacks in their C interface. You're dealing with an external system, get used to an event-driven interface. Otherwise, go and hack the source yourself.
Cursors and per-row callbacks, at least the implementations that I have seen, trigger *after* the query has been processed. There is no means to tell a JOIN to "stop and go no further" when a certain condition is met.
There is no way to perform loops, searches or complex mutations on intermediate sets beyond what SQL has to offer.
What you're asking for exists and does not require reinventing the DB engine. And if you need a different type of engine, there are things like "tick databases" made for storing and fetching truly massive amounts of log-type data quickly (usually stock quotes). There are even SQL databases that are real time and used in industrial automation.
Yes, I know there are tick databases, bibliographical databases and quite a few others. What do they have to do with the shortcoming of most SQL databases that I described? Are you saying that instead of thinking about how to improve a tool that "almost fits" I should rather go and start with one that was made for an entirely different purpose?
Expand your horizons before judging the entire field.
Make sure you comprehend the question before talking down like that?
I'm by no means claiming to be a database guru or that I know things better than the smart people who actually design these things. If I sounded like that then I apologize, it was not intended.
I just wondered why an obviously *possible* and probably very useful bit of flexibility has not been considered yet.
Feel free to enlighten me on database theory and why manual setup of execution plans is much more difficult than it may appear to me by looking at the output of "explain analyze" but don't point me to a motorbike (which is fine for certain purposes) when I'm looking to pimp my car...
Three months later someone moving the dvd platter dropped it on the way to the vault. The DVD's that hit the floor and got scratched up was data that was not replaceable. But the time they figured out what they lost it was too late.
So, and you sold them that solution?
Sounds like a great idea. Let's write data to a single disk, delete it from everywhere else and pretend we're fine.
metoo!!!11one@aol.com
Well, you mentioned the exact thing that I'd be interested in:
...because some queries could be tackled quite easily with a little script
launch into some exhaustive, grandiose search logic
once the relevant rows have been fetched to memory. as it is, some things
that cannot be expressed well in SQL would be deadsimple if you could
throw a little "while"-loop in the mix. I know most RDBS have some kind of
scripting language but the syntax is usually horrible (I have only tried
postgres, i think they call it plsql) and its still closely tied to SQL,
as in you can usually only operate on the result-set of a query, not on the
intermediate steps.
In other news, virus victim associates with milk producers to print distributed-RC5-crack workunits on the back of milk cartons. "Please solve this puzzle and help this guy to get back at his data"
I bet many of these are already in most cracker dictionaries, at least the obvious patterns. But then again, its definately still harder than just a dictionary word with a number at the end...
Well, you have a point. (I'm responding because I wrote a post quite similar to the one you replied to)
But it's really just that, why is none of the dbs letting us do our own execution plan (and do mutations on the intermediate sets)?
In my environment the number of queries that need to run frequently is relatively limited. Squeezing the last bit of performance out of them would definately be reasonable. More reasonable than starting from square one (sleepycat) or below.
Why is it that we have these powerful, mature database backends in open source but the only means to trigger their magic remains so limited?
I don't claim to grasp much of the underlying hard math. But I do realize when I run into a corner case that could be resolved with a minor tweak.
100M rows, for example, is a lot of data, any way you look at it. If you've got 100 bytes per row (remarkably small in many cases), that's 10G of data. If you're shuffling through all that data every time, yeah, it's gonna be slow. Ya might want to look into reorganizing, or archiving.
10G is a lot of data?
Well, when you know how to treat it it doesn't have to be.
My problem with SQL databases is that they often refuse to do what I want them to do. They refuse to use an index for some obscure reason or take another, entirely wrong approach.
When that happens you're down to hinting the query optimizer (which rarely worked for me) or drag the stuff through various temp tables which works faster than the initial query but still not remotely as fast as it could be if i could just tell the damn thing exactly what to do and in what order.
When a temp_table is involved most RDBMS will do the first query (read/process/write), second query (read/process/write) etc.
With more control over the actual processing steps taking place after the first "read" I could often save quite a few of them. Stupid query optimizers tend to waste *a lot* of precious RAM and once they hit the boundary of physical mem it usually means: game over (as in: "let's try to do this with yet another intermediate step"...)
I missed a "be nice" in my above post. You'll figure it out. :-)
Just freaking program the database instead of waving chicken bones at it.
Best quote about databases I have read in a long time. Is it by you?
We have, too, hit the ceiling on our reporting SQL database (postgres) a while ago and it's slowly becoming a pain to work with it.
There are adjustments that we can make to the schema to improve the situation (drastically even) but its quickly approaching a point where the sheer amount of data makes some of the more interesting queries less and less feasible because of the performance hit.
The next step (after improving the schema) will be to throw more hardware at it (currently: dual-xeon, 3GB ram, fast scsi disks) but still, sometime not far in the future we'll have to switch some of the interesting questions to custom stuff (like grepping/scripting on huge files, cdb, custom stuff) or consequently reduce the working set (like, only process a month instead of three) because the damn queries don't scale lineary but more exponentially.
Instead of rolling most of that custom stuff on our own we'd much prefer to have a toolkit available - just as you suggested.
Let *me* decide how to get to the data. Yes I *do* know better than any query optimizer how to approach *my* problem.
I think this is a huge market gap (think goatse only bigger!) since any friggin website is database driven nowadays. And anything based on a SQL DB that grows to any noteworthy size very quickly regrets to be SQL based in first place. Don't underestimate the overhead of clustering (in addition to the overhead of a SQL database in itself).
There are many situations where the flexiblity of SQL is just unnessecary and the waste of ressources unjustified. In these situations it would to not be forced to write it *all* from scratch but just to use something that has been time-tested, peer-reviewed and definately works. I know many people who would pay serious money for such a thing.
In my expirience it's more like 9 out of 10 times can you swap (or even hot-swap) a failed drive.
Out of 5 drive failures that I have expirienced only one brought the machine to a halt (assume the failed drive did something strange to the ide bus).
In all other cases the raid degraded gracefully and the machine could be shutdown cleanly to swap in a new drive.
It *should* be even better with server-grade SCA (hot-swap SCSI) drives because since these are built for hot-swap they are even less likely to confuse the bus when they go down.
So, as you might have guessed, I don't agree with you.
Swapping in a new disk is usually much less hassle than restoring from backup.
Even if the machine halts when a disk fails - at least you still have your data.
Nobody's welcoming our new cockroach overlords?
Nah, no big deal.
During my time in the special forces airborne division I routinely landed F14, F15 and 747 on aircraft carriers.
Remember, anything on a computer, any sort of file, any sort of document, ANYTHING on a computer can be programmatically generated.
Good point. So, will we ever see digital signatures being used for government and corporate communication?
Those are pretty hard to fake.
Exactly my first thought.
Am I the only one who thinks that this kind of marketing doesn't belong in schools?