Comment Re:Please People, You're Spreading Misinformation (Score 1) 239
Guess who is the number one political gift donor in America is.
And look at where the to individual contributors are from.
Guess who is the number one political gift donor in America is.
And look at where the to individual contributors are from.
syslogd on every modern unix is capable of routing to a specific log file for a specific app. If the basic syslogd isn't enough, your loghost can run syslog-ng or any of the other more powerful syslog daemons. You only have to replace the one on the server, the other clients should just be forwarding EVERYTHING to it.
Of course at this sort of level, you'd probably save yourself a metric assload of trouble if you implemented a proper network monitoring/management server.
Myself, having only 15 or so hosts to deal with, most of which aren't chattery just use ssh + a colorizer script I wrote for my purposes. I typically leave it running on a spare monitor all the time.
Spots -do- change line positions. The reason is that the star rotates, so half of the visible surface moves towards us, half of it recedes. Now imagine that part of either the receding or approaching surface is covered by a spot...
However, this also changes the shape of a spectral line, not just the position of the centre. This is why people do a 'bisector analysis' (basically, split line in half, compare right/left side to discover distortions).
Also, spot activity can be measured independently. With sufficiently big spots, the stellar rotation period can be determined photometrically (i.e. by measuring the periodic darkening in the stellar luminosity). Or one can infer the period from the doppler broadening of the lines caused by stellar rotation. Spot activity also shows up by certain emission lines in the spectrum (also for the Sun - these lines vary in intensity during the solar cycle).
Stellar pulsations are another problem, since unlike spots they don't change the line shape, so one can't rule them out with a bisector analysis. However, stellar pulsations would cause the star to periodically change its surface temperature and/or luminosity, which again can be measured independently.
The biggest problem is plausible deniability - if they search your computer and find the software, how do you explain its presence?
There is really only one way to solve this problem: the software must credibly pass as malware. It must have at least some of the traits of malware, and it must be actively used as malware, otherwise it's not credible, and in sufficiently oppressive countries you will likely end in prison for just having it on your machine.
The existence of life can in principle be inferred from the composition of a planets' atmosphere, which could be determined spectroscopically. E.g. earths' atmosphere is oxygen-rich, which would not be possible without life (oxygen is agressive, and would disappear quickly by forming compounds with surface minerals, if it wasn't replenished by photosynthesis).
There is research on ways to do this, and on the kind of instruments that would be required. However, this research focuses on life as we know it, which requires water. 'Hot Jupiters' like this planet are much too hot, and most scientists would not seriously consider them candidates for any kind of life.
By contrast virtually all of a standard Linux desktop will compile to ARM. You might be missing some important pieces like Flash player, Sun Java and some other stuff, but the core experience would all be there. You'd get Firefox, OpenOffice, media players and everything else, subject to the system's other limitations such as memory & disk footprint.
Yes, and here's the catch. It has been my experience that if you want a Linux desktop that can compete with the offerings from Microsoft, in compatibility, functionality, and eye candy, you are looking into something pretty heavyweight: Gnome or KDE, OpenOffice, Firefox, all of them heavyweight stuff, not to mention the ever-increasing number of deamons that are running in the background (hald, NetworkManager, Dbus,
There is no language called POSIX. It's an OS standard, and software authors writing in high-level languages should not need to care about it. There are languages like C, C++, Java, etc. If you're writing Java, you should pay attention to the Java standard. If you're writing C, you should pay attention to the C standard (which doesn't include OS specific things like fsync()).
And if you adhere to the standard of the language you are using, you should have some reasonable expectation that things will work, instead of dying a horrible and gruesome death. A conforming HTML page should not fail. A conforming Java/C/C++/whatever program should not fail either, but the problem is, it will. This is like asking HTML authors to understand the low-level details of the browser rendering engine in order to write working HTML pages.
Some high-level languages (e.g. PHP) have no built-in fsync. Also fsync() is not part of the C standard, it's a POSIX extension. What you have in C is fflush(), but that will not fsync(). So books about programming in C usually don't cover fsync(), as it's not part of the language. I know that sounds like nitpicking, but truth is, if you've learned programming from books about some language, chances are you've never heard about fsync().
Basically, what happens is that you need to understand OS design in order to program in a high-level language, and nobody (at least none of the books) tells you so. This is a WTF on more than one level... either make it part of the language, or make sure it isn't needed.
After any salary raise, you will have less money at the end of the month than you did before.
