Add a dozen disabled copies of Ebola RNA/DNA to the common cold. Now you have something that acts like the common cold until it has a trivial mutation. You'd get random pockets of Ebola infections popping up all over the place.
I can see it now, newborn babies being purposely infected with this anti-HIV virus.
Already today, some places push parents to give a hepititis vaccine to their newborns. That is, we're giving an STD vaccine to children with poorly-developed immune systems. Vaccines do tend to wear off in time too; just when will these babies be having sex?
Years later, maybe we discover that this increases the risk of auto-immune diseases or causes cancer. Oh well, too late!
(Comparison's with Stevens book are a little
unfair as they have different emphases.
Rochkinds is on Unix, Steven's are less on
Unix and more on networking)
No way. Stevens wrote a UNIX book, not just the
networking books. The UNIX book is about file IO,
directory operations, system data files (passwd),
process control and job control, signals, terminals,
mmap, daemon writing, pipes, shared memory,
message queues, FIFOs, semaphores, passing
file descriptors, serial port IO, PTYs, etc.
I don't think this new book can compare. There's just something wrong with trying to write a UNIX book while running Windows. Stevens wrote APUE with *roff macros! FYI, that beats TeX for nerd value.
The old way was to call open() on the directory, then simply use read() to get an array of structs. Each struct had a 16-bit inode number and a 14-character filename.
Linux broke support for this, because 32-bit inode numbers and 255-character filenames would not fit. Linux would get stuck with DOS-style name mangling and some sort of inode remapping. Like this:
Linux_i~1.html
(but hey, 14 characters beats 8.3 style names)
Re:joe beats vi for oddball terminals
on
JOE Hits 3.0
·
· Score: 1
I think I've used that one too.
Anyway, I'm sure I've dealt with a telnet that wouldn't pass escape. It did allow ^[ and ^] though, typed with the control key. With great pain I suppose a truly determined vi user might be able to cope.
At the time I was using emacs, which was fairly tolerable. I only needed to monkey around for exiting: ^[ X kill-emacs
Using joe would have been much better.
Then there's the DECstation console and the genuine VT220. To get an Esc, press F11. How do you like that one, vi user?
The above is how you do it. See the 2nd edition K&R book, generally considered the main book for the ANSI C standard. The above works for C99 and C++ as well.
Leaving out the prototyle, as in "main()", is also acceptable. It's gross though, and gets you in a bad habit that will lead to loss of type-safety when using a C compiler.
Here you go again: int main(int argc, char *argv[])
(and don't think about changing the names either, because that's not how K&R did it)
joe beats vi for oddball terminals
on
JOE Hits 3.0
·
· Score: 1
How would a vi user deal with a MacOS telnet that doesn't pass the escape key through?
With joe, no problem. I don't need Esc, Alt, arrow keys, Meta, ^Q, ^S, DEL, or ^H. I've seen all of these keys missing. With joe, I get by with ^K and either arrow keys or ^F, ^B, ^P, ^N.
I use joe to work on procps. (the ps program, etc.)
Without joe, the work would go much slower. Emacs
is too slow, and it gave Richard Stallman some
disabling repettitive stress injuries in his hands.
With vi, you FEEL productive because your mind is
kept busy trying to optimize your keystrokes. That
isn't the same thing as BEING productive.
With joe, copying and moving text works right.
The selection is highlighted properly, and you
don't have to remember what's inside some
invisible cut buffer.
With joe, find/replace is unified. Choose what
you want, then you're asked for options like
case sensitivity and so on.
WordStar, TurboPascal 4, and TurboPascal 5.5 all
work mostly like joe. Even Borland C++ retained
the keystrokes in addition to the new CUA ones.
My only wish is that the default keymap stop
abusing the backtick key. Oh, they'd better not
ruin the fast start-up that joe has.
If you're going to complain about invariant sections in GNU documentation, take a look at the GPL itself and gasp in horror. You're not allowed to modify it! That's right, and no, I don't mean modifying the license used by existing code. I meant you can't take the GPL, change a few words, and then use the result as Joe's Public License.
Going to 85 Hz or higher will cause horizontal smearing due to bandwidth limits. You may be better off at 72 or even lower. You can increase your tolerance for low refresh rate by decreasing the overall brightness -- that is, including the overhead light, window, desk lamp, etc.
Any one monitor height is bad. Unfortunately, it isn't easy to drasticly change monitor position every few minutes. Maybe you could get one of those movable arms, allowing you to sit, stand, lie down, etc. This is more of a back, wrist, and elbow issue though.
This is good advice for a 100% digital display,
and good advice for an early-90s Trinitron like
the ones Sun used to ship.
It's terrible advice for a Windows-optimized CRT.
These days, black-on-white is the standard.
If you use white-on-black, the vertical lines
will be a bit darker than the horizontal ones.
The effect is especially bad with high resolution,
high refresh rates, cheap analog cables, and any
video card not made by Matrox.
Viewing angle matters a lot if you want to avoid eye strain, which was the whole point of this ask-slashdot. It especially matters on a screen that is nearly 2 feet wide. Apple gives you a whopping 170 degrees, and it shows.
Contrast may matter a bit, but 350:1 is enough. Remember that 8-bit per channel video limits the output anyway. I smell marketing.
Brightness is useless unless your room lights are too bright. Any monitor you can buy is brighter than you should need. If your room light is way too bright and you are stuck with it, then yeah, maybe brightness could matter. Fix your room lights.
Correction on the sizes:
1680x1050 $1299 20" Apple Cinema 1920x1200 $1999 23" Apple Cinema HD
90 degree is 45 to each side, which is not enough for a decently wide monitor. With that Dell, there will be subtle disturbing color and brightness variations, especially near the edges of the screen.
That is, unless you sit back very far and line your head up perfectly.
Also, is it free of dead pixels? (both kinds?) I got my Apple Cinema Display shipped by mail, and it arrived with 100% perfect pixels. There wasn't a single stuck-on or stuck-off pixel, and not even a bad sub-pixel.
If it is resolution you want, get 1920x1200 with the 23" Apple Cinema Display HD. ("HD"!)
Damn, I sound like an Apple ad... except my Mac is running Debian of course.:-)
You can use a PC with an Apple Display if you like; it requires an ADC-to-DVI adaptor that takes away the coolness of running power and USB down the monitor cable. (ADC is DVI plus 25-volt power and USB pass-through)
Slashdot Mirror
Add a dozen disabled copies of Ebola RNA/DNA to
the common cold. Now you have something that acts
like the common cold until it has a trivial
mutation. You'd get random pockets of Ebola
infections popping up all over the place.
I can see it now, newborn babies being purposely
infected with this anti-HIV virus.
Already today, some places push parents to give
a hepititis vaccine to their newborns. That is,
we're giving an STD vaccine to children with
poorly-developed immune systems. Vaccines do tend
to wear off in time too; just when will these
babies be having sex?
Years later, maybe we discover that this increases
the risk of auto-immune diseases or causes cancer.
Oh well, too late!
Many kernel developers send their changes in via
the top few developers. This causes changes to get
credited to the wrong person.
So there are many more than 916 different developers,
and the top 5 developers aren't as active as you
thought they were.
Every hard-core UNIX programmer should know how to
pass file handles between arbitrary processes.
ROTFLMAO
Did I ever say Linux was the first? Linux did
support read() on directories long ago though,
as did many other systems around 1990.
It was portable until Berkeley invented FFS.
No way. Stevens wrote a UNIX book, not just the networking books. The UNIX book is about file IO, directory operations, system data files (passwd), process control and job control, signals, terminals, mmap, daemon writing, pipes, shared memory, message queues, FIFOs, semaphores, passing file descriptors, serial port IO, PTYs, etc.
I don't think this new book can compare.
:-(
There's just something wrong with trying
to write a UNIX book while running Windows.
Stevens wrote APUE with *roff macros! FYI,
that beats TeX for nerd value.
Problem is, APUE is getting obsolete.
The old way was to call open() on the directory,
then simply use read() to get an array of structs.
Each struct had a 16-bit inode number and a
14-character filename.
Linux broke support for this, because 32-bit inode
numbers and 255-character filenames would not fit.
Linux would get stuck with DOS-style name mangling
and some sort of inode remapping. Like this:
Linux_i~1.html
(but hey, 14 characters beats 8.3 style names)
I think I've used that one too.
Anyway, I'm sure I've dealt with a telnet that
wouldn't pass escape. It did allow ^[ and ^]
though, typed with the control key. With great
pain I suppose a truly determined vi user might
be able to cope.
At the time I was using emacs, which was fairly
tolerable. I only needed to monkey around for
exiting: ^[ X kill-emacs
Using joe would have been much better.
Then there's the DECstation console and the
genuine VT220. To get an Esc, press F11.
How do you like that one, vi user?
Again, joe makes things easy.
K&R used *argv[] in "The C Programming Language",
second edition.
Heretics use **argv or **av or *av[] or....
The above is how you do it. See the 2nd edition
K&R book, generally considered the main book for
the ANSI C standard. The above works for C99 and
C++ as well.
Leaving out the prototyle, as in "main()", is
also acceptable. It's gross though, and gets you in
a bad habit that will lead to loss of type-safety
when using a C compiler.
Here you go again:
int main(int argc, char *argv[])
(and don't think about changing the names
either, because that's not how K&R did it)
joe of course. A person can not live without joe.
How would a vi user deal with a MacOS telnet
that doesn't pass the escape key through?
With joe, no problem. I don't need Esc, Alt,
arrow keys, Meta, ^Q, ^S, DEL, or ^H. I've seen
all of these keys missing. With joe, I get by
with ^K and either arrow keys or ^F, ^B, ^P, ^N.
With joe, copying and moving text works right. The selection is highlighted properly, and you don't have to remember what's inside some invisible cut buffer.
With joe, find/replace is unified. Choose what you want, then you're asked for options like case sensitivity and so on.
WordStar, TurboPascal 4, and TurboPascal 5.5 all work mostly like joe. Even Borland C++ retained the keystrokes in addition to the new CUA ones.
My only wish is that the default keymap stop abusing the backtick key. Oh, they'd better not ruin the fast start-up that joe has.
If you're going to complain about invariant
sections in GNU documentation, take a look at
the GPL itself and gasp in horror. You're not
allowed to modify it! That's right, and no, I
don't mean modifying the license used by existing
code. I meant you can't take the GPL, change a
few words, and then use the result as Joe's
Public License.
"Remove all glare" may mean to remove the dust.
Going to 85 Hz or higher will cause horizontal
smearing due to bandwidth limits. You may be
better off at 72 or even lower. You can increase
your tolerance for low refresh rate by decreasing
the overall brightness -- that is, including the
overhead light, window, desk lamp, etc.
Any one monitor height is bad. Unfortunately,
it isn't easy to drasticly change monitor position
every few minutes. Maybe you could get one of
those movable arms, allowing you to sit, stand,
lie down, etc. This is more of a back, wrist,
and elbow issue though.
It's terrible advice for a Windows-optimized CRT. These days, black-on-white is the standard. If you use white-on-black, the vertical lines will be a bit darker than the horizontal ones. The effect is especially bad with high resolution, high refresh rates, cheap analog cables, and any video card not made by Matrox.
Test your monitor now.
Viewing angle matters a lot if you want to avoid
eye strain, which was the whole point of this
ask-slashdot. It especially matters on a screen
that is nearly 2 feet wide. Apple gives you a
whopping 170 degrees, and it shows.
Contrast may matter a bit, but 350:1 is enough.
Remember that 8-bit per channel video limits
the output anyway. I smell marketing.
Brightness is useless unless your room lights
are too bright. Any monitor you can buy is
brighter than you should need. If your room
light is way too bright and you are stuck with
it, then yeah, maybe brightness could matter.
Fix your room lights.
Correction on the sizes:
1680x1050 $1299 20" Apple Cinema
1920x1200 $1999 23" Apple Cinema HD
90 degree is 45 to each side, which is not enough
:-)
for a decently wide monitor. With that Dell, there
will be subtle disturbing color and brightness
variations, especially near the edges of the screen.
That is, unless you sit back very far and line
your head up perfectly.
Also, is it free of dead pixels? (both kinds?)
I got my Apple Cinema Display shipped by mail,
and it arrived with 100% perfect pixels. There
wasn't a single stuck-on or stuck-off pixel,
and not even a bad sub-pixel.
If it is resolution you want, get 1920x1200
with the 23" Apple Cinema Display HD. ("HD"!)
Damn, I sound like an Apple ad... except my
Mac is running Debian of course.
You can use a PC with an Apple Display if you
like; it requires an ADC-to-DVI adaptor that
takes away the coolness of running power and
USB down the monitor cable. (ADC is DVI plus
25-volt power and USB pass-through)