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.

They won't -- because you are obscure -- get it?

no.

15mm about half an inch

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.

Most of this is from "Genghis Khan and the Making of the Modern World" (a great read): http://www.amazon.com/Genghis-Khan-Making-Modern-World/dp /0609809644 Other pieces

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.

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?

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.

It's pretty depressing.

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 "$@".