I have installed linux several times, on different machines, now (mostly redhat). UDMA settings are almost always right on modern machines. The only exception is an old P166 machine with a very old HD, where the original kernel 2.2 does not support DMA on it, but 2.4 do (transfer rate 5MB/s -> 10MB/s). Fussing with the kernel usually doesn't give much benefit, and is definitely not for newcomers.
Things actually useful are: disabling unnecessary services on startup (if you don't use atd, don't start it to save start-up time, and in many machines it is unnecessary to detect hardware changes using kudzu upon startup); for machines with multiple HD's, put the swap on the faster HD.
When running with multiple CPU's, the kernel instances running on these CPUs need regulation when they access shared data. Such regulation is usually implemented with locks. A simple approach is to use a small number of "big" locks (like a lock that makes sure that only one CPU can run actual kernel code). This is very simple and easy to debug, but may cause poor performance because one CPU cannot (for example) do network transfers while another is reading disk, while this should be allowed in principle. So we should use finer-grained locks. However, as we make locks more and more fine-grained, we have more and more locks, so things get messy, hard to debug, and locking/unlocking overhead goes up to make performance degrade for fewer-cpu machines. Because of such a cost, we should make locks finer-grained when it actually improve performance much according to benchmarks.
Of course this applies to something else, like making transfers zero-copy, too.
cat (textutils) 2.0.21
Written by Torbjorn Granlund and Richard M. Stallman.
Copyright (C) 2002 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
So I have 23 trained cats (2 leaders and 21 performers). Cool.
If you are sure you don't have any web proxies in your way, and your browser doesn't show or store the URL in any way (history, bookmarks, cache, etc.), then it is probably as secure as a clear-text HTTP password --- it only leaks to packet sniffers.
The problem is that it is hard to make sure that your software and web proxies don't do the wrong thing, because all software know that HTTP password should be secret and not be logged or stored in cleartext, but noone knows a URL should also be secret!
Maybe linux just have a liberal enough license and enough infrastructure that the cost to write additional code required to build such a brain surgery system is relatively low, because they don't need to rewrite the memory manager and file manager and many device drivers from scratch.
This looks just like code reuse. Of course they can slap real-time stuff into the kernel, as long as the R&D costs are acceptable.
Also, I have heard of some RT patches to the kernel. Or even the stock kernel's latency may be good enough if they eliminate the worst cases?
Users don't care about 5% lower throughput, but since the web browser can run simultaneously with a background compilation, the user experience will be much smoother (everyone says that). In the single-threaded benchmarks, there is only one thread running, so no speedups can be expected.
Maybe you have more memory than you ever need. But in case memory run a little tight, if there were no swap, the OS just have to drop the read-only pages (like most executable code) while leaving many rarely-used r/w (like data) pages in RAM. So there will definitely be MORE thrashing if RAM happen to be a little scarce (when you mistakenly started something twice, etc.).
I once used KDE1 on a 32MB system, and it run quite smoothly. One day I did some configuration and forgot to turn on swap. After typing startx, the system nearly thrashed to death, and it took me three minutes to exit KDE normally.
Sure, just write in the "correct" way, the code will perform well even without any tricky optimization. However, although you know what the computer will do to execute your C code, many new programmers do not. They will just use doubles when ints should be used, use pow() when calculating 1
Knowing how to write "clean" code is the most reliable way to give your program acceptable performance. Compiler optimization is much less important for many people (for GCC, you can't get much faster than -O2 or -Os for most code), comparatively, and one definitely shouldn't rely on them (like changing a/5.0 to a*0.2) too much.
It is hard or very inefficient to emulate certain oddities of the CPU, etc., so if they happen to be unused in the guest OSes supported by vmware, they won't get much debugging and will possibly break when used. For example, linux (only tried RH6.2) and win98 runs very well in vmware, but hurd doesn't work well, an example in OSKit does not work (which works well in bochs and natively). Several "guest os" options had been tried.
In short, programs like VMware are so much more complicated than CPU emulators like Bochs that it is nearly impossible to make anything work without testing. Since VMware is closed source, it is unlikely that it will be tested much on unsupported guest OSes, because that will not generate much profit. If you want to run Windows, Linux, or BSD, or Netware on it, fine. If you want to test your toy os, Bochs-like things (or better, another computer) is much better.
In many case you just need to make a copy of the original string, so strdup() will be a good thing. And it is quite ubiquitous.
(Of course xstrdup() with out-of-memory protection should be better).
BTW, has there been any exploits that rely on the program not checking the return value of malloc()'alikes? This seems to be the thing that everyone cares, but missing the check is not usually as harmful on modern systems --- it is mostly a cleanness and user-friendliness issue now.
You really should cache the value of strlen(str) before entering the loop. Otherwise, in order to move the strlen() out of the loop, the compiler has to be sure that toupper() never returns zero for a non-zero input (otherwise strlen(str) may change during the loop). It is hard to write a compiler THAT clever...
I think C is a clean language when the programmer know how to program cleanly --- but so many C language teachers and books encourage poor programming styles, like making a 256-byte string buffer here and there.
I hope new systems will have functions like asprintf() or getline() or xstrdup() easily accessible (so you won't need to write one yourself even for a small program), and teachers will encourage use of such functions (and tell the students how to write one in case the system don't have it), and make them understand what they are doing before strcat()'ing, strlen()'ing, strncpy()'ing, or allocating a 256-byte string buffer.
Even for a somewhat advanced user like me, Redhat saves me much time. But some distribution-specific things (like things in/etc/sysconfig) are so still so hard to figure out!
Do not try to make the computer clever. Such things (such as windows emulation or hardware autodetection) are hard to make work perfectly, and when they don't it is utterly confusing and irritating for the users, even advanced ones.
In my opinion, for some more difficult things (like detecting hardware or running windows programs), the distro should not try to automate things, but rather make manual things easier --- just like it should not decide which partition to shrink to make space for linux.
A central driver repository is already there (in the kernel source --- you need very few vendor-supplied drivers). But it is better if we have some easy-to-find and up-to-date hardware support database that tells me what driver to load for a specific piece of hardware, and how stable it is, etc. I spend quite some time trying to figure out the driver for a D-link DE220 network card (newly installed, so not detected upon distribution installation), and at last found that the might NE driver just works.
I don't think having a single large file as the registry is a good idea. File systems are good enough today, and trying to create a new filesystem-like thing such as the big registry file (especially for things that important) is just going to introduce bugs and cause some users to lose data.
As for installing and uninstalling programs cleanly, the existing system (RPM or otherwise) is good enough. Application developers are free to use whatever way they like to store config data. If they think GConf is convenient, they can just use it. Users don't care much about these things, and since one application usually do not access others' configs, neither does it hurt the developers.
The real problems is still system configuration IMHO. One of my classmates want to change his MAC address on a Redhat system, but changing that using the GUI tools does not work for some reason, so I just added several lines to/etc/rc.local, and executed it. It just works, but does not look like a "clean" way in the view of the distribution.
I think GUI programs for system configuration should be carefully choosen. If they don't work perfectly, they shouldn't be installed by default. After all, most new linux users buy some books, so it is not that hard to tell them which file to change in order to change your MAC address, and what to do to make it take effect immediately.
Another problems are about command line tools. Even new users like the "less" command or the backward-searching feature of bash, however their key bindings are so different (VI-like vs. Emacs-like) it is confusing. Maybe it is a good idea to make their keybindings customizable (already done for bash) and create some config files that users can choose upon distribution installation.
Actually gcc code is not too far from the standard (it is glibc and linux kernel that contain a lot of gcc-isms). However, gcc is meant to be portable, and it is really a PITA to make all the code compile on all kinds of compilers, some of them adheres to old standards and have all kinds of quirks. Therefore the C compiler (that are carefully written so that it will compile on all those old-and-buggy compilers) is compiled first (w/o optimization to avoid bugs), then the resulting bootstrap compiler is used to do the actual compilation, so the C++ compiler (etc.) would not need so much care.
So you are incorrect IMO about the bootstrap compiler. It is a full C compiler, and should generate exactly the same code as the real compiler.
I have found such a PS file somewhere that can somewhat convert PostScript files to SVG. I have tried it on some graphics I created with MetaPost. It works except for the fonts, although the process is far from polished, so it is not for normal users.
Don't flame me. I'm still a measly LOADLIN user while everyone here are using the mighty GRUB. Nothing but GRUB can boot the new HUGE kernel. It is the first vmlinuz that is larger than 1048576 bytes (I'm now using RH 7.3 Update, which is 1040447 bytes).
Does that mean I can only choose between (1) not upgrading redhat kernels anymore (2) compile myself (3) install GRUB and confusing everyone else? Or could someone kindly fix LOADLIN?
Add a more-or-less standardized tag on various songs and video files to indicate their copyright status, then patch xmms and winamp and similar programs (including encoders) to decode these tags and tell you about the copyright status and the license (Country-dependent and constantly-changing stuff like fair-use should not be repeated, but just mentioned). And you can setup a policy file (like the java security policy) to tell the applications what to do (ignore, stop, or ask for confirmation) when you ask it to do something that are not authorized in the license (whether it is unlawful or just fair-use).
This should be a useful feature for those who don't want to violate the law but find it difficult to discover their distribution rights on a MP3 file. Maybe it is applicable to software as well, so that you don't redistribute some file illegally without knowledge, or running non-free software when you really want to live on OSS only. Just make them advisory and optional.
Slashdot Mirror
Things actually useful are: disabling unnecessary services on startup (if you don't use atd, don't start it to save start-up time, and in many machines it is unnecessary to detect hardware changes using kudzu upon startup); for machines with multiple HD's, put the swap on the faster HD.
Of course this applies to something else, like making transfers zero-copy, too.
Copyright (C) 2002 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
So I have 23 trained cats (2 leaders and 21 performers). Cool.
http://www.example.com/3458976394534/admin.html
If you are sure you don't have any web proxies in your way, and your browser doesn't show or store the URL in any way (history, bookmarks, cache, etc.), then it is probably as secure as a clear-text HTTP password --- it only leaks to packet sniffers.
The problem is that it is hard to make sure that your software and web proxies don't do the wrong thing, because all software know that HTTP password should be secret and not be logged or stored in cleartext, but noone knows a URL should also be secret!
This looks just like code reuse. Of course they can slap real-time stuff into the kernel, as long as the R&D costs are acceptable.
Also, I have heard of some RT patches to the kernel. Or even the stock kernel's latency may be good enough if they eliminate the worst cases?
Users don't care about 5% lower throughput, but since the web browser can run simultaneously with a background compilation, the user experience will be much smoother (everyone says that). In the single-threaded benchmarks, there is only one thread running, so no speedups can be expected.
Except by Middle-Aged Computer Scientists
Well, although I am a Emacs (and GNU) fan, it is really ``Generally Not Used'' by anyone I know.
I once used KDE1 on a 32MB system, and it run quite smoothly. One day I did some configuration and forgot to turn on swap. After typing startx, the system nearly thrashed to death, and it took me three minutes to exit KDE normally.
Sure, just write in the "correct" way, the code will perform well even without any tricky optimization. However, although you know what the computer will do to execute your C code, many new programmers do not. They will just use doubles when ints should be used, use pow() when calculating 1 Knowing how to write "clean" code is the most reliable way to give your program acceptable performance. Compiler optimization is much less important for many people (for GCC, you can't get much faster than -O2 or -Os for most code), comparatively, and one definitely shouldn't rely on them (like changing a/5.0 to a*0.2) too much.
In short, programs like VMware are so much more complicated than CPU emulators like Bochs that it is nearly impossible to make anything work without testing. Since VMware is closed source, it is unlikely that it will be tested much on unsupported guest OSes, because that will not generate much profit. If you want to run Windows, Linux, or BSD, or Netware on it, fine. If you want to test your toy os, Bochs-like things (or better, another computer) is much better.
(Of course xstrdup() with out-of-memory protection should be better).
BTW, has there been any exploits that rely on the program not checking the return value of malloc()'alikes? This seems to be the thing that everyone cares, but missing the check is not usually as harmful on modern systems --- it is mostly a cleanness and user-friendliness issue now.
I think C is a clean language when the programmer know how to program cleanly --- but so many C language teachers and books encourage poor programming styles, like making a 256-byte string buffer here and there.
I hope new systems will have functions like asprintf() or getline() or xstrdup() easily accessible (so you won't need to write one yourself even for a small program), and teachers will encourage use of such functions (and tell the students how to write one in case the system don't have it), and make them understand what they are doing before strcat()'ing, strlen()'ing, strncpy()'ing, or allocating a 256-byte string buffer.
Even for a somewhat advanced user like me, Redhat saves me much time. But some distribution-specific things (like things in /etc/sysconfig) are so still so hard to figure out!
In my opinion, for some more difficult things (like detecting hardware or running windows programs), the distro should not try to automate things, but rather make manual things easier --- just like it should not decide which partition to shrink to make space for linux.
A central driver repository is already there (in the kernel source --- you need very few vendor-supplied drivers). But it is better if we have some easy-to-find and up-to-date hardware support database that tells me what driver to load for a specific piece of hardware, and how stable it is, etc. I spend quite some time trying to figure out the driver for a D-link DE220 network card (newly installed, so not detected upon distribution installation), and at last found that the might NE driver just works.
As for installing and uninstalling programs cleanly, the existing system (RPM or otherwise) is good enough. Application developers are free to use whatever way they like to store config data. If they think GConf is convenient, they can just use it. Users don't care much about these things, and since one application usually do not access others' configs, neither does it hurt the developers.
The real problems is still system configuration IMHO. One of my classmates want to change his MAC address on a Redhat system, but changing that using the GUI tools does not work for some reason, so I just added several lines to /etc/rc.local, and executed it. It just works, but does not look like a "clean" way in the view of the distribution.
I think GUI programs for system configuration should be carefully choosen. If they don't work perfectly, they shouldn't be installed by default. After all, most new linux users buy some books, so it is not that hard to tell them which file to change in order to change your MAC address, and what to do to make it take effect immediately.
Another problems are about command line tools. Even new users like the "less" command or the backward-searching feature of bash, however their key bindings are so different (VI-like vs. Emacs-like) it is confusing. Maybe it is a good idea to make their keybindings customizable (already done for bash) and create some config files that users can choose upon distribution installation.
I bet the JVM does far more inlining than GCC.
There is a detailed analysis. And you can try that without having to use some payware or large free software.
So you are incorrect IMO about the bootstrap compiler. It is a full C compiler, and should generate exactly the same code as the real compiler.
I have found such a PS file somewhere that can somewhat convert PostScript files to SVG. I have tried it on some graphics I created with MetaPost. It works except for the fonts, although the process is far from polished, so it is not for normal users.
so please keep your hand off my precious computer!
Does that mean I can only choose between (1) not upgrading redhat kernels anymore (2) compile myself (3) install GRUB and confusing everyone else? Or could someone kindly fix LOADLIN?
Upgraded to kernel-2.4.18-14 (from 2.4.18-10 of RH7.3).
Loadlin crashed. Booting from a floppy directly failed too. Looks as if the kernel is too big for these things to handle it properly.
GRUB works --- but then I'll have to setup GRUB just for a kernel that is only 4 builds newer --- at the cost of confusing everyone else.
This should be a useful feature for those who don't want to violate the law but find it difficult to discover their distribution rights on a MP3 file. Maybe it is applicable to software as well, so that you don't redistribute some file illegally without knowledge, or running non-free software when you really want to live on OSS only. Just make them advisory and optional.
A week ago I got there (from china). Using links(1), of course. The text along is scary enough.
As for the percentage of young regular smokers, I find it hard to believe. No one in my middle school or high school dare smoke in public.