I like to think of it it his way. A soldier wears camoflage in the field to help protect
Stop playing silly semantic games and equivocation fallacies.
What's next? Arguing that 'security through obscurity' is obscure in Jude the Obscure's way?
Pretending that adding an obscurity layer is effective makes just as much sense as pretending that run-length encoding a gzip file will make it smaller.
This is not a case of misspelling (think Notingham) or variant spelling (think Britney vs. Brittany). There's simply no standard way of transliterating Russian names. Cyrillic "e" may be pronounced "eh", "yeh", "yo", "o" or "ih" and some people will use some kind of phonetic approximation so they don't have their names too badly garbled.
I would have expected them to include the original cyrillic name and all the/obvious/ transliterations in their database, but that's apparently way beyond their capabilities.
A "central tenant of morality" is just as needed as hair in the soup.
I find the idea that a "Central Lie" is necessary for people to act morally highly offensive, and impossible to prove in practice; but if that is really the case, then better let the whole world go to hell than having to play with and smugly pretend to believe some random bullshit.
And if we're into real Scotsmans, for a "real" Christian, the thing is about sin and salvation, not pretending to be an idiot in the hope that the others will do the same, and so be able to go along nicely instead of killing and maiming each other.
So the solution is either to turn off that specific warning (usually means it's off in all files)
why?
It's very easy to tailor compiler options for each source file in the Makefile.
There's also 'pragma GCC diagnostic push/pop', even if it doesn't work for some cases (like -Wunused-function).
For unused functions/variables/parameters it's best to conditionally define 'UNUSED__' to '__attribute__((unused))' for gcc and use that; creating dummy use cases is stupid.
Yes, there will still be problems, yes, there will ALWAYS be people
who are willing to cause physical violence to get their way, but
building interpersonal relationships is always the best way to work
towards reducing problems.
No. Many people are just rabidly, abjectly bigoted, reactionary fucks. And access to information tools only tends to exacerbate it.
If you ever lived in one of those third-world countries, you would know that the middle-class, relatively affluent (ie exactly the people a westerner can relate to) are the ones that are falling for all that conservative or revolutionary trash. In Afghanistan, that's probably the 1.5 million with access to the internet.
You need solid bourgeois values (foremost hypocrisy and intelectual dishonesty) and LOTS of free time to ingurgitate the amount of bullshit needed to be able to embrace any ideology.
Poking the wrong bits into hardware (as in your experimental driver) will lock hard your entire system -- you won't even have the chance of a kernel panic, micro-kernel or not.
Then, how about those video cards that have hard access to the whole memory, bypassing whatever restrictions the kernel may put in place?
If a driver wants to 'drive' anything, he needs access to the system's interrupts, busses, locks, whatever. At that point, all bets are off.
Come on, it would be much easier on Linux to exploit bugs in the filesystem code - I now from experience that the code is not that hardened on that side: even accidental corruption of the fs may easily crash the system.
Why bother with executable files and such?
I don't know of any Unix that regards file system metadata as an attack vector -- it's assumed that the hardware (including the physical support of any non-network fs) is under the complete control of the user;-)
What system do you use which trashes all its buffer cache from time to time, just for fun?
Usually, a filesystem is fully synced only when it is unmounted, and that cannot happen while a process still holds a reference to a file on it.
Instead of "sync" or "echo 3 >/proc/sys/vm/drop_caches" you can start some memory-hungry program, which will quickly eat up all your memory and force all buffers to disk (either in swap or in the filesystem). Problem solved;-)
If you are using a persistent/tmp, 'root' is anybody who
mounts the HDD...
And in other news, the contents of memory may persist through reboots. It's not like the BIOS or the OS fill it with zeros on each reboot. You'll have to also unplug the power cord, yank the battery, etc.
Having your terminal session stored on disk mean that everything
you see is suddenly on your filesystem, and staying on it if your/tmp is backed by the harddrive.
No. If you open(O_CREAT) a file than immediately unlink it, and use the opened handle to store temporary data, that data has no more chance to hit the disk than regular memory being swapped out.
Try to learn a bit about buffer cache and such stuff.
This "bug" is about someone ignorant about security and how an OS works having his naive assumptions contradicted by reality.
There are dozens of ways to transfer files between computers.
NTFS-formatted flash drives happen to be a stupid one, as that
filesystem is only 100% safe to write to on windows
Besides, flash drives are "optimized" for FAT and will be
much slower when used with another fs -- their firmware makes assumptions about
the position of the FAT table, and treats writes to those addresses specially.
You can even break them badly by repartitioning them with some general purpose tool, eg start the
first partition at 63*512 as usual on hds.
but am unsure how I would properly connect the 32-bit system to the
64-bit one for X apps
That's trivial -- you just have to mount/home and/tmp (either as normal partitions or with --bind)
inside the chroot, and they will find the X11 socket and the.Xauthority file just fine.
But you don't really need a chroot for that. You can install the 32bit libraries and ld-linux.so somewhere
and then starting them with a script like LD_LIBRARY_PATH=/32libs/32libs/ld-linux.so "$@".
Slashdot Mirror
If the enemy is using (effectively) some kind of thermal detection, then yes, camouflage shares all the characteristics of security through obscurity.
Including but not limited to stupidly complicating the task of corpse recovery.
Stop playing silly semantic games and equivocation fallacies.
What's next? Arguing that 'security through obscurity' is obscure in Jude the Obscure's way?
Pretending that adding an obscurity layer is effective makes just as much sense as pretending that run-length encoding a gzip file will make it smaller.
I would have expected them to include the original cyrillic name and all the /obvious/ transliterations in their database, but that's apparently way beyond their capabilities.
No, you don't.
Just because you don't know Polish, don't assume that "Pchn" and "jea" are actual words.
That is dumb.
The big advantage of quicksort is that is able to quickly sort in place.
Now try to convey that with your piss-poor piles and cards examples.
Anything but mergesort (including bubbesort) looks contrived with physical objects.
I find the idea that a "Central Lie" is necessary for people to act morally highly offensive, and impossible to prove in practice; but if that is really the case, then better let the whole world go to hell than having to play with and smugly pretend to believe some random bullshit.
And if we're into real Scotsmans, for a "real" Christian, the thing is about sin and salvation, not pretending to be an idiot in the hope that the others will do the same, and so be able to go along nicely instead of killing and maiming each other.
why?
It's very easy to tailor compiler options for each source file in the Makefile.
There's also 'pragma GCC diagnostic push/pop', even if it doesn't work for some cases (like -Wunused-function).
For unused functions/variables/parameters it's best to conditionally define 'UNUSED__' to '__attribute__((unused))' for gcc and use that; creating dummy use cases is stupid.
No. Many people are just rabidly, abjectly bigoted, reactionary fucks. And access to information tools only tends to exacerbate it.
If you ever lived in one of those third-world countries, you would know that the middle-class, relatively affluent (ie exactly the people a westerner can relate to) are the ones that are falling for all that conservative or revolutionary trash. In Afghanistan, that's probably the 1.5 million with access to the internet.
You need solid bourgeois values (foremost hypocrisy and intelectual dishonesty) and LOTS of free time to ingurgitate the amount of bullshit needed to be able to embrace any ideology.
no.
You're way off, sooner or later you'll get into trouble with that.
Better try something like: 25mm ~ 1'', 10cm ~~ 4'', 1.5m ~~ 5'.
Poking the wrong bits into hardware (as in your experimental driver) will lock hard your entire system -- you won't even have the chance of a kernel panic, micro-kernel or not.
Then, how about those video cards that have hard access to the whole memory, bypassing whatever restrictions the kernel may put in place?
If a driver wants to 'drive' anything, he needs access to the system's interrupts, busses, locks, whatever. At that point, all bets are off.
Attila and Genghis Khan were completely different historical figures -- there was like a MILLENIUM or such between them.
And anyway, trying to interpret old history through modern prejudices and stereotypes is, to put it mildly, cringeworthy.
Many crash-causing bugs are readily exploitable for code execution.
Why bother with executable files and such?
I don't know of any Unix that regards file system metadata as an attack vector -- it's assumed that the hardware (including the physical support of any non-network fs) is under the complete control of the user ;-)
Usually, a filesystem is fully synced only when it is unmounted, and that cannot happen while a process still holds a reference to a file on it.
Instead of "sync" or "echo 3 > /proc/sys/vm/drop_caches" you can start some memory-hungry program, which will quickly eat up all your memory and force all buffers to disk (either in swap or in the filesystem). Problem solved ;-)
Try it without the "sync".
What's your point? Are you assuming that putting random users in the "disk" group is safe?
And in other news, the contents of memory may persist through reboots. It's not like the BIOS or the OS fill it with zeros on each reboot. You'll have to also unplug the power cord, yank the battery, etc.
No. If you open(O_CREAT) a file than immediately unlink it, and use the opened handle to store temporary data, that data has no more chance to hit the disk than regular memory being swapped out.
Try to learn a bit about buffer cache and such stuff.
This "bug" is about someone ignorant about security and how an OS works having his naive assumptions contradicted by reality.
Besides, flash drives are "optimized" for FAT and will be much slower when used with another fs -- their firmware makes assumptions about the position of the FAT table, and treats writes to those addresses specially.
You can even break them badly by repartitioning them with some general purpose tool, eg start the first partition at 63*512 as usual on hds.
It's pretty depressing.
That's trivial -- you just have to mount /home and /tmp (either as normal partitions or with --bind)
inside the chroot, and they will find the X11 socket and the .Xauthority file just fine.
But you don't really need a chroot for that. You can install the 32bit libraries and ld-linux.so somewhere and then starting them with a script like LD_LIBRARY_PATH=/32libs /32libs/ld-linux.so "$@".
On the Russian side, there isn't even a damn road going there.
The only way to get to Chukotka, Kamchatka, Magadan Region, etc is via boat or plane.
How do you measure the 'correction rate' of a natural language?
[citation needed]
Emacs can do that too (C-x n n = narrow-to-region)