System settings, never user settings. I.e., stuff in/etc et al, but not in ~user/.program.
The reason for this is very simple. What should happen if the system administrator decides to remove a program (purge or not) and the user happens to store documents in its configuration directory (this could potentially be wine)? Should ~user/.program be removed? Should ~user be touched at all by any maintenance action performed by root? Clearly not.
If it managed to infect the Wine registry well enough that it's run automatically, I will have to go into the Wine registry to remove it manually. Or I could run a couple of simple commands: sudo aptitude purge wine; sudo aptitude install wine;
Wrong. Wine installs stuff in ~/.wine. The above commands don't touch user directories, so he would end up with a fresh system-wide wine installation but the same malware-ridden user config.
Scheduling policies:
-b | --batch set policy to SCHED_BATCH
-f | --fifo set policy to SCHED_FIFO
-i | --idle set policy to SCHED_IDLE
-o | --other set policy to SCHED_OTHER
-r | --rr set policy to SCHED_RR (default)
SCHED_OTHER, _RR and _FIFO are the ones you were referring to. But I don't know if _IDLE and _BATCH are separate scheduling algorithms or they are one of the others with different parameters...
And "Chromium" still doesn't have things like flash and printing, at least not in a stable, usable form.
Wrong about flash. Add '--enable-plugins' to chromium-browser's command line, and soft link the flash library into chromium's plugins directory (which they fail to tell you to do), e.g. in Ubuntu you would do:
The VirtualBox Open Source Edition (OSE) is the one that has been released under the GPL and comes with complete source code. It is functionally equivalent to the full VirtualBox package, except for a few features that primarily target enterprise customers. This gives us a chance to generate revenue to fund further development of VirtualBox. [emphasis mine]
But on Linux, it is inherently ugly. The beast looks ancient and the fonts and dialogs make matters worse.
Widgets and dialogs, ok, that's your aesthetic preference. But fonts? After a couple of years using Ubuntu I hate how Windows fonts look pixelated even with Cleartype on. Freetype is much better at its job than Cleartype. If only because of that, I prefer the looks of Firefox on linux than on Windows.
My guess is compiz. Install compizconfig-settings-manager, open it, go to "General" and tick "Sync to VBlank" in the "Display Settings" tab. The newer UXA-mode Intel driver may have problems with this, but for other cards this should make everything look better.
Bottomline for the topic under discussion: you never know.
And anyone with a whole brain just uses browser extensions. I have better things to do than finding ad server names and adding them to my hosts file every time I want to block something - my time is a more valuable resource than a handful of CPU cycles (I've never found ABP particularly heavy anyway, I don't know where you're getting this from).
Which is not incompatible with my point. When a way of solving a particular problem is impractical, the only value such solution may have is as an academic exercise. You'll learn a lot from such an exercise as long as you realize it's just that, an exercise.
If you really use quantum mechanics for a purely classical problem in your research, you are a lousy researcher, because you are being unable to focus on the important parts of the problem and neglect those that do not matter, thus wasting time and resources.
Obviously. Which isn't to say that the concept of a classical regime versus a quantum one isn't useful. You wouldn't describe the motion of a baseball using Schroedinger's equation: it's perfectly possible, but impractical.
Any information we can get about the transition between the two regimes is very valuable indeed.
I see you repeatedly dismissed any points you can't argue with. Nicely done.
Such as?
Why TCSH? What makes the FreeBSD defaults representative of all of BSD land, all of a sudden?
Why not? You compare the GNU shell against a random shell and I can't pick a random BSD flavour to make the comparison fairer?
Is there such a thing as a BSD shell anyway?
Well, since what's now MKSH couldn't even be compiled on any platform other than OpenBSD for many YEARS, I think, yes, it qualifies if anything does...
Quoting yourself: "With mksh it was made portable and can be installed on practically any Unix system.".
Portable, but it can't be compiled on anything other than BSD...
You're clearly stretching to justify the pointless, useless, incompatible, and annoying behavior.
You fail to see that what you find annoying is the fact that it is ultracompatible, unlike all non-GNU versions of ps. You find it annoying that typing the wrong command --which you are-- gives you a warning, and even then it runs. Really, I'm stretching here...
It doesn't do that when you pipe into it, which is all that matters in practice.
Gee. Thanks for telling me how I'm supposed to use my computer. Much appreciated.
And every time I need to do some quick math, do I have to write a script for it now? Because that's "all that matters"?
Erm, what? What I'm saying is that it would be wrong for bc to print a header, large or small, when you're using it within a script. In interactive mode, no, it doesn't matter if it prints four lines of header (1 for version number + 3 for GPL warranty). This just proves that you get easily annoyed, nothing more.
I don't see how that's to do with anything other than how the binaries were compiled?
Well then, you apparently know absolutely nothing about any form of programming... This does explain quite a bit, really.
Right, 'course I don't...
GNU make is a great example, because it's obviously immensely superior to all other implementations of make.
Actually it's pretty horrible. It merely works most of the time because it's been around since before Linux, and used on so many systems where the proprietary version of make was horrendous, that EVERYTHING is coded with GMakes bugs and quirks in-mind.
Have you noticed that cdrtools always complains when you use GMake, and recommends the use of anything else? Not to say that BSD make should be used... smaller target audience and all that...
Besides, you've proven pretty well you know nothing about programming at all. And you've not bothered to list a single reason why gmake is supposedly superior, at all.
Yeah, right. Come back when you've written a set of makefiles for a large project that work with GNU make, BSD make, SunOS make and Tru64 make at the same time, supporting different architectures, compilers, optional library overrides, etc. I have, and what I can tell you is that the only thing GNU make does wrong is that it spoils you for options. Other make systems are simply underfeatured.
That's almost funny. Pretty much the only thing a GNU man page has ever told anyone about anything, is that they should be using "info" instead, if they want to get ANY information on the program...
Way to avoid my point.
BSD tools are underfeatured with respect to their GNU counterparts. Prove the opposite if you can.
Thank god for the OpenBSD version of ksh. With mksh it was made portable and can be installed on practically any Unix system. It features practically every BASH feature human beings could ever use, while being a tiny fraction of the size.
Bash and ksh are quite on par feature-wise, so pick whichever one you prefer since both are available on GNU and BSD systems. However this misses the GNU-vs-BSD point, as do you -- if anything, you should be comparing bash against tcsh which is the default shell in FreeBSD. Is there such a thing as a BSD shell anyway?
And how about FreeBSD's tar? No -z -Z -j crap... use any of the flags, and whatever compression method used will be detected and handled.
From the GNU tar manpage (which, it may surprise you, is actually useful):
-a, --auto-compress
with --create, selects compression algorithm basing on the suffix of
the archive file name
So it's there, as an option. And IMO it makes better sense as an option than as default behaviour.
How about "ps -ax" bitching at you not to type the dash (which every other Unix system requires),
Again from a GNU manpage:
Note that "ps -aux" is distinct from "ps aux". The POSIX and UNIX standards require that "ps -aux" print all processes owned by a user named "x", as well as printing all processes that would be selected by the -a option. If the user named "x" does not exist, this ps may interpret the command as "ps aux" instead and print a warning.
That is, BSD ps has a given syntax ('ps aux') and "conveniently" ignores any dash preceding the options ('ps -aux'=='ps aux'). This clashes with POSIX standards. GNU ps not only supports its own POSIXly correct syntax and the strict BSD syntax, but it also correctly catches things like 'ps -aux', issues a warning and runs the command you intended to run. And you complain?
"bc" printing a dozen lines of the GPL every time you start it up?
If a dozen is three, then yes. It doesn't do that when you pipe into it, which is all that matters in practice.
Or how about just the fact that nearly every GPL binary is 4X the size of any of the BSD equivalents?
I don't see how that's to do with anything other than how the binaries were compiled?
Why don't you start trying to list a few ways YOU'VE find GNU utilities to be any better than their BSD counterparts?
GNU make is a great example, because it's obviously immensely superior to all other implementations of make.
Other than little personal annoyances, you've listed nothing much. Try comparing manpages side by side and let me know when you find a single *feature* in a BSD tool that is not in a GNU tool. Starting by the ones you mentioned above.
I just don't see the requirement to have a shitty GNU userland on the FreeBSD system.
What do you mean? Every GNU tool I've used is far better than its BSD counterpart (if it exists). Some manpages do suck, but I've never failed to find the information I need for any command that is remotely complicated.
In any case, if the Debian maintainers shared your opinion of the BSD userland, they would try to get that into their standard Linux-based distribution, rather than wait to have the FreeBSD kernel to do that there.
Is it essentially just FreeBSD with APT and gnu userland instead of ports and bsd userland?
It's FreeBSD with the entire Debian userland. AND it's Debian with a FreeBSD kernel. Pretty much like a centaur is a man with a horse's body AND a horse with a human head.
The best description depends on what part you focus on. To me it's Debian with a FreeBSD kernel.
The specific setting I wanted was focus follows mouse, don't raise. Setting this involved the configuration tool (don't know the name) and using gconf and using google to figure out what and where the configuration setting I'm looking for is.
It would have been much simpler if you had opened System > Preferences > Windows and clicked on the little checkbox next to "Select windows when the mouse moves over them", leaving "Raise selected windows after an interval" unchecked.
Ubuntu 9.04 boots 13% faster with ext4 than with ext3
or using the AMD Sempron data:
Ubuntu 9.04 boots 18% faster with ext4 than with ext3
If the boot time with ext3 was one hour, 3.1 seconds would be pretty unimpressive, and if ext3 took 3.2 seconds ext4 would be the bestest filesystem ever. Absolute differences are mostly meaningless.
Slashdot Mirror
Yup.
System settings, never user settings. I.e., stuff in /etc et al, but not in ~user/.program.
The reason for this is very simple. What should happen if the system administrator decides to remove a program (purge or not) and the user happens to store documents in its configuration directory (this could potentially be wine)? Should ~user/.program be removed? Should ~user be touched at all by any maintenance action performed by root? Clearly not.
From TFA:
If it managed to infect the Wine registry well enough that it's run automatically, I will have to go into the Wine registry to remove it manually. Or I could run a couple of simple commands:
sudo aptitude purge wine;
sudo aptitude install wine;
Wrong. Wine installs stuff in ~/.wine. The above commands don't touch user directories, so he would end up with a fresh system-wide wine installation but the same malware-ridden user config.
From running `chrt` on 2.6.31:
Scheduling policies:
-b | --batch set policy to SCHED_BATCH
-f | --fifo set policy to SCHED_FIFO
-i | --idle set policy to SCHED_IDLE
-o | --other set policy to SCHED_OTHER
-r | --rr set policy to SCHED_RR (default)
SCHED_OTHER, _RR and _FIFO are the ones you were referring to. But I don't know if _IDLE and _BATCH are separate scheduling algorithms or they are one of the others with different parameters...
And "Chromium" still doesn't have things like flash and printing, at least not in a stable, usable form.
Wrong about flash. Add '--enable-plugins' to chromium-browser's command line, and soft link the flash library into chromium's plugins directory (which they fail to tell you to do), e.g. in Ubuntu you would do:
sudo ln -s /usr/lib/flashplugin-installer/libflashplayer.so /usr/lib/chromium-browser/plugins/
Works well, is stable and is usable, despite the warnings that it may melt your computer etc. Printing is still unavailable.
Microsoft Bob. He had it coming...
The latter. See here, where they say
The VirtualBox Open Source Edition (OSE) is the one that has been released under the GPL and comes with complete source code. It is functionally equivalent to the full VirtualBox package, except for a few features that primarily target enterprise customers. This gives us a chance to generate revenue to fund further development of VirtualBox. [emphasis mine]
But on Linux, it is inherently ugly. The beast looks ancient and the fonts and dialogs make matters worse.
Widgets and dialogs, ok, that's your aesthetic preference. But fonts? After a couple of years using Ubuntu I hate how Windows fonts look pixelated even with Cleartype on. Freetype is much better at its job than Cleartype. If only because of that, I prefer the looks of Firefox on linux than on Windows.
So again, what was Linux hoping to achieve by dropping old "obsolete" OSS in favor of increasingly complex solutions?
To remove floating-point operations (like sound mixing) from the kernel, I believe.
My guess is compiz. Install compizconfig-settings-manager, open it, go to "General" and tick "Sync to VBlank" in the "Display Settings" tab. The newer UXA-mode Intel driver may have problems with this, but for other cards this should make everything look better.
Bottomline for the topic under discussion: you never know.
And anyone with a whole brain just uses browser extensions. I have better things to do than finding ad server names and adding them to my hosts file every time I want to block something - my time is a more valuable resource than a handful of CPU cycles (I've never found ABP particularly heavy anyway, I don't know where you're getting this from).
I hope Mr. Debug gets over his loss soon.
Which is not incompatible with my point. When a way of solving a particular problem is impractical, the only value such solution may have is as an academic exercise. You'll learn a lot from such an exercise as long as you realize it's just that, an exercise.
If you really use quantum mechanics for a purely classical problem in your research, you are a lousy researcher, because you are being unable to focus on the important parts of the problem and neglect those that do not matter, thus wasting time and resources.
Obviously. Which isn't to say that the concept of a classical regime versus a quantum one isn't useful. You wouldn't describe the motion of a baseball using Schroedinger's equation: it's perfectly possible, but impractical.
Any information we can get about the transition between the two regimes is very valuable indeed.
Bye!
That is a fair point.
I see you repeatedly dismissed any points you can't argue with. Nicely done.
Such as?
Why TCSH? What makes the FreeBSD defaults representative of all of BSD land, all of a sudden?
Why not? You compare the GNU shell against a random shell and I can't pick a random BSD flavour to make the comparison fairer?
Well, since what's now MKSH couldn't even be compiled on any platform other than OpenBSD for many YEARS, I think, yes, it qualifies if anything does...
Quoting yourself: "With mksh it was made portable and can be installed on practically any Unix system.".
Portable, but it can't be compiled on anything other than BSD...
You're clearly stretching to justify the pointless, useless, incompatible, and annoying behavior.
You fail to see that what you find annoying is the fact that it is ultracompatible, unlike all non-GNU versions of ps. You find it annoying that typing the wrong command --which you are-- gives you a warning, and even then it runs. Really, I'm stretching here...
Gee. Thanks for telling me how I'm supposed to use my computer. Much appreciated.
And every time I need to do some quick math, do I have to write a script for it now? Because that's "all that matters"?
Erm, what? What I'm saying is that it would be wrong for bc to print a header, large or small, when you're using it within a script. In interactive mode, no, it doesn't matter if it prints four lines of header (1 for version number + 3 for GPL warranty). This just proves that you get easily annoyed, nothing more.
Well then, you apparently know absolutely nothing about any form of programming... This does explain quite a bit, really.
Right, 'course I don't...
Actually it's pretty horrible. It merely works most of the time because it's been around since before Linux, and used on so many systems where the proprietary version of make was horrendous, that EVERYTHING is coded with GMakes bugs and quirks in-mind.
Have you noticed that cdrtools always complains when you use GMake, and recommends the use of anything else? Not to say that BSD make should be used... smaller target audience and all that...
Besides, you've proven pretty well you know nothing about programming at all. And you've not bothered to list a single reason why gmake is supposedly superior, at all.
Yeah, right. Come back when you've written a set of makefiles for a large project that work with GNU make, BSD make, SunOS make and Tru64 make at the same time, supporting different architectures, compilers, optional library overrides, etc. I have, and what I can tell you is that the only thing GNU make does wrong is that it spoils you for options. Other make systems are simply underfeatured.
That's almost funny. Pretty much the only thing a GNU man page has ever told anyone about anything, is that they should be using "info" instead, if they want to get ANY information on the program...
Way to avoid my point.
BSD tools are underfeatured with respect to their GNU counterparts. Prove the opposite if you can.
There, spelled out clearly.
Thank god for the OpenBSD version of ksh. With mksh it was made portable and can be installed on practically any Unix system. It features practically every BASH feature human beings could ever use, while being a tiny fraction of the size.
Bash and ksh are quite on par feature-wise, so pick whichever one you prefer since both are available on GNU and BSD systems. However this misses the GNU-vs-BSD point, as do you -- if anything, you should be comparing bash against tcsh which is the default shell in FreeBSD. Is there such a thing as a BSD shell anyway?
And how about FreeBSD's tar? No -z -Z -j crap... use any of the flags, and whatever compression method used will be detected and handled.
From the GNU tar manpage (which, it may surprise you, is actually useful):
-a, --auto-compress
with --create, selects compression algorithm basing on the suffix of
the archive file name
So it's there, as an option. And IMO it makes better sense as an option than as default behaviour.
How about "ps -ax" bitching at you not to type the dash (which every other Unix system requires),
Again from a GNU manpage:
Note that "ps -aux" is distinct from "ps aux". The POSIX and UNIX standards require that "ps -aux" print all processes owned by a user named "x", as well as printing all processes that would be selected by the -a option. If the user named "x" does not exist, this ps may interpret the command as "ps aux" instead and print a warning.
That is, BSD ps has a given syntax ('ps aux') and "conveniently" ignores any dash preceding the options ('ps -aux'=='ps aux'). This clashes with POSIX standards. GNU ps not only supports its own POSIXly correct syntax and the strict BSD syntax, but it also correctly catches things like 'ps -aux', issues a warning and runs the command you intended to run. And you complain?
"bc" printing a dozen lines of the GPL every time you start it up?
If a dozen is three, then yes. It doesn't do that when you pipe into it, which is all that matters in practice.
Or how about just the fact that nearly every GPL binary is 4X the size of any of the BSD equivalents?
I don't see how that's to do with anything other than how the binaries were compiled?
Why don't you start trying to list a few ways YOU'VE find GNU utilities to be any better than their BSD counterparts?
GNU make is a great example, because it's obviously immensely superior to all other implementations of make.
Other than little personal annoyances, you've listed nothing much. Try comparing manpages side by side and let me know when you find a single *feature* in a BSD tool that is not in a GNU tool. Starting by the ones you mentioned above.
I just don't see the requirement to have a shitty GNU userland on the FreeBSD system.
What do you mean? Every GNU tool I've used is far better than its BSD counterpart (if it exists). Some manpages do suck, but I've never failed to find the information I need for any command that is remotely complicated.
In any case, if the Debian maintainers shared your opinion of the BSD userland, they would try to get that into their standard Linux-based distribution, rather than wait to have the FreeBSD kernel to do that there.
Is it essentially just FreeBSD with APT and gnu userland instead of ports and bsd userland?
It's FreeBSD with the entire Debian userland. AND it's Debian with a FreeBSD kernel. Pretty much like a centaur is a man with a horse's body AND a horse with a human head.
The best description depends on what part you focus on. To me it's Debian with a FreeBSD kernel.
You missed the obvious:
E: Invalid operation with.
I ran it on firefox (which I can't update due to IS) and got 71
Interestingly, I get 70/100 with AdBlock disabled, and 71/100 if I turn it on. I'm a bit puzzled.. does anyone get the same behaviour?
The specific setting I wanted was focus follows mouse, don't raise. Setting this involved the configuration tool (don't know the name) and using gconf and using google to figure out what and where the configuration setting I'm looking for is.
It would have been much simpler if you had opened System > Preferences > Windows and clicked on the little checkbox next to "Select windows when the mouse moves over them", leaving "Raise selected windows after an interval" unchecked.
More like "time for frist psot pissing contest!".
Ubuntu 9.04 boots 13% faster with ext4 than with ext3
or using the AMD Sempron data:
Ubuntu 9.04 boots 18% faster with ext4 than with ext3
If the boot time with ext3 was one hour, 3.1 seconds would be pretty unimpressive, and if ext3 took 3.2 seconds ext4 would be the bestest filesystem ever. Absolute differences are mostly meaningless.