Because a) some people don't have broadband so they want a CD of the software they are actually going to run b) only stable releases have timely security updates c) installing security updates on unstable can require downloading 100s of MB due to pulling in other updated packages. d) stable won't even install on some newer hardware without guru knowledge e) unstable is sometimes buggy and can make a system unbootable, or make the user unable to log in. f) some people want to run reasonably recent software but without it changing every day. g) Unstable can be horribly broken during things like a gcc 3 transition
RedHat 8's GUI config tools are abysmal. They are badly organised and have (in places) pretty poor UI design. Having said that, Windows control panel is only slightly better.
SAUCE applies aggressive correctness checks to incoming mail. Works with exim, but apparently could be adapted:
http://www.chiark.greenend.org.uk/~ian/sauce/
You can't run an interactive game on separate machines because the communication latency will be too high.
I'm reminded of an old userfriendly cartoon here
>It compares the performance of a Linux SMP kernel that
>was aware of Hyper-Threading to one that was not."
But if you aren't going to use hyper threading you would use a UP (non-SMP) kernel, which would gain you considerable performance. The benefits are not so clear cut as many of the benchmarks show limited benefit from hyperthreading and would perform faster on a uniprocessor kernel.
I did see a demo of a Java debug system which generated a log during execution and allowed the user to look at what was the full state of the program at any point during its execution. Very cool.
As somebody who uses printf, I would like the facility to add printf's retrospectively without having to recompile and re-run the code. printf debugging is great because it can be extremely context sensitive to the state of the program.
Another advantage of printf debugging is that you can compare the behaviour of two similar versions where one displays a bug, and see where the buggy one's behaviour is differing from the working version. Perl is a great tool for accounting for differences which are expected
Other than that, I find debugging on x86 is a pain because the assembler is much harder to read than a RISC instruction set like ARM. I don't know what I'll do if I ever have to debug something on IA64:)
I did see a demo of a Java debug system which generated a log during execution and allowed the user to look at what was the full state of the program at any point during its execution. Very cool.
If you're going to pay for software try to get somebody who uses it (for real, not a demo in a shop) to show you how it works and get an honest opinion on it.
Professional applications often seem to have a quirky or unusual user interface and it can be hard to assess how easy it will be to use once you have got to grips with it.
I had a dual monitor set up with NT4 at work, and I found that it was not really usable, and have given up on the second monitor. Windows apps put windows on random monitors and it was really tiring moving my head backwards and forwards. Windows 2000 didn't improve matters either.
At home, I find having multiple workspaces in windowmaker is at least as good.
Re:Recycle Bins - don't you just hate them?
on
Undelete In Linux
·
· Score: 1
My solution is to do "echo *a*b*c*.*", and if the list of files is OK, then edit the command to use rm instead. I find myself more likely to click on the wrong pixel and accidentally delete the wrong file than to type an incorrect rm command
I used it the other day and I couldn't make it do anything useful. It wouldn't import raw audio files (they were too short and it wouldn't let me tell it what format they were), I couldn't figure out how to downmix from stereo to mono, or how to reduce the sample rate.
Admittedly, CoolEdit has some of these problems too
I ran KDE 2.2.2 on a 486/66 with 24MB of RAM for a while, and it was OK for basic web browsing. It took a while to start up, but once up and running it was quite usable (in fact, more so than the crappy celery 400 system which it replaced - On-board video sucks)
Slashdot Mirror
minor correction. we have to find a place where the experiment took place billions of years ago, and the evidence is just arriving now...
mplayer doesn't have a crap splash screen, so mplayer is better :)
use SAUCE:http://www.chiark.greenend.org.uk/~ian/sauc
Because
a) some people don't have broadband so they want a CD of the software they are actually going to run
b) only stable releases have timely security updates
c) installing security updates on unstable can require downloading 100s of MB due to pulling in other updated packages.
d) stable won't even install on some newer hardware without guru knowledge
e) unstable is sometimes buggy and can make a system unbootable, or make the user unable to log in.
f) some people want to run reasonably recent software but without it changing every day.
g) Unstable can be horribly broken during things like a gcc 3 transition
RedHat 8's GUI config tools are abysmal. They are badly organised and have (in places) pretty poor UI design. Having said that, Windows control panel is only slightly better.
you don't need the first make menuconfig, and you should do a make oldconfig before the second. The second make menuconfig then becomes optional.
KDE has already benefitted from this release!
SAUCE applies aggressive correctness checks to incoming mail. Works with exim, but apparently could be adapted: http://www.chiark.greenend.org.uk/~ian/sauce/
You can't run an interactive game on separate machines because the communication latency will be too high. I'm reminded of an old userfriendly cartoon here
Eat a peanut butter sandwich, because after you've changed a nappy, you'll never look at one in the same light again
info --subnodes --output - | less
makes it work just like man :)
Debian actually provides proper manpages for a lot of these programs.
>was aware of Hyper-Threading to one that was not."
But if you aren't going to use hyper threading you would use a UP (non-SMP) kernel, which would gain you considerable performance. The benefits are not so clear cut as many of the benchmarks show limited benefit from hyperthreading and would perform faster on a uniprocessor kernel.
As somebody who uses printf, I would like the facility to add printf's retrospectively without having to recompile and re-run the code. printf debugging is great because it can be extremely context sensitive to the state of the program.
Another advantage of printf debugging is that you can compare the behaviour of two similar versions where one displays a bug, and see where the buggy one's behaviour is differing from the working version. Perl is a great tool for accounting for differences which are expected
Other than that, I find debugging on x86 is a pain because the assembler is much harder to read than a RISC instruction set like ARM. I don't know what I'll do if I ever have to debug something on IA64 :)
I did see a demo of a Java debug system which generated a log during execution and allowed the user to look at what was the full state of the program at any point during its execution. Very cool.
Surely dselect is the part of the installer which most needs replacing?
Professional applications often seem to have a quirky or unusual user interface and it can be hard to assess how easy it will be to use once you have got to grips with it.
I wonder if they might be overselling it?
While hotspot server generates significantly better code, it spends much longer doing it and therefore the execution time is frequently worse.
If you don't believe me, try compiling some Java programs using javac with each VM. :)
Do SiS still support the DRI project?
At home, I find having multiple workspaces in windowmaker is at least as good.
My solution is to do "echo *a*b*c*.*", and if the list of files is OK, then edit the command to use rm instead. I find myself more likely to click on the wrong pixel and accidentally delete the wrong file than to type an incorrect rm command
Audacity is terrible.
I used it the other day and I couldn't make it do anything useful. It wouldn't import raw audio files (they were too short and it wouldn't let me tell it what format they were), I couldn't figure out how to downmix from stereo to mono, or how to reduce the sample rate.
Admittedly, CoolEdit has some of these problems too
can xine or mplayer play any of the trailers?
I ran KDE 2.2.2 on a 486/66 with 24MB of RAM for a while, and it was OK for basic web browsing. It took a while to start up, but once up and running it was quite usable (in fact, more so than the crappy celery 400 system which it replaced - On-board video sucks)
CUPS allows use of IPP (Internet Printing Protocol) over SSL. I don't know whether Windows even supports IPP but it's pretty nifty on UNIX systems.