You must not read Slashdot either, because you completely missed the obvious meme of all:
"The CPU is dying -- Netcraft confirms it!"
Or "CPUs are for old people".
That being said, why is there so much joking in slashdot these days? Truly insightfull posts are hard to come by when every discussion starts with 50 "funny" (but painfully obvious) jokes.
Debian testing is far more stable than Ubuntu and is regularly updated.
Debian testing and Ubuntu are both based on Debian unstable. It takes a while for testing to become "debian stable", and it also takes a while before Ubuntu becomes a "release". Moreover, it takes a while for an Ubuntu LTS release to get better - but if you give Ubuntu LTS some time to mature, it will prove to be extremely solid (this is what happened with Hardy), while still delivering relatively recent packages.
I understand a number of them have been deferred to lenny.1, but I had expected this number to drop further before a release was made. Has Debian changed their release policy?
Honestly, if you're the kind of guy who uses Debian stable you certainly will stay with KDE 3.5 until at least 4.5.
Good to see that in the time of bleeding edge releases-every-6-months distros there's still a choice that actually allows you to get work done.
Ubuntu LTS is one such choice as well.
I made the mistake of upgrading to Ubuntu 8.10 from 8.04 LTS (and didn't like it), and now I need to go back. With Lenny out, it will feel less like a defeat if I install Lenny instead;-).
Now when sid starts moving again, KDE 4.2 will go in - completely avoiding the earlier, less complete releases that everybody was ranting about.
Hopefully they will freeze KDE 4.3 with Qt 4.5. Freezing kde at 4.2 would seem like a mistake, when you consider that KDE people mostly focus on fixing bugs for 4.3. Also, Qt 4.5 should bring big performance improvements.
Ruby's startup time is the same as Python. Both are too slow for many things small shell scripts are used for, which contrary to your belief often do get run thousands of times.
It's a design choice that they get run thousands of times - the same design choice would be very bad programming when done in ruby/python scipt.
Your beliefs that shell scripting is never appropriate, that python's syntax is not an impediment, and that Ruby is 'slow' compared to Python are not based on facts, they're based on ignorance.
And then the whole script goes wildly crazy because it ends up in an unanticipated state? Sounds delicious.
There's times to abort in the face of error... and times not to.
The idea with exceptions is that it doesn't happen. Unless you supress the exception, your whole script aborts with a traceback that tells exactly what went wrong. With shell scripts, you get error status and a cryptic error message if you get lucky.
I'm a lazy bastard, and I've found this to be the perfect behaviour.
Python doesn't help much over shell scripts without extra libraries, which may or may not be present on any given system.
What are those extra libraries without which you can't work? Python standard library is absolutely enough for shell script like tasks, both trivial and non-trivial.
Python has changed incompatibly several times already.
It's actually quite rare. Python 3.0 was created explicitly to allow breaking of the compatibility. If you write scripts that use the new stuff, of course they won't work on older scripts. But old scripts still work on new python 2.x interpreters.
Or do you have a concrete example in mind?
Python has a large startup overhead:
So a 0.02 second startup time is a problem for you? If you are starting zillions of python interpreters, you are doing something very wrong.
Python is not the same syntax as the shell. If you don't learn the shell then your day-to-day command lines are gimped.
Of course you should learn the shell, and shell scripting as well (to some degree). You still need to be able to read and modify shell scripts, unfortunately. Just don't write new ones that you publish (as opposed to using them for private things).
Ruby is actually much better... since it has a sensible syntax you could make a rubysh that wouldn't suck.
If you care so much about performance, I'm surprised you bring up ruby;-). It's not really "much better" even if your friend moved to it from perl - it's just something some people pick up because they heard a cousin of their friend was once bitten by python's indentation rules.
Your idea works until you have a huge number of files (not uncommon for a backup script) and run out of memory on the.read() call. Not pretty. To avoid that, you have to use.readline() or the file iterator, both of which have the newline limitation I mentioned.
So, it's back to actual coding then:-). I don't have a oneliner for that, but shouldn't be too hard:
b = f.read(blocksize) spl = b.split('\0')... do stuff with lines, and reloop
Always add the last line from the split to the beginning of next block.
This way, you can make a memory-efficient generator that only allocates data when it needs it.
Honestly, I just never got into python. I like perl (and hate it), and I like Ruby (and love it), but Python never "clicked" for me. Python and Tcl are the "scripting languages I just don't enjoy working in".
I believe this is a common mindset issue. Ruby borrowed lots of stuff from perl (which they thought was good, or appealing to convert - I'm not sure), including TIMTOWTDI, whereas Python community thinks of Perl as a warning example more than anything else. My theory is that the different languages balance between simplicity and 'regularity' (python) vs. 'playfullness' and 'interesting' solutions (ruby, perl).
These days, e.g. Python is installed everywhere you need to go.
No it isn't. Not even remotely close.
And in most cases the response to a request to install an entire programming language would be flat rejection, turning to raucous laughter when they realise you only want it because you don't like any of the several scripting environments that are already available.
Sounds like a rather dysfunctional working environment.
I had something like this in mind when I said "everywhere you need to go" (as opposed to just saying "everywhere").
"if [ $? != 0 ]; then" goes a long way and you get bonus points for wrapping it in a function.
What I like about the python way is that you don't have to write any of that - if something fails, the whole function fails (unless you specifically catch the exception). No need for explicit error handling to clutter your scripts.
Why isn't there (or is there?) a simple python cheat guide, or library, that do the same things as grep, awk, find, mv and xargs?
Forgot to mention - no need to do it all in raw python. Just call out to shell when you feel like it, if you are sure it can stay unix-only. You can do wonders with some shell invocation + os.popen(...).read()
Shell scripts have horrible error handling, and quickly become a maintenance nightmare. These days, e.g. Python is installed everywhere you need to go.
Just do this:
def c(s): os.system(c)
and you have mostly covered the area where shell scripts excel. You can still write minimal "shell scripts" inside c().
Unluckily, you still *need* to grok shell scripting to some extent, or at least be able to read them. Just don't write them if you can help it.
Don't know why they'd pick the unstable beta distro to do it, though. Ought to use the Russian version of CentOS or Ubuntu LTS.
I guess they can still funnel fixes from RHEL based on that Fedora later on. Seems a bit unnecessary duplication of effort though.
Personally, I'd preferred them to have based on Ubuntu, and perhaps pay canonical for some support contracts if necessary. Perhaps Fedora is the more patriotic alternative because there is nobody to pay?;-)
Oh, by the way, proprietary Qt was shipped as system libraries on those distros that defaulted to KDE. The GPL has an exception for that, placing Qt in the same category as Win32, Cocoa and many flavors of Motif.
...until Novell bought them out. When it became apparent that Novell wasn't going to uphold the SuSE quality, I switched over to Ubuntu. Haven't looked back since.
It seems [Open]SUSE is becoming a bit "hip" again, after years of silence. These days everybody is using Ubuntu (and it's becoming synonymous with "Linux"), though...
Slashdot Mirror
You must not read Slashdot either, because you completely missed the obvious meme of all:
"The CPU is dying -- Netcraft confirms it!"
Or "CPUs are for old people".
That being said, why is there so much joking in slashdot these days? Truly insightfull posts are hard to come by when every discussion starts with 50 "funny" (but painfully obvious) jokes.
Don't do that. Instead, go from intrepid to Squeeze (testing) in a month or so. Going from Ubuntu intrepid to Debian Lenny will downgrade your libc.
I plan to do a full install on another partition, just to play it safe. Thanks for the warning anyway.
Debian testing is far more stable than Ubuntu and is regularly updated.
Debian testing and Ubuntu are both based on Debian unstable. It takes a while for testing to become "debian stable", and it also takes a while before Ubuntu becomes a "release". Moreover, it takes a while for an Ubuntu LTS release to get better - but if you give Ubuntu LTS some time to mature, it will prove to be extremely solid (this is what happened with Hardy), while still delivering relatively recent packages.
I understand a number of them have been deferred to lenny.1, but I had expected this number to drop further before a release was made. Has Debian changed their release policy?
Yes, they actually made a release.
*drumroll*
Honestly, if you're the kind of guy who uses Debian stable you certainly will stay with KDE 3.5 until at least 4.5.
Good to see that in the time of bleeding edge releases-every-6-months distros there's still a choice that actually allows you to get work done.
Ubuntu LTS is one such choice as well.
I made the mistake of upgrading to Ubuntu 8.10 from 8.04 LTS (and didn't like it), and now I need to go back. With Lenny out, it will feel less like a defeat if I install Lenny instead ;-).
Now when sid starts moving again, KDE 4.2 will go in - completely avoiding the earlier, less complete releases that everybody was ranting about.
Hopefully they will freeze KDE 4.3 with Qt 4.5. Freezing kde at 4.2 would seem like a mistake, when you consider that KDE people mostly focus on fixing bugs for 4.3. Also, Qt 4.5 should bring big performance improvements.
Ruby's startup time is the same as Python. Both are too slow for many things small shell scripts are used for, which contrary to your belief often do get run thousands of times.
It's a design choice that they get run thousands of times - the same design choice would be very bad programming when done in ruby/python scipt.
Your beliefs that shell scripting is never appropriate, that python's syntax is not an impediment, and that Ruby is 'slow' compared to Python are not based on facts, they're based on ignorance.
Ok, you convinced me with this argument.
And then the whole script goes wildly crazy because it ends up in an unanticipated state? Sounds delicious.
There's times to abort in the face of error... and times not to.
The idea with exceptions is that it doesn't happen. Unless you supress the exception, your whole script aborts with a traceback that tells exactly what went wrong. With shell scripts, you get error status and a cryptic error message if you get lucky.
I'm a lazy bastard, and I've found this to be the perfect behaviour.
Python doesn't help much over shell scripts without extra libraries, which may or may not be present on any given system.
What are those extra libraries without which you can't work? Python standard library is absolutely enough for shell script like tasks, both trivial and non-trivial.
Python has changed incompatibly several times already.
It's actually quite rare. Python 3.0 was created explicitly to allow breaking of the compatibility. If you write scripts that use the new stuff, of course they won't work on older scripts. But old scripts still work on new python 2.x interpreters.
Or do you have a concrete example in mind?
Python has a large startup overhead:
So a 0.02 second startup time is a problem for you? If you are starting zillions of python interpreters, you are doing something very wrong.
Python is not the same syntax as the shell. If you don't learn the shell then your day-to-day command lines are gimped.
Of course you should learn the shell, and shell scripting as well (to some degree). You still need to be able to read and modify shell scripts, unfortunately. Just don't write new ones that you publish (as opposed to using them for private things).
Ruby is actually much better... since it has a sensible syntax you could make a rubysh that wouldn't suck.
If you care so much about performance, I'm surprised you bring up ruby ;-). It's not really "much better" even if your friend moved to it from perl - it's just something some people pick up because they heard a cousin of their friend was once bitten by python's indentation rules.
Does python can really replace shell scripting ?
Yes, for everything apart from script you run with 'source' that manipulate the environment directly.
I'd really like to know. When I write scripts, I use intensively pipes and awk.
Would python allow me to do the same kind of things that awk do ?
Yes, you can call out for a shell by using os.system, os.popen, subprocess module.
I do think awk is pretty redundant though.
Your idea works until you have a huge number of files (not uncommon for a backup script) and run out of memory on the .read() call. Not pretty. To avoid that, you have to use .readline() or the file iterator, both of which have the newline limitation I mentioned.
So, it's back to actual coding then :-). I don't have a oneliner for that, but shouldn't be too hard:
b = f.read(blocksize) ... do stuff with lines, and reloop
spl = b.split('\0')
Always add the last line from the split to the beginning of next block.
This way, you can make a memory-efficient generator that only allocates data when it needs it.
I've run into one big problem replacing find/xargs in Python: There's no good equivalent of the find '-print0' and xargs '-0' options.
This seems to work:
fs = os.popen('find -print0').read().split('\0')
Honestly, I just never got into python. I like perl (and hate it), and I like Ruby (and love it), but Python never "clicked" for me. Python and Tcl are the "scripting languages I just don't enjoy working in".
I believe this is a common mindset issue. Ruby borrowed lots of stuff from perl (which they thought was good, or appealing to convert - I'm not sure), including TIMTOWTDI, whereas Python community thinks of Perl as a warning example more than anything else. My theory is that the different languages balance between simplicity and 'regularity' (python) vs. 'playfullness' and 'interesting' solutions (ruby, perl).
No it isn't. Not even remotely close.
And in most cases the response to a request to install an entire programming language would be flat rejection, turning to raucous laughter when they realise you only want it because you don't like any of the several scripting environments that are already available.
Sounds like a rather dysfunctional working environment.
I had something like this in mind when I said "everywhere you need to go" (as opposed to just saying "everywhere").
Hmm... did someone re-invent imake?
No, SCons does not generate makefiles.
SCons here was just an example to illustrate how much Automake sucks. Obviously we have other systems like CMake as well.
Wherever you want to do an awful lot of things with the input and output of) system utilities and./or bash builtins.
Whenever you try to do something nontrivial in between the system utilities, you start losing the benefit of shell scripts.
Check out GNU autoconf. That's a good example of how a script works on *nix box. And, yes, they are useful!
Autoconf is also a horrible peace of crap. One of the better reason to hate the concept of shell scripts, actually.
Check out SCons for comparison:
Program('hello.c')
or
SharedLibrary('foo', ['f1.c', 'f2.c', 'f3.c'])
And that's pretty much it. I'm not sure all the horrors required by autoconf would fit into a slashdot posting.
"if [ $? != 0 ]; then" goes a long way and you get bonus points for wrapping it in a function.
What I like about the python way is that you don't have to write any of that - if something fails, the whole function fails (unless you specifically catch the exception). No need for explicit error handling to clutter your scripts.
Or better, just...
c = os.system
Ok, I cheated. I usually have it like this:
def c(s):
print ">",s
os.system(s)
Why isn't there (or is there?) a simple python cheat guide, or library, that do the same things as grep, awk, find, mv and xargs?
Forgot to mention - no need to do it all in raw python. Just call out to shell when you feel like it, if you are sure it can stay unix-only. You can do wonders with some shell invocation + os.popen(...).read()
Why isn't there (or is there?) a simple python cheat guide, or library, that do the same things as grep, awk, find, mv and xargs?
re.findall, s.split(), os.walk, shutil.move,
" ".join
Don't do it.
Shell scripts have horrible error handling, and quickly become a maintenance nightmare. These days, e.g. Python is installed everywhere you need to go.
Just do this:
def c(s): os.system(c)
and you have mostly covered the area where shell scripts excel. You can still write minimal "shell scripts" inside c().
Unluckily, you still *need* to grok shell scripting to some extent, or at least be able to read them. Just don't write them if you can help it.
Don't know why they'd pick the unstable beta distro to do it, though. Ought to use the Russian version of CentOS or Ubuntu LTS.
I guess they can still funnel fixes from RHEL based on that Fedora later on. Seems a bit unnecessary duplication of effort though.
Personally, I'd preferred them to have based on Ubuntu, and perhaps pay canonical for some support contracts if necessary. Perhaps Fedora is the more patriotic alternative because there is nobody to pay? ;-)
Incidentally - can you run Hind with Wine?
Oh, by the way, proprietary Qt was shipped as system libraries on those distros that defaulted to KDE. The GPL has an exception for that, placing Qt in the same category as Win32, Cocoa and many flavors of Motif.
Really? Can you elaborate on this?
...until Novell bought them out. When it became apparent that Novell wasn't going to uphold the SuSE quality, I switched over to Ubuntu. Haven't looked back since.
It seems [Open]SUSE is becoming a bit "hip" again, after years of silence. These days everybody is using Ubuntu (and it's becoming synonymous with "Linux"), though...