Talkback
Talkback:108/okopnik.html
[ In reference to "Laptop review: Averatec 5400 series" in LG#108 ]
John Karns [johnkarns at gmail.com]
Tue, 29 Apr 2008 19:10:07 -0700
On Wed, Apr 23, 2008 at 11:23 AM, Rick Moen <[email protected]> wrote:
> Quoting Ben Okopnik ([email protected]): > > > I'd like to correct one common misapprehension, though: you don't have > > to learn to program in order to use Linux. in fact, the skills you need > > to use it are the same ones that you need for using Windows. > > Actually, I think it's time we counter the hoary "you have to be a > programmer to use Linux" farrago with a far more credible counter-meme: > You really must be a programmer to stand a chance of not being > horribly frustrated by MS-Windows. > > Consider how many times we've heard from MS-Windows users that the poor > security architecture, corruption-prone registry, spyware-infested > proprietary software marketplace, fragile and fragmentation-tending > filesystems, and so on have driven them to utter distraction.
So true! My sister just told me how she had recently suffered the loss of all the data on her laptop, collected over at least three years. It was all due to a family member visiting a Web site that infected the system with some kind of virus. Her comment to me was something like "I just hate computers!" My retort was the usual "The problem is not inherent to 'computers', but MS Windows's inferior design. You really ought to have Linux installed."
It's really sad when there is not even the slightest awareness that the monopoly OS is not the only choice available.
Unfortunately, she and her spouse are at a total loss as to how to approach it, other than calling the Geek Squad to re-install the inferior system, and wait for it to happen all over again sometime in the future.
-- John
[ Thread continues here (7 messages/10.88kB) ]
Talkback:143/sephton.html
[ In reference to "A Question Of Rounding" in LG#143 ]
René Pfeiffer [lynx at luchs.at]
Tue, 27 May 2008 09:56:54 +0200
Hello!
Last week I bought the third edition of the "Numerical Recipes" (http://www.nr.com/). I first used this book over ten years ago when coding mathematical functions for a calculator software on the Commodore Amiga. The third edition has more sections and more code in it. Today the section 22.2 caught my eye. The title is "Diagnosing Machine Parameters". It deals with the problems of floating-point arithmetic and mentions the fact that IEEE 754 has the advantage of being defined and known. A lot of older computing hardware had their own floating-point representation with varying parameters.
The section introduces a piece of code for measuring these machine parameters. It's called MACHAR, and published here: http://portal.acm.org/citation.cfm?id=3D51907&dl=3DACM&coll=3Dportal
"Numerical software written in high-level languages often relies on machine-dependent parameters to improve portability. MACHAR is an evolving FORTRAN subroutine for dynamically determining thirteen fundamental parameters associated with a floating-point arithmetic system. The version presented here operates correctly on a large number of different floating-point systems, including those implementing the new IEEE Floating-Point Standard."
C source can be found here for example: http://www.netlib.org/blas/machar.c
Just to let you know.
Best,
René.
Talkback:150/kapil.html
[ In reference to "Virtualizing without Virtualizing" in LG#150 ]
Jim Dennis [answrguy at gmail.com]
Fri, 2 May 2008 12:21:12 -0700
Kapil forgot at least one important term in his "EULA(1)":
* The software to be run can share the network interface state with the parent and all siblings.
In particular we have have to recognize that only one process (family) on a given machine can bind to a given port to accept incoming requests. For example, you can only have one sshd listening on port 22 on any given interface, and one listening on the "catchall" interface. If I have one sshd listening on the catchall and one listening on the address bound eth0:0 (both on TCP port 22), then any incoming request for that one address will go to the second process; any other incoming requests will go to the first one.
(It's fairly rare to configure a system with a mixture of processes listening on specific and catchall addresses, BTW; but it is possible).
The key point here is that the chroot "virtualization" is not amenable to hosting networking services, unless you can arrange some way to dispatch the incoming connections to their respective chroot jailed processes on different ports or IP aliases.
However, overall I have been recommending chroot as a "super lightweight virtualization" model for many years. It only virtualizes the file/directory structure, but that's often sufficient to development work, for example.
JimD (AnswerGuy emeritus?)
[ Thread continues here (5 messages/6.07kB) ]
Talkback:136/pfeiffer.html
[ In reference to "Measuring TCP Congestion Windows" in LG#136 ]
René Pfeiffer [lynx at luchs.at]
Sun, 11 May 2008 15:53:45 +0200
On May 06, 2008 at 2343 +0530, akshay saad appeared and said:
> On Tue, May 6, 2008 at 5:31 PM, René Pfeiffer <[email protected]> wrote: > > On May 06, 2008 at 0020 +0530, akshay saad appeared and said: > > > Hi, > > > I was following your article http://linuxgazette.net/136/pfeiffer.html > > > (Measuring TCP congestion window). > > > What I observed was that RTT is constant throughout the experiment I > > > did with your code . > > > I was wondering isn't it suppose to change ? > > > > It depends on your test environment. What was the network link between > > the two hosts? If it was a local link (such as Ethernet) the RTT won't > > change much. You need a WAN link (simulated or real) to observe RTT > > variations. Unsaturated links don't produce very little RTT variations. > > > I did tried that on intercontinental network. But I can access > network only through proxy server of my college. Does that create a > difference ?
Yes, a proxy effectively cuts the TCP connection in two. You have one connection from the client to the proxy, and one from the proxy to the server. The RTT you are observing is the one between you and the proxy server of your college. This may be the reason why there are no variations.
Best,
René.
Talkback:150/howell.html
[ In reference to "Knoppix 5.3.1" in LG#150 ]
R.+F. Weggler-Willi [weggler.willi at bluewin.ch]
Sun, 4 May 2008 07:29:32 +0200
Hi Edgar
I absolutely agree with you about "compiz". I do not see any advantages for me with firing disappearing windows! So the best new cheatcode for Knoppix 5.3.1 is
=> "no3d".
... but let taste be taste. Knoppix 5.3.1 is really the most mature live-CD available. Thanks to Klaus and the Debian people.
Bob Weggler
Talkback:150/melinte.html
[ In reference to "Lockpicking" in LG#150 ]
Frederik Deweerdt [deweerdt at free.fr]
Sat, 3 May 2008 12:15:41 +0200
Hi,
I enjoyed the article on deadlock detection. I wanted you to know that I developed a library and utility that do basically the same thing. One notable difference is that hierarchical trees of locks are built at the run time.
The code is GPL and available from here: http://www.ohloh.net/projects/6739
Regards,
Frederik
[ Thread continues here (3 messages/2.94kB) ]
Talkback:150/lg_tips.html
[ In reference to "2-Cent Tips" in LG#150 ]
clarjon1 [clarjon1 at gmail.com]
Mon, 5 May 2008 09:25:27 -0400
<snip>
> > > > And, finally, corrupted ISO downloads. A friend taught me how to fix > > > these: If your ISO is corrupted, it seems like all you have to do to fix > > > it is to create/get a torrent of it, stick the corrupted download in the > > > directory where the ISO will be downloaded to by default, and let the > > > torrent system correct it for you! > > > > I can't see this working at all. Were you told this on April 1st? ;) > > I was, now that I go through my chat logs, but the person who asked me about > whether or not I had the file handy for a torrent, and introduced me to this, > had previously posted for help for the image he was requesting, a few days > before.
Just found this on Slashdot, for all those who are still unbelievers...
http://tech.slashdot.org/tech/08/05/04/2230252.shtml
-- clarjon1
