in answer to my own question, it looks like they've developed a system that uses other tools. The image hiding tool used is 'outguess' rather than 'steghide', but there's probably no reason why they couldn't change that to some other program in the future. Steghide is older, but seems to support more file formats, and multiple encryption algorithms.
How is this different from steghide? Here's the summary from 'aptitude show steghide':
Steghide is steganography program which hides bits of a data file in some of
the least significant bits of another file in such a way that the existence of
the data file is not visible and cannot be proven.
Steghide is designed to be portable and configurable and features hiding data
in bmp, wav and au files, blowfish encryption, MD5 hashing of passphrases to
blowfish keys, and pseudo-random distribution of hidden bits in the container
data.
Well, actually, the way you are meant to be moderating (according to the/. underlords) can be found here. It's almost the reverse of what you suggest. Quote unrelated:
Insightful -- An Insightful statement makes you think, puts a new spin on a given story (or aspect of a story). An analogy you hadn't thought of, or a telling counterexample, are examples of Insightful comments.
Interesting -- If you believe a comment to be Interesting (and it's not mostly Redundant, Offtopic, or otherwise lame), it is.
With the crypted Echelon IP I just published, if NSA has a way to decrypt the message and want to track me, Slashdot will be offline in 5, 4, 3...2......1
127.0.0.1? Why am I able to log into that with my current username and password?
Reading these comments has changed my thoughts on data storage a little bit, but has reinforced my idea that databases are a bad idea for this sort of thing.
The main issues I have with using databases are file size (I store and convert text files that are 10-100MB zipped), and mutability (generated data doesn't typically change, I just add new experiments on top of other data). A secondary issue is that for plain-text data files (or plain-text convertible data files), writing code is easier when you don't have to bother about a database middleman.
So, if I were to do [another] large research project in the future, here's my thoughts on what I would consider an appropriate approach:
Use a file system, rather than a database
New data gets put in a consistent place, e.g/data/<date>/<source>/
Backup this data. Assuming immutable files, incremental backups don't make much sense.
Symlink categories to the original data
When a file is referenced (or attached) in an email, keep a link between email date and file, e.g./categories/<email>/<date>/<sink>/
Maintain (preferably autogenerate) and backup a plain-text file linking categories to files. This will help when data gets lost (i.e. accidentally deleted).
My most common uses for old data are re-running analyses (generating new data as results), and sending data to someone else. It helps to be able to make those things as quick as possible.
I don't have a facebook account, but I tried a few random emails (pretty much name@gmail.com), and came up with a full name and photo (although more commonly just the full name).
enter email address with 'mashed keys' as password
enter email address with 'mashed keys' as password 2 more times at 'incorrect login' screen
enter captcha
if email address represents a real user, their name (and photo, if it exists) shows up
I have always been a fan of multiple prioritized voting. You prioritize each candidate, with your vote going to your first choice. Then, whomever would have come in dead last is disqualified, and every vote that went to him is redistributed to the voter's next preference. Repeat until there is only one candidate left.
I still prefer the looks of Doom to the looks of polygon-based games. I certainly preferred Doom to Quake, and maybe that has coloured my impressions of other games. "True" 3D graphics (made up of triangles) just look far too sharp for my liking. Edges on objects don't have chamfers, and the transition between objects and background is quite harsh. I figure those problems will be eventually resolved, but it needs better anti-aliasing and (possibly) "infinite" resolution.
You can also change the udev rules (/etc/udev/rules.d/) to rewrite particular drives as whatever you want, but who knows how long udev rewriting will be around?
FWIW, my laptop is using sdXY naming for partitions, but I think it's always been like that based on the comments in my fstab.
all work will now be concentrated on polishing Debian 'Squeeze' to achieve the quality Debian stable releases are known for.
Like being released with a positive number of "release-critical" bugs, and that count going upover time. My guess based on past Debian release history is that we'll be looking at around 100 RC bugs at release time (it's around 500 at the moment).
The plural virii, though common, is often considered to be incorrect, and based on a misunderstanding of Latin. There is no plural for the Latin word virus; using the native English pluralisation rules, to yield viruses, would arguably then be most correct.
That stuff should be happening at the firmware/kernel level
Energy management of hardware (with respect to using too much energy) should happen at the hardware level. The people who make the hardware have the best chance of making sure overuse can't happen. Software cannot be trusted to always do the right thing, particularly when manufacturers don't openly publish schematics and/or limits. Perhaps a network card could be consuming all the CPU resources, so that there is nothing left to notice that the frame rate of the video card is twice redline rates.
This is no more a problem than having a CPU run a computationally intensive test that doesn't do anything.
I had two ThinkPad laptops that did bad stuff when I did CPU-intensive work (like zooming in as far as possible in an SVG using Inkscape v. 0.45) for extended periods of time. I suspected it was due to overheating, but IBM/Lenovo said that couldn't be the problem. The result was that the computer froze, and wouldn't turn on again after being forced off. The "fix" was to replace the mainboard, which gave the laptop another few months of life. I ended up getting an R50 replaced with an R51 that had the same problem. I've seen the same thing happen with a Dell laptop (although those say "the computer shut down because it overheated" on next startup, unlike the ThinkPads), and I think it may possibly also happen with my current acer laptop (although I've not experienced anything as bad as the ThinkPads).
It has caused significant problems for me, so I wouldn't recommend to others to run laptops at 100% for extended periods of time. Laptops should be designed to handle that, but in my experience, they aren't.
If you're familiar with Perl, these things are obvious. You need to learn Perl basics before you can understand Perl code.
wtf is $_ ?
The default variable, or the "default input and pattern matching space". Many functions are implicitly applied to this variable, and return this variable as a result.
wtf is the regex being applied to?
If not otherwise specified, regex are applied to the "default input and pattern matching space".
wtf is the print printing?
The print statement is printing the "default input and pattern matching space", which in this case is the result from the previous command.
Most of the confusion that you have mentioned can be overcome by understanding the "default" concept of Perl.
How about dumping the responsibility of controlling the output onto the generators by installing a fuse, or circuit breaker, which requires manual reset (reset by the generator, not the people operating the grid). That way, you limit grid input to some pre-defined value and you don't have to worry about large surges. The generator will realise that it is in their best interests to make sure that the fuse isn't tripped, so will set up their own storage, or learn to feather.
simple six-letter passwords like ameski would be broken immediately by a brute force non-dictionary attack
No, they wouldn't. A reasonable computer system would have controls to protect against brute-force attacks, either by increasing the password check time for each failed attempt, or by locking a computer out if it failed more than some small number of times.
Dictionary attacks work en-masse because it's a birthday attack -- you can spam heaps of people with heaps of words, even only 2-3 times per person, and the chance of getting a match is pretty high (as long as you don't care who the match is). Distribute the work over thousands of computers and a couple of weeks, and it can be quite difficult to automatically pick up. The search space for six-letter passwords (even ones starting with 'a') is much larger, and basically needs a determined brute-force login attempt for each user.
you're including an external file ('stdio.h'), which could be replaced by anything. A malicious person with access to that file could change the declaration for the printf statement to call an external function (or just add code into the header file), and then you're screwed.
Thinking about this makes me wonder if that's not a standard thing to do. No one checks stdio.h, right?
Re:What is the point and goal here?
on
Wine 1.2 Released
·
· Score: 1
Why do we need to run those junky programs from another OS?
Because we can, and no one else will (not even Microsoft).
Slashdot Mirror
in answer to my own question, it looks like they've developed a system that uses other tools. The image hiding tool used is 'outguess' rather than 'steghide', but there's probably no reason why they couldn't change that to some other program in the future. Steghide is older, but seems to support more file formats, and multiple encryption algorithms.
How is this different from steghide? Here's the summary from 'aptitude show steghide':
Steghide is steganography program which hides bits of a data file in some of
the least significant bits of another file in such a way that the existence of
the data file is not visible and cannot be proven.
Steghide is designed to be portable and configurable and features hiding data
in bmp, wav and au files, blowfish encryption, MD5 hashing of passphrases to
blowfish keys, and pseudo-random distribution of hidden bits in the container
data.
we put up a video of a video of an advertisement in an advertisement so you can watch while you read about watching while you read!
Your statement is a wonderfully concise explanation of the craziness of this story.
Well, actually, the way you are meant to be moderating (according to the /. underlords) can be found here. It's almost the reverse of what you suggest. Quote unrelated:
There have been numerous $20 DRM-free indy games that were pirated just as much as everything else.
There is no reward for companies that go DRM-free
DRM takes effort to implement. There is also no (or very small) reward for companies that go with DRM.
Meh, who cares about the US citizens? What the world really needs is a really long high-speed railway... from Canada to Mexico.
With the crypted Echelon IP I just published, if NSA has a way to decrypt the message and want to track me, Slashdot will be offline in 5, 4, 3...2......1
127.0.0.1? Why am I able to log into that with my current username and password?
When I click on that I2P link from my university, I get this:
Access Denied
Your request was denied because of its content categorization: "Proxy Avoidance"
If you believe this is an error, please contact the ITS Service Desk.
That actually gives me a better idea about what it does than the parent.
Reading these comments has changed my thoughts on data storage a little bit, but has reinforced my idea that databases are a bad idea for this sort of thing.
The main issues I have with using databases are file size (I store and convert text files that are 10-100MB zipped), and mutability (generated data doesn't typically change, I just add new experiments on top of other data). A secondary issue is that for plain-text data files (or plain-text convertible data files), writing code is easier when you don't have to bother about a database middleman.
So, if I were to do [another] large research project in the future, here's my thoughts on what I would consider an appropriate approach:
My most common uses for old data are re-running analyses (generating new data as results), and sending data to someone else. It helps to be able to make those things as quick as possible.
I don't have a facebook account, but I tried a few random emails (pretty much name@gmail.com), and came up with a full name and photo (although more commonly just the full name).
I have always been a fan of multiple prioritized voting. You prioritize each candidate, with your vote going to your first choice. Then, whomever would have come in dead last is disqualified, and every vote that went to him is redistributed to the voter's next preference. Repeat until there is only one candidate left.
Otherwise known as Single Transferable Vote.
I still prefer the looks of Doom to the looks of polygon-based games. I certainly preferred Doom to Quake, and maybe that has coloured my impressions of other games. "True" 3D graphics (made up of triangles) just look far too sharp for my liking. Edges on objects don't have chamfers, and the transition between objects and background is quite harsh. I figure those problems will be eventually resolved, but it needs better anti-aliasing and (possibly) "infinite" resolution.
Less then a few months ago a kernel update in squeeze changed ide addressing from hda to sda. Bricking my debian boot sequence.
The recommended route is using uuid now, for example in /etc/fstab:
UUID=3e036498-60fb-44a9-a3d1-205a3ffaeb7d swap swap defaults 0 0
or something like this in grub:
linux /vmlinuz-2.6.32-3-686 root=UUID=903040df-e1af-4c1e-86e3-c954a30ce948 ro
You can also change the udev rules (/etc/udev/rules.d/) to rewrite particular drives as whatever you want, but who knows how long udev rewriting will be around?
FWIW, my laptop is using sdXY naming for partitions, but I think it's always been like that based on the comments in my fstab.
all work will now be concentrated on polishing Debian 'Squeeze' to achieve the quality Debian stable releases are known for.
Like being released with a positive number of "release-critical" bugs, and that count going up over time. My guess based on past Debian release history is that we'll be looking at around 100 RC bugs at release time (it's around 500 at the moment).
Pi should be calculated in base 3.141593...
You're out on the 6th decimal digit (unless you're going to stop there). Pi is greater than 3.1415926 and less than 3.1415927.
Have I been trolled?
That what she said.
only visa versa
Is that when she spends exactly the same amount you saved on your credit card?
It's the plural of virus
Er, did you read the page you linked to?
The plural virii, though common, is often considered to be incorrect, and based on a misunderstanding of Latin. There is no plural for the Latin word virus; using the native English pluralisation rules, to yield viruses, would arguably then be most correct.
Why not just go the whole way and say that the sun is ejaculating a coronal mass?
It's an appropriate word for this situation; it's only been recently that ejaculation has been more commonly associated with semen.
That stuff should be happening at the firmware/kernel level
Energy management of hardware (with respect to using too much energy) should happen at the hardware level. The people who make the hardware have the best chance of making sure overuse can't happen. Software cannot be trusted to always do the right thing, particularly when manufacturers don't openly publish schematics and/or limits. Perhaps a network card could be consuming all the CPU resources, so that there is nothing left to notice that the frame rate of the video card is twice redline rates.
This is no more a problem than having a CPU run a computationally intensive test that doesn't do anything.
I had two ThinkPad laptops that did bad stuff when I did CPU-intensive work (like zooming in as far as possible in an SVG using Inkscape v. 0.45) for extended periods of time. I suspected it was due to overheating, but IBM/Lenovo said that couldn't be the problem. The result was that the computer froze, and wouldn't turn on again after being forced off. The "fix" was to replace the mainboard, which gave the laptop another few months of life. I ended up getting an R50 replaced with an R51 that had the same problem. I've seen the same thing happen with a Dell laptop (although those say "the computer shut down because it overheated" on next startup, unlike the ThinkPads), and I think it may possibly also happen with my current acer laptop (although I've not experienced anything as bad as the ThinkPads).
It has caused significant problems for me, so I wouldn't recommend to others to run laptops at 100% for extended periods of time. Laptops should be designed to handle that, but in my experience, they aren't.
Now, about the script itself:
If you're familiar with Perl, these things are obvious. You need to learn Perl basics before you can understand Perl code.
wtf is $_ ?
The default variable, or the "default input and pattern matching space". Many functions are implicitly applied to this variable, and return this variable as a result.
wtf is the regex being applied to?
If not otherwise specified, regex are applied to the "default input and pattern matching space".
wtf is the print printing?
The print statement is printing the "default input and pattern matching space", which in this case is the result from the previous command.
Most of the confusion that you have mentioned can be overcome by understanding the "default" concept of Perl.
How about dumping the responsibility of controlling the output onto the generators by installing a fuse, or circuit breaker, which requires manual reset (reset by the generator, not the people operating the grid). That way, you limit grid input to some pre-defined value and you don't have to worry about large surges. The generator will realise that it is in their best interests to make sure that the fuse isn't tripped, so will set up their own storage, or learn to feather.
simple six-letter passwords like ameski would be broken immediately by a brute force non-dictionary attack
No, they wouldn't. A reasonable computer system would have controls to protect against brute-force attacks, either by increasing the password check time for each failed attempt, or by locking a computer out if it failed more than some small number of times.
Dictionary attacks work en-masse because it's a birthday attack -- you can spam heaps of people with heaps of words, even only 2-3 times per person, and the chance of getting a match is pretty high (as long as you don't care who the match is). Distribute the work over thousands of computers and a couple of weeks, and it can be quite difficult to automatically pick up. The search space for six-letter passwords (even ones starting with 'a') is much larger, and basically needs a determined brute-force login attempt for each user.
you're including an external file ('stdio.h'), which could be replaced by anything. A malicious person with access to that file could change the declaration for the printf statement to call an external function (or just add code into the header file), and then you're screwed.
Thinking about this makes me wonder if that's not a standard thing to do. No one checks stdio.h, right?
Why do we need to run those junky programs from another OS?
Because we can, and no one else will (not even Microsoft).