I use hp-ux and have been looking forward to a port of nutscrape 6 for a long time
FYI, since Mozilla 0.8, there are prebuilt binaries for both HP-UX 10.20 and HP-UX 11. I know there have been some also for older milestones (M18, IIRC). They are made available some time after the Windows/Linux/Solaris releases.
Unfortunately, it seems you have to build and install GTK and the other libraries (i.e. libjpeg, libungif, libpng and friends) by yourself, which isn't exactly a painless process on HP-UX 10.20 (I don't know about 11, but it should be definitively simplier).
OTOH, if you really want it, IE 5 is available for HP-UX 10.20 (just search the microsoft site). At least it seems to work enough...
iptables uses shell scripts with a BUNCH of commands, while ipfilter uses a configuration file
Well, looking at it from a pure technical point of view, it should be mostly a matter of "let's do a shell script that reads firewall rules from a configuration file", which every admin put in charge of configure the firewall should be able to do (IMHO).
On the human side I agree that life could be somewhat easier without the "firewall configuration scripts du jour" that the previous admin (or the previous guy who played as an admin on TV) left somewhere on the system and now it's your job to locate/check/mantain...
If you read the documentation about IPV6, its adoption should greatly reduce the size of routing tables. So, perhaps, it's the case of researching the thing a little more.
AFAIK (from reading the IPV6 docs), it's the current inefficient allocation of IPV4 networks/addresses that leads us to large routing tables.
Taking your reasonement to the extreme, we should all start writing JVM opcodes.
<IRONY>
It is flexible enough so several languages with other paradigms are implemented on it, it is cross platform in the sense that there are decent JVM for the main platforms, and making readable programs only requires disciplined programmers. Maintenance is easily done because everything is well documented with comments and on dead trees.
</IRONY >
It is worth noting that it requires years for a coder to get the experience needed to be `disciplined'. Expecially, it requires lots of debugging other's code. Even you weren't born as a `disciplined' programmer, but you became disciplined like everyone else, day by day.
In the meanwhile, either the `still not disciplined coder' refrain itself from using languages requiring more discipline (which is a fancy way just to say that some languages are definitively not for beginners), or (s)he use the language anyway, with great headaches for the guy doing maintenance.
It's good for a language to be flexible, but trying to support all coding styles at once just for the sake of it is pure evil. That's why there are multiple languages out there.
Do you really mean that it is not possible to write readable code in perl???
I was talking about languages in general. All languages suck more or less from this point of view (this is why you have many of them - otherwise we'd be all using only the One True Language - which is not the case).
That said, i fear Perl is going in the direction of the creeping featurism that affected C++ some time ago, and IMHO it would be really a pity. Introducing constructs that to save a line or two affects how the code is interpreted 1200 lines below, and then saying "you should use them locally" adds to the list of things that an average developer could get wrong or overlook.
A language with an anal-retentive syntax is definitively not the answer, but nor is trying to support every conceivable programming style (in the sense of the amount of syntax sugar thrown in) in a single language.
So, to answer your question: it is definitively possible to write perfectly readable Perl, exactly in the same manner it is possible to write perfectly readable assembly or C. But people won't write readable code just because it's possible.
The usefulness of a language [is determined] by the speed at which you can make something out of it that you can actually use.
Uhm, that's a little bit narrow-minded IMHO. At least, you should throw in also the ability for people other than the original author to quickly understand what the code does, how it does it and change its behaviour according to the new requirements. Requirements usually aren't written in stone, and even if Perl allows you to be extremely quick at producing new working code from zero, having to almost refactor everything at every change request which can't be done by the original author doesn't sound too well to me.
You can say: "but there are comments for this! There is literate programming!", but in the end the final word is always said by code itself, not by the comments (do you expect all programmers to write meaningful and exahustive comments explaining the exact behaviour and side effects of a piece of code? I've given up expecting this some years ago...).
I may be wrong, of course, and honestly I hope I am. I recognize that Perl programmers have better things to do that writing code which is difficult to read, but I wouldn't like to have to say one day "Inside Perl there is a little nifty language..." as it has been said over and over for C++.
If this is going to be the case, expect a Language-X to Perl translator really soon, and Perl being relegated to be the new assembly language of the third millenium (btw, IIRC, this is one of Larry's proposals: using Perl as a cross-platform VM with translators on the top of it from several languages -- after all, this is the current trend).
could perhaps make an XML parser that could translate this into classes for an interpreted language like Python
Do you mean Glade plus libglade with the Python bindings in gnome-python?
Glade, other than generating C source for the GTK+ GUI you design, saves the file describing the GUI in an XML format which can be read via libglade. Then, it's only a matter of linking it in and calling a function which reads the XML file and builds the widget tree. The task of registering your handlers for the various events (i.e. a certain button pressed) can also be performed automatically by libglade, i.e. by looking at the executable symbol table for languages like C, or using the introspection features of the interpreter in the case of Python.
I always thought that the "write good code" statement was implicit.
Mmmmh... I used to think so, but it's not always true. The current trend, as I can see, is that (at least for some managers) it is better having something quickly packed together and half working today with the promise of making it fully working tomorrow than having something well designed and fully working, but not before the next week.
In other words, there are people out there thinking
good code/design == works well == more time
bad code/design == works enough == less time
bad code/design now plus good code/design after == good code/design
which, unfortunately, is not true.
So, while I'm agreeing with you, to some people it is not so evident that a coder should write good code...
Uhm, for printing pourpouses, TT is not better than Adobe Type 1, and also there is the not-so-little inconvenience of TT font makers being expecially creative when it comes to give the right name to glyphs (instead of following the Adobe convention). Peple having to live with iso-8859-1/2/15 instead of plain US-ASCII perhaps can understand it better.
BTW, Ghostscript already comes with an high quality replacement for standard Postscript fonts (the URW fonts), which can be readily used with XFree since they are common Adobe Type 1 (this is explained in better detail somewhere in the Font-deuglification-howto).
If I understood it correctly, a major TrueType feature that Adobe Type 1 fonts don't have is the presence of hints for rendering glyphs at small sizes (or low resolutions), but I doubt they can be used in a free TT font renderer, since there should be patents on them. But using the bitmapped versions for exact size matches and the vectorial versions in the other cases gives you the same result... and XFree allows you do to this automatically (again, follow the instructions within the URW fonts).
Putting every font file in a known place is going to leave unsolved a part of the problem, because this wont't work if you use a centralized X font server (and install noncommon fonts only on the machine running it). Here I'd really prefer an extension to the X Font Server protocol.
About fonts.alias: it isn't really needed at all, but it's there if you need it. fonts.dir OTOH is something we could easily get rid of, since all font files commonly used today already contain the needed information, but then, it's only a matter of running mkfontdir each time the X font server is started...
By opening up the source, any tom, dick and harry can view the source and the innovation.
Yes, but you know: unmantained software rots. And who is better than the people who did the maintenance since yesterday to continue doing the maintenance (for a fee)?
IMHO, in some cases, it would be a great opportunity to start working for yourself, not for your boss. Of course, your boss won't agree...
How can the filesystem code possibly know when data is on the disk when the kernel is caching it
Simple: it doesn't know when data is on the disk, because with common hardware you can't. Hard disks have their onboard (volatile) memory, and write operations report as completed when data reach the cache of the disk, which IIRC can't be controlled by software.
Someone once told me SGI has a smart disk controller backed up with a battery, so in the event of a blackout, the controller would keep for some hours the data still not written on the disk, flushing it on the disk on the next power up.
BTW, it can decode encrypted pdf too with a little modification. Just follow the (very simple) instructions printed when you try to read an encrypted.pdf for the first time...
Of course, these are the same people that use the MAPS DUL
Please report the whole story, not just half. Maps DUL usage has been dropped shortly after.
Also, please note that using DUL generally does not block dial-up users: it forces them to use the ISP's server as a relay, as it should be. Unfortunately, it seems that there are troubles for some dial-up users to do so, and for the sake of them DUL has been dropped. But the vast majority is not affected at all.
Heck, if you want to use your local sendmail anyway (which makes sense with a dial-up account), setting it up your to smart relay your mail trough your ISP's servers is quite simple.
OTOH, ECN is really a benefit for every user on the net, and we should make pressure on ISPs and network admins to properly configure/update their routers, otherwise it will be just a really nice thing dropped for laziness.
Don't worry about disposal. The nuclear material exists in nature now and we manage to live with it. There's no reason why we can't put it back with a level of safety equal to background radiation.
I'd rather be worried, because:
disposing it in a safe manner costs n
disposing it in a not-so-safe manner probably costs n - x
disposing it in an unsafe (and unlawful) manner surely costs n / x.
Of course, I'm talking about short-term costs.
Everyday you can hear of toxic dump being stored improperly or in abusive dumps, and now tell me how we can ensure the same won't happen with nuclear disposal, expecially when the number of subjects to be controlled is going up by an order or two of magnitude?
I know the alternatives (coal) sucks. But without a serious answer to the problem above (greed and short-sighted behaviour), this is going to suck even more.
If Python can parse it nonambiguosly, even a reindenter can do it (even if this means that the reindenter will have to know a lot more of Python's semantics as a C/C++/Java reindenter has to know), so it is definitively possible.
who says that his indentation style is 100% right
AFAIK, a block may start when the last nonblank character on a line is a ":", and a block (or more) ends at the first nonempty line which is less indented than the first line of the block. Python probably remembers the indentation of each opening line in a block, so it is able to deduce how many nested blocks it has to close. Simple and straight.
So there isn't really a style issue here, since the only rule is "indent blocks", and the only pourpouse a Python reindenter will accomplish would be changing the number of spaces used for indentation (i.e. from 8 to 4 or vice-versa), and the nice side effect is that the indentation always reflects the block structure (which is not necessarily true in C, C++, Java and other languages - having been mantaining several thousands of LOC written in these languages for years I can say that it's a PITA).
Of course, if you use an editor like Emacs with python-mode, editing Python sources requires no care at all.
BTW: if you use 2 spaces to indent because you have a lot of nested blocks, your code is probably broken or redundant and you should split it in simplier pieces.
Re:To whom? Re:Another Benefit of Free software.
on
Eazel On The Ropes
·
· Score: 1
So it is a benefit to whom?
Well, in theory is a benefit for users.
I'm saying "in theory" because this makes sense mainly for well-established products, or for products not directed to final users (i.e. cross-platform frameworks - it's not nice to have to refactor a product because the company providing the framework it is based on went under).
Personally I think that the "put Gnome on the desktop" meme is spreading at a lower rate than the one Eazel expected (after all, how long did it take to the "put Linux on your server" meme to spread?), which combined with the actual economic situation (in which big IT companies have to downsize themselves and little IT companies have troubles getting funding) is causing the problem here.
At least with/Perl/PHP/Java/Pascal*shudder*/Fortran you can run it through a formatter to get good formatted code
That's the point: since formatting has an effective impact on the interpretation of the code, coders are forced to Do It Right(TM), in a way that satisfies both the interpreter and an human eye. It's sad to enforce good habits, but unfortunately there are several coders out there not even knowing what the word "indent" means at all (not to mention the religion wars on where opening braces should be put - on the same line of the conditional/loop/declaration? On a line on themselves? Furtherly indented or not?).
Starting from this point, writing a reindenter for Python is not much harder than writing one for every other language.
I really see two main issues here:
printings on paper may be less readable (think of a piece of source spawing on several sheets: it's easier to measure indentation or to search for a closing mark? I don't know).
tab stops: in the *NIX world, tab stops are placed every 8 characters. End of discussion. In the Windows world (and perhaps others) there is the bad habit of "tab stop width of the day" (but it undoubtly IS a bad habit, since it makes sources unreadable for people not having the same settings on the editor - unless they are passed by a reindenter). Unfortunately, there is no way to enforce this (and perhaps this will cause some headaches to coders when hunting down the problem described in the last bug report...)
This is exactly the BSD spirit. You seems to like it. Fine.
OTOH, there are people saying "The more people (myself included) can contribute to a certain piece of code and all of its derivatives, the better", which is a different motivation, but equally valid.
Choose the licence that best represents your whishes.
Since you are clearly using bash as your shell, wich is a GNU shell, I'd say that sometimes that the choerence you are talking about has its execptions.
On the other hand, a UNICODE character is twice as large as an 8-bit one, so it does increase the code size somewhat
This is why UTF-8 exists and is used on most unices, and why I consider it a better solution than plain (untrasformed) UNICODE (or UCS-16, if you like).
Yes, and they realise, for instance that in English (and most European languages), a pen is still a pen, even if its at the start of a sentence, and is therefore spelt `Pen
OTOH, most european languages need also non-ascii characters, and saying "À is the capitalized version of à" is something that you can do only if you know what encoding has been used for the name of the file, and then we are still ignoring names in nonalphabetical languages with variable length encodings. Since some system calls require the name of a file as a parameter, this knowledge should be built in the kernel, with all the bloat it requires.
As you see, this is the sort of thing that better lives in userspace.
Slashdot Mirror
FYI, since Mozilla 0.8, there are prebuilt binaries for both HP-UX 10.20 and HP-UX 11. I know there have been some also for older milestones (M18, IIRC). They are made available some time after the Windows/Linux/Solaris releases.
Unfortunately, it seems you have to build and install GTK and the other libraries (i.e. libjpeg, libungif, libpng and friends) by yourself, which isn't exactly a painless process on HP-UX 10.20 (I don't know about 11, but it should be definitively simplier).
OTOH, if you really want it, IE 5 is available for HP-UX 10.20 (just search the microsoft site). At least it seems to work enough...
Well, looking at it from a pure technical point of view, it should be mostly a matter of "let's do a shell script that reads firewall rules from a configuration file", which every admin put in charge of configure the firewall should be able to do (IMHO).
On the human side I agree that life could be somewhat easier without the "firewall configuration scripts du jour" that the previous admin (or the previous guy who played as an admin on TV) left somewhere on the system and now it's your job to locate/check/mantain...
AFAIK (from reading the IPV6 docs), it's the current inefficient allocation of IPV4 networks/addresses that leads us to large routing tables.
....PCKeyboard (the ex keyboard division of IBM and Lexmark) makes an interesting product. Of course, you can attach an external pointing device too.
<IRONY> /IRONY >
It is flexible enough so several languages with other paradigms are implemented on it, it is cross platform in the sense that there are decent JVM for the main platforms, and making readable programs only requires disciplined programmers. Maintenance is easily done because everything is well documented with comments and on dead trees.
<
It is worth noting that it requires years for a coder to get the experience needed to be `disciplined'. Expecially, it requires lots of debugging other's code. Even you weren't born as a `disciplined' programmer, but you became disciplined like everyone else, day by day.
In the meanwhile, either the `still not disciplined coder' refrain itself from using languages requiring more discipline (which is a fancy way just to say that some languages are definitively not for beginners), or (s)he use the language anyway, with great headaches for the guy doing maintenance.
It's good for a language to be flexible, but trying to support all coding styles at once just for the sake of it is pure evil. That's why there are multiple languages out there.
I was talking about languages in general. All languages suck more or less from this point of view (this is why you have many of them - otherwise we'd be all using only the One True Language - which is not the case).
That said, i fear Perl is going in the direction of the creeping featurism that affected C++ some time ago, and IMHO it would be really a pity. Introducing constructs that to save a line or two affects how the code is interpreted 1200 lines below, and then saying "you should use them locally" adds to the list of things that an average developer could get wrong or overlook.
A language with an anal-retentive syntax is definitively not the answer, but nor is trying to support every conceivable programming style (in the sense of the amount of syntax sugar thrown in) in a single language.
So, to answer your question: it is definitively possible to write perfectly readable Perl, exactly in the same manner it is possible to write perfectly readable assembly or C. But people won't write readable code just because it's possible.
Uhm, that's a little bit narrow-minded IMHO. At least, you should throw in also the ability for people other than the original author to quickly understand what the code does, how it does it and change its behaviour according to the new requirements. Requirements usually aren't written in stone, and even if Perl allows you to be extremely quick at producing new working code from zero, having to almost refactor everything at every change request which can't be done by the original author doesn't sound too well to me.
You can say: "but there are comments for this! There is literate programming!", but in the end the final word is always said by code itself, not by the comments (do you expect all programmers to write meaningful and exahustive comments explaining the exact behaviour and side effects of a piece of code? I've given up expecting this some years ago...).
I may be wrong, of course, and honestly I hope I am. I recognize that Perl programmers have better things to do that writing code which is difficult to read, but I wouldn't like to have to say one day "Inside Perl there is a little nifty language..." as it has been said over and over for C++.
If this is going to be the case, expect a Language-X to Perl translator really soon, and Perl being relegated to be the new assembly language of the third millenium (btw, IIRC, this is one of Larry's proposals: using Perl as a cross-platform VM with translators on the top of it from several languages -- after all, this is the current trend).
Do you mean Glade plus libglade with the Python bindings in gnome-python?
Glade, other than generating C source for the GTK+ GUI you design, saves the file describing the GUI in an XML format which can be read via libglade. Then, it's only a matter of linking it in and calling a function which reads the XML file and builds the widget tree. The task of registering your handlers for the various events (i.e. a certain button pressed) can also be performed automatically by libglade, i.e. by looking at the executable symbol table for languages like C, or using the introspection features of the interpreter in the case of Python.
Mmmmh... I used to think so, but it's not always true. The current trend, as I can see, is that (at least for some managers) it is better having something quickly packed together and half working today with the promise of making it fully working tomorrow than having something well designed and fully working, but not before the next week. In other words, there are people out there thinking
- good code/design == works well == more time
- bad code/design == works enough == less time
- bad code/design now plus good code/design after == good code/design
which, unfortunately, is not true.So, while I'm agreeing with you, to some people it is not so evident that a coder should write good code...
BTW, Ghostscript already comes with an high quality replacement for standard Postscript fonts (the URW fonts), which can be readily used with XFree since they are common Adobe Type 1 (this is explained in better detail somewhere in the Font-deuglification-howto).
If I understood it correctly, a major TrueType feature that Adobe Type 1 fonts don't have is the presence of hints for rendering glyphs at small sizes (or low resolutions), but I doubt they can be used in a free TT font renderer, since there should be patents on them. But using the bitmapped versions for exact size matches and the vectorial versions in the other cases gives you the same result... and XFree allows you do to this automatically (again, follow the instructions within the URW fonts).
Putting every font file in a known place is going to leave unsolved a part of the problem, because this wont't work if you use a centralized X font server (and install noncommon fonts only on the machine running it). Here I'd really prefer an extension to the X Font Server protocol.
About fonts.alias: it isn't really needed at all, but it's there if you need it. fonts.dir OTOH is something we could easily get rid of, since all font files commonly used today already contain the needed information, but then, it's only a matter of running mkfontdir each time the X font server is started...
Yes, but you know: unmantained software rots. And who is better than the people who did the maintenance since yesterday to continue doing the maintenance (for a fee)?
IMHO, in some cases, it would be a great opportunity to start working for yourself, not for your boss. Of course, your boss won't agree...
Thank you, I didn't know.
Simple: it doesn't know when data is on the disk, because with common hardware you can't. Hard disks have their onboard (volatile) memory, and write operations report as completed when data reach the cache of the disk, which IIRC can't be controlled by software.
Someone once told me SGI has a smart disk controller backed up with a battery, so in the event of a blackout, the controller would keep for some hours the data still not written on the disk, flushing it on the disk on the next power up.
gs -dBATCH -sDEVICE=epswrite -sOutputFile=myfile.eps myfile.pdf
BTW, it can decode encrypted pdf too with a little modification. Just follow the (very simple) instructions printed when you try to read an encrypted .pdf for the first time...
Combined with pstoedit is a great tool
There you can find some links to other interpreters too.
Also, please note that using DUL generally does not block dial-up users: it forces them to use the ISP's server as a relay, as it should be. Unfortunately, it seems that there are troubles for some dial-up users to do so, and for the sake of them DUL has been dropped. But the vast majority is not affected at all.
Heck, if you want to use your local sendmail anyway (which makes sense with a dial-up account), setting it up your to smart relay your mail trough your ISP's servers is quite simple.
OTOH, ECN is really a benefit for every user on the net, and we should make pressure on ISPs and network admins to properly configure/update their routers, otherwise it will be just a really nice thing dropped for laziness.
I'd rather be worried, because:
- disposing it in a safe manner costs n
- disposing it in a not-so-safe manner probably costs n - x
- disposing it in an unsafe (and unlawful) manner surely costs n / x.
Of course, I'm talking about short-term costs. Everyday you can hear of toxic dump being stored improperly or in abusive dumps, and now tell me how we can ensure the same won't happen with nuclear disposal, expecially when the number of subjects to be controlled is going up by an order or two of magnitude?I know the alternatives (coal) sucks. But without a serious answer to the problem above (greed and short-sighted behaviour), this is going to suck even more.
FYI, for 2.2.x, you just have to put `nocheck' among the fs options in /etc/fstab.
If Python can parse it nonambiguosly, even a reindenter can do it (even if this means that the reindenter will have to know a lot more of Python's semantics as a C/C++/Java reindenter has to know), so it is definitively possible.
who says that his indentation style is 100% right
AFAIK, a block may start when the last nonblank character on a line is a ":", and a block (or more) ends at the first nonempty line which is less indented than the first line of the block. Python probably remembers the indentation of each opening line in a block, so it is able to deduce how many nested blocks it has to close. Simple and straight. So there isn't really a style issue here, since the only rule is "indent blocks", and the only pourpouse a Python reindenter will accomplish would be changing the number of spaces used for indentation (i.e. from 8 to 4 or vice-versa), and the nice side effect is that the indentation always reflects the block structure (which is not necessarily true in C, C++, Java and other languages - having been mantaining several thousands of LOC written in these languages for years I can say that it's a PITA).
Of course, if you use an editor like Emacs with python-mode, editing Python sources requires no care at all.
BTW: if you use 2 spaces to indent because you have a lot of nested blocks, your code is probably broken or redundant and you should split it in simplier pieces.
Well, in theory is a benefit for users.
I'm saying "in theory" because this makes sense mainly for well-established products, or for products not directed to final users (i.e. cross-platform frameworks - it's not nice to have to refactor a product because the company providing the framework it is based on went under).
Personally I think that the "put Gnome on the desktop" meme is spreading at a lower rate than the one Eazel expected (after all, how long did it take to the "put Linux on your server" meme to spread?), which combined with the actual economic situation (in which big IT companies have to downsize themselves and little IT companies have troubles getting funding) is causing the problem here.
That's the point: since formatting has an effective impact on the interpretation of the code, coders are forced to Do It Right(TM), in a way that satisfies both the interpreter and an human eye. It's sad to enforce good habits, but unfortunately there are several coders out there not even knowing what the word "indent" means at all (not to mention the religion wars on where opening braces should be put - on the same line of the conditional/loop/declaration? On a line on themselves? Furtherly indented or not?).
Starting from this point, writing a reindenter for Python is not much harder than writing one for every other language.
I really see two main issues here:
This is exactly the BSD spirit. You seems to like it. Fine.
OTOH, there are people saying "The more people (myself included) can contribute to a certain piece of code and all of its derivatives, the better", which is a different motivation, but equally valid.
Choose the licence that best represents your whishes.
Since you are clearly using bash as your shell, wich is a GNU shell, I'd say that sometimes that the choerence you are talking about has its execptions.
This is why UTF-8 exists and is used on most unices, and why I consider it a better solution than plain (untrasformed) UNICODE (or UCS-16, if you like).
See this page for further reference.
OTOH, most european languages need also non-ascii characters, and saying "À is the capitalized version of à" is something that you can do only if you know what encoding has been used for the name of the file, and then we are still ignoring names in nonalphabetical languages with variable length encodings. Since some system calls require the name of a file as a parameter, this knowledge should be built in the kernel, with all the bloat it requires.
As you see, this is the sort of thing that better lives in userspace.