Oxygentated vodka could be the perfect recepie for a really explosive Molotov cocktail
To be able to have two windows side by side
on
Are 80 Columns Enough?
·
· Score: 2, Informative
Most of the time I use my laptop with a 1024x768 resolution screen, and that's just enough to fit two 80 character wide emacs windows next to each other. I usually have several source files or different sections of the same file open next to each other, and I would not give that up in favor of longer lines. And that's with IMO the smallest readable font, 6x13 a.k.a `fixed'. There are laptops with bigger screens, but they are bigger and havier than my Thinkpad X60.
After I got an MS in pure math, I've started on the math Ph.D. but I quit to work as a software engineer. And while working I've started an other Ph.D. where I mostly do theoretical economic modeling with some computer science sprinkled in. Doing a pure math Ph.D. is very difficult, and only recommended if you really dedicated. On the other hand, theoretical economics uses a lot of math, if you like you can be as theoretical as you want yet people will still think that you are doing something related to the real world. And these days everyone wants to combine economics and computers, so your CS background will be useful.
Alternatively, you can just stay in CS, CS research at higher level is really math, and even in practice, many software development task requires good mathematical analysis.
By "not quite perfect," do you mean "cause a Kernel panic when it locks an HDTV signal?"
It does not do that for me, I've been using the pcHDTV card for more than a year now, the machine has a pcHDTV card and an other bt878 based analog TV card. I can record HDTV while MythTV is recording from the analog card. My machine is up 63 days now, and it's recording about an hour of HDTV per day, and maybe 2 hours of analog TV per day. So I am satisfied with the stability.
Also, it requires an HDTV-only, hacked / forked version of Xine.
The release version of MythTV also supports it, although the last I checked it did not handle subchannels well. I usually just record to disk, and use MPlayer to watch it, the standard release of mplayer can play the HDTV streams just fine, and you can convert HDTV to DivX using mencoder. So do not bother with Xine, MPlayer is better anyways.
No, the article referred in/. is very badly written. As far as I understand the article claims that Intel has implemented their CPU based on early AMD documentation, so they've missed two instructions. I.e. they have not reverse-engineered anything. Intel have the right to implement exactly the same instruction set, but they did not do that, because they did not have the documentation.
Except that these dogs outperform their contemporary RISC competition.
The Alpha development was killed years ago, yet if the several years old Alpha were remapped with today's best 90nm fab technology it would beat all current CPUs. And the IBM PowerPC chips are still alive, and are quite competitive with x86 and the Itanium. It is much harder to make the x86 fast. The instructions are variable-length, which complicates instruction prefetching and decoding. The x86 also requires I/D cache coherency so that you can write self-modifying code without using I-cache invalidate instructions. This requires extra pipeline levels, which in turn increases the branch-misprediction penalty. But the gap between the architectures are decreasing, as in the long run they all face the same bottlenecks: slow, high-latency memory bus and recently heat dissipation.
For programming, the x86 instruction set is not too bad, but the paucity of registers does hurt even if there are plenty of rename-registers, because you will have to store some values in memory and it takes extra instructions to juggle the variables between the memory and registers. And it also relies on the micro-architecture to be able to efficiently use store-forwarding. That's why one of the most significant improvement in AMD64 is the 8 new GPRs.
The free implicit flag calculations you mention is really a bad thing, since it means you cannot place instructions between the test and the branch to fill in the branch slot. And some of the nicer instructions on x86 (e.g. bts) are so slow, that you are better off writing RISC-like multi-instruction code. Actually I've found the PowerPC assembly to be easier to use than x86. PowerPC lets you do implicit flag calculations but only if you set a bit in the instruction, so it also allows you to fill the branch slots. And it have multiple set of flags and have instructions to do logical operations between those flags. It has the usual RISC features like 32 registers and 3 operand instructions, plus it have very efficient shift, rotate and bitfield insert/extract instructions. In fact, the PowerPC is such a rich instruction set you can hardly call it `reduced'.
The page you linked to (repeating here) contains only documentation regarding instructions and programming the processor, NOT the processor's architecture.
FYI, the processor architecture *is* about instructions and programming, perhaps you have confused this with the micro-architecture, which describes a specific physical implementation of an architecture.
The shortest instruction on the 6502 was 1 clockpulse,
On the Z80 it was 4 clockpulses.
As I remember, the shortest 6502 instruction actually took 2 cycles, each memory access, either for instruction fetch or read/writed required an additional cycle. But the 6502 only had 3 8-bit registers! It did not have any registers that could fully hold an address.
On the other hand, you are right, the Z80 had a 4 cycly minimum instruction length, with each memory ddess adding 3 cycles, but the Z80 usually run close to 4 MHz (e.g. 3.5 MHz on the ZX Spectrum). It had 5 pairs of GPRs, plust a shet of shadow GPRs, and it supported 16-bit reigster addressing and arithmetic. So in general, a 3.5 MHz Z80 was far superior to the 1MHz 6502. The current x86 instruction set is the derivative of the i8080 instruction set, which is a subset of the Z80 instruction set.
Never get reconditioned (or used) laptops unless they include a new battery
I would say the opposite! At least for me, the CPU speed of the laptop is secondary, and refurbished 600 MHz P-III laptops are often half the price of the new gigahertz models, while most of the other parameters are the same. Many laptops have 3 year warranty that may still be valid. Sure, the battery may have to be replaced, but you can save $1000 by buying used, and a new battery is usually below $200. So far I had 3 laptops, all were used or refurbished IBM ThinkPads. The battery died in two of them (one died because I left it in the car turned on in a hot summer day), and one of the dead batteries were replaced by IBM free of charge, even though it was not supposed to be under warranty.
The example you mention, export FOO=bar is a valid POSIX syntax.
POSIX as well as the standard Unix specification mandates that this
should work on any conformant/bin/sh implementation. True, it does
not work in the original Bourne Shell, and there are old systems where
this may not work. The other commonly used non-Bourne compatible
feature are the ${...%...} and ${...#...} substitutions, but that is
also POSIX compliant. The original Bourne shell had many problems
that made it difficult to use for scripting, and I think it is a good
thing that POSIX clarified many aspects of the shell behavior, and it
also added some new feature mostly taken from the Korn Shell. Today
any system that claims to be Unix must support these features.
You also mentioned scripts that work in the original Bourne shell but
break with bash. If it is a bug in bash, write a bugreport, and try
to find a workaround. There are bugs in commercial shells as well,
and if you want a portable application, you must work around them.
There is no easy route to portability, some systems, especially old
ones are broken beyond belief, and the only way to find such problems
is to release your program and let the users report the bugs. And if
you want a fast scripting language, you can also use ksh, I believe it
is standard on most commercial Unixes. On Linux pdksh is available as
well as AT&T ksh93. pdksh is smaller and much faster than bash. You
can also use ash, I think it is the BSD/bin/sh. Debian tries to be
ash compatible, if something in Debian does not work with sh linked to
ash, file a bugreport.
A good way to learn some portable shell programming is to look at GNU
configure scripts generated by autoconf. It can be tiresome to write
shell programs with bug-compatibility in mind, but you can get used to
it.
However, it would be conservative to assume that approximately 60% of all Apache sites run Linux, and that figure still gives Linux twice the market share of NT and Windows 2000 combined.
Note that attrition.org do have an OS pie chart, which show 59% of the
servers are NT and 24% is Linux. Compare to that the cumulative total
of around 7300 for NT and 300 for Linux you can conclude that over the
August 1999 - April 2001 period NT and Linux were equally likely to be
defaced. But you can also see that in March/April 2001 NT is pulling
ahead of Linux in the number of defacements.
Slashdot Mirror
Oxygentated vodka could be the perfect recepie for a really explosive Molotov cocktail
Most of the time I use my laptop with a 1024x768 resolution screen, and that's just enough to fit two 80 character wide emacs windows next to each other. I usually have several source files or different sections of the same file open next to each other, and I would not give that up in favor of longer lines. And that's with IMO the smallest readable font, 6x13 a.k.a `fixed'. There are laptops with bigger screens, but they are bigger and havier than my Thinkpad X60.
After I got an MS in pure math, I've started on the math Ph.D. but I quit to work as a software engineer. And while working I've started an other Ph.D. where I mostly do theoretical economic modeling with some computer science sprinkled in. Doing a pure math Ph.D. is very difficult, and only recommended if you really dedicated. On the other hand, theoretical economics uses a lot of math, if you like you can be as theoretical as you want yet people will still think that you are doing something related to the real world. And these days everyone wants to combine economics and computers, so your CS background will be useful.
Alternatively, you can just stay in CS, CS research at higher level is really math, and even in practice, many software development task requires good mathematical analysis.
No, the article referred in /. is very badly written. As far as I understand the article claims that Intel has implemented their CPU based on early AMD documentation, so they've missed two instructions. I.e. they have not reverse-engineered anything. Intel have the right to implement exactly the same instruction set, but they did not do that, because they did not have the documentation.
For programming, the x86 instruction set is not too bad, but the paucity of registers does hurt even if there are plenty of rename-registers, because you will have to store some values in memory and it takes extra instructions to juggle the variables between the memory and registers. And it also relies on the micro-architecture to be able to efficiently use store-forwarding. That's why one of the most significant improvement in AMD64 is the 8 new GPRs.
The free implicit flag calculations you mention is really a bad thing, since it means you cannot place instructions between the test and the branch to fill in the branch slot. And some of the nicer instructions on x86 (e.g. bts) are so slow, that you are better off writing RISC-like multi-instruction code. Actually I've found the PowerPC assembly to be easier to use than x86. PowerPC lets you do implicit flag calculations but only if you set a bit in the instruction, so it also allows you to fill the branch slots. And it have multiple set of flags and have instructions to do logical operations between those flags. It has the usual RISC features like 32 registers and 3 operand instructions, plus it have very efficient shift, rotate and bitfield insert/extract instructions. In fact, the PowerPC is such a rich instruction set you can hardly call it `reduced'.
I know this is now way off topic, but some studies show just the opposite: Male Circumcision Reduces Female Pleasure
On the other hand, you are right, the Z80 had a 4 cycly minimum instruction length, with each memory ddess adding 3 cycles, but the Z80 usually run close to 4 MHz (e.g. 3.5 MHz on the ZX Spectrum). It had 5 pairs of GPRs, plust a shet of shadow GPRs, and it supported 16-bit reigster addressing and arithmetic. So in general, a 3.5 MHz Z80 was far superior to the 1MHz 6502. The current x86 instruction set is the derivative of the i8080 instruction set, which is a subset of the Z80 instruction set.
The rentals stores would actually hate that. More than 20% of their revenues come from late fees.
I would say the opposite! At least for me, the CPU speed of the laptop is secondary, and refurbished 600 MHz P-III laptops are often half the price of the new gigahertz models, while most of the other parameters are the same. Many laptops have 3 year warranty that may still be valid. Sure, the battery may have to be replaced, but you can save $1000 by buying used, and a new battery is usually below $200. So far I had 3 laptops, all were used or refurbished IBM ThinkPads. The battery died in two of them (one died because I left it in the car turned on in a hot summer day), and one of the dead batteries were replaced by IBM free of charge, even though it was not supposed to be under warranty.
The example you mention, export FOO=bar is a valid POSIX syntax. /bin/sh implementation. True, it does
/bin/sh. Debian tries to be
POSIX as well as the standard Unix specification mandates that this
should work on any conformant
not work in the original Bourne Shell, and there are old systems where
this may not work. The other commonly used non-Bourne compatible
feature are the ${...%...} and ${...#...} substitutions, but that is
also POSIX compliant. The original Bourne shell had many problems
that made it difficult to use for scripting, and I think it is a good
thing that POSIX clarified many aspects of the shell behavior, and it
also added some new feature mostly taken from the Korn Shell. Today
any system that claims to be Unix must support these features.
You also mentioned scripts that work in the original Bourne shell but
break with bash. If it is a bug in bash, write a bugreport, and try
to find a workaround. There are bugs in commercial shells as well,
and if you want a portable application, you must work around them.
There is no easy route to portability, some systems, especially old
ones are broken beyond belief, and the only way to find such problems
is to release your program and let the users report the bugs. And if
you want a fast scripting language, you can also use ksh, I believe it
is standard on most commercial Unixes. On Linux pdksh is available as
well as AT&T ksh93. pdksh is smaller and much faster than bash. You
can also use ash, I think it is the BSD
ash compatible, if something in Debian does not work with sh linked to
ash, file a bugreport.
A good way to learn some portable shell programming is to look at GNU
configure scripts generated by autoconf. It can be tiresome to write
shell programs with bug-compatibility in mind, but you can get used to
it.