PHP is simple and easy to learn (it appears; I'm
still in that phase). mod_perl is WAY more mature.
Basicly, PHP has a very crude language (I mean, OO without object destructors? get real!) The manual is skimpy. No barewords:-( No distinction between arrays and hashes. No anonymous structures.
My feeling is that for fairly small things PHP is
the go, for complexity or nontrivial things Perl is a far superior choice. (BTW, shopping carts and product catalogues fall into the former category - they're apparently perfectly tractable in PHP.)
Of course. And yea, probably only in NY.
And better still, only against 2600 and "those actual in concert with it" (possible misquote),
though that's an wonderfully vague description.
X had a few design criteria, including: - support all sorts of weird frame buffers (video RAM was once very expensive) - not prescribe policy
Let me address this last one: the reason you see a plethora of window managers is _because_ there's a plethora of GUI preferences out there. Every time I see phrases like "standard GUI" I cringe in fear. This is the path to user entrapment. To take an example, I don't have _any_ window borders or title bars on my desktop; they waste space and are an inefficient way to manipulate windows anyway. Only under X have I this flexibility.
X is good. It's bloated, and the graphics model shows some age (not alpha, etc, as you remark), but it gets some things more right than many other platforms: it leaves policy in the hands of the user (via _many_ very different, very configurable wm choices) and it separates the app from the wm and rendering system. That division is a damn fine thing.
What would I have "fixed" in X?
I'd have an "emulation" facility to let lazy apps request one of a very small number of basic graphics modes (1 bit deep, 8 or 16-bit mapped colour, 16 or 24-bit true colour) and let the server handle transcription to the video hardware. As it is, several apps don't cope well with less common graphics models.
If they win, it affirms their "firm stance" against hackers. It provides an appearance of vigilence in protecting their "trade secret". It promulgates the atmosphere of fear that any reverse enginieer will endure.
One of the things that really disturbs me about all this (and not just this, this has been bugging me about the corporate world for quite a while) is that many people seem to view their jobs as "check you conscience at the door". I've had several people remark to me (in the course of doing something for work) "my job is X", where X often maps very closely to "maximise the profits for the company regardless of method". How many software engineers loathe software patents but churn them out as part of their job? Like situations exist in many places. I though "I was just following orders" was a discredited idea these days. How many companies feel their duty to the stockholders vis a vis sheer profit is the guiding light of their actions? Trademark lore _requires_ trademark owners to pursue any potential infringement with the evils of legal threat lest they lose their trademark. Like provisions exist for trade secrets (hence the DVD CCA's need to display vigilence, however misguided). These provisions are _actively_ bad for polite cooperation and free flow of information and technology.
Behold the farce touted as a representative government.
Think about this: you see all these stories in the press: "Austalia backpedals on Kyoto Accord" or "US mulls CDA". It's not _us_, it's the scum who've got into power (because most of us would rather do something useful, so the papershufflers with power cravings percolate to the top).
The ABA are just one facet of a whole system symptomatic of those portions of the society which want everyone else brought down to their level.
My primary concerns about this crap are that (a) the privacy implications because to check _every_ id they must reveal who's doing what to a central system (b) the checks are _more_ intrusive than apply at, say, an R-rated movie (where generally you must show some id if you're not obviously "old") - if you're obviously "old" no id is needed and thus no intrusion is performed at all and (c) the crippling effect this will have on web indexers, which now can no longer index a lot of useful material.
When you're parsing $DISPLAY, are you looking for an IP address? NO! You're looking for: ip-addr:n[.n] So you rip of the right hand display[.screen] spec _first_, then hand the left hand side to your ascii2address routine.
Of course it matters. RSA is a perfect fine algorithm. Lots of folks have RSA keys. GPG's disdain for RSA because of the patent is a major pain in the arse to a lot of us. It basicly renders it useless if we're dealing with someone with an RSA key.
Of course we want RSA if the patent encumbrances lapse!
This all came up about 2 months ago. Much "new force" and "new fangled gravity theories needed" abounded. As I recall the discrepancies were resolved without resorting the such stuff. Dig around on space news and the like for the articles.
Look, XML is great for moving info between apps; nice nested tagged data, easy to parse.
But DO NOT replace the common config files with XMLised goop! Many of use use plain text editors to control configs, or many and varied simple tools to batch edit them. This is very easy with the common line-oriented configs. Moving to XML will: (a) break every automatic script out there, (b) piss off everyone who hand edits these files.
Plain text configs are a BIG WIN.
Maybe for complex configs with weird nested data structures this might be an ok idea, but even then I'd go for something terser than XML (even the broken XML-with-short-closing-tags is too verbose).
I've a little script called "ring" I use to look up phone lists. For passwords I just have a pgp encrypted file; I decrypt it and pipe it through ring to find the password I need for whatever obscure site I need to visit. I have a few shell aliases for storing (unexported) the passphrase for this file in my shell and for passing it to pgp for the pgp->ring lookup. Works just find. So I just make random passwords for sites and note 'em down. (md5 on an active log file is a handy way to get arbitrary strings for passwords).
Horms is the mail dude for ZipWorld, one of the larger Asutralian ISPs. They run Linux internally and he presented a paper at CALU on building a large and scalable mail system. See:
"Open Telstra's lines to the others and we all win!"
Well... Yes, it means the competition doesn't have to lay their own infrastructure. Less waste.
But... Telstra laid this infrastructure. It's big. Very expensive. They have to maintain it. They need to recoup both their investment in the first place and their ongoing maintenance costs. Yet the regulatory authority tends to mandate cheap end user cost and unprohibitive access costs to the competition. I know if I were Telstra I'd be damn pissed about this situation.
1: Ssh1 is not that expensive, just ssh2. 2: You don't need the server stuff on your 1000 hosts, just on the central one. Just have the clients pull the files from the server (eg from a cron job, like we do here). 3: Use rsync instead of rdist - it's much better.
Firstly, this is not new. Secondly, this patent should fail the "nonobvious" test - such an approach is obvious to anyone in the networking field. Like many patents, this is a classic example of the ease with which the PTOs of many countries are abused. Any competent patent lawyer can probably invalidate the original patent by citing prior art and by getting a few expert witnesses to say this patent is an obvious application of well known principles of load distribution.
Slashdot Mirror
Basicly, PHP has a very crude language (I mean, OO without object destructors? get real!) The manual is skimpy. No barewords :-( No distinction between arrays and hashes. No anonymous structures.
My feeling is that for fairly small things PHP is the go, for complexity or nontrivial things Perl is a far superior choice. (BTW, shopping carts and product catalogues fall into the former category - they're apparently perfectly tractable in PHP.)
Of course. And yea, probably only in NY.
And better still, only against 2600 and "those actual in concert with it" (possible misquote),
though that's an wonderfully vague description.
X had a few design criteria, including:
- support all sorts of weird frame buffers
(video RAM was once very expensive)
- not prescribe policy
Let me address this last one: the reason you see a plethora of window managers is _because_ there's a plethora of GUI preferences out there. Every time I see phrases like "standard GUI" I cringe in fear. This is the path to user entrapment. To take an example, I don't have _any_ window borders or title bars on my desktop; they waste space and are an inefficient way to manipulate windows anyway. Only under X have I this flexibility.
X is good. It's bloated, and the graphics model shows some age (not alpha, etc, as you remark), but it gets some things more right than many other platforms: it leaves policy in the hands of the user (via _many_ very different, very configurable wm choices) and it separates the app from the wm and rendering system. That division is a damn fine thing.
What would I have "fixed" in X?
I'd have an "emulation" facility to let lazy apps request one of a very small number of basic graphics modes (1 bit deep, 8 or 16-bit mapped colour, 16 or 24-bit true colour) and let the server handle transcription to the video hardware.
As it is, several apps don't cope well with less common graphics models.
> what does prosecuting him do for these people?
If they win, it affirms their "firm stance" against hackers. It provides an appearance of vigilence in protecting their "trade secret". It promulgates the atmosphere of fear that any reverse enginieer will endure.
One of the things that really disturbs me about all this (and not just this, this has been bugging me about the corporate world for quite a while) is that many people seem to view their jobs as "check you conscience at the door". I've had several people remark to me (in the course of doing something for work) "my job is X", where X often maps very closely to "maximise the profits for the company regardless of method". How many software engineers loathe software patents but churn them out as part of their job? Like situations exist in many places. I though "I was just following orders" was a discredited idea these days. How many companies feel their duty to the stockholders vis a vis sheer profit is the guiding light of their actions? Trademark lore _requires_ trademark owners to pursue any potential infringement with the evils of legal threat lest they lose their trademark. Like provisions exist for trade secrets (hence the DVD CCA's need to display vigilence, however misguided). These provisions are _actively_ bad for polite cooperation and free flow of information and technology.
It depresses the hell out of me.
Behold the farce touted as a representative government.
Think about this: you see all these stories in the press: "Austalia backpedals on Kyoto Accord" or "US mulls CDA". It's not _us_, it's the scum who've got into power (because most of us would rather do something useful, so the papershufflers with power cravings percolate to the top).
The ABA are just one facet of a whole system symptomatic of those portions of the society which want everyone else brought down to their level.
My primary concerns about this crap are that (a) the privacy implications because to check _every_ id they must reveal who's doing what to a central system (b) the checks are _more_ intrusive than apply at, say, an R-rated movie (where generally you must show some id if you're not obviously "old") - if you're obviously "old" no id is needed and thus no intrusion is performed at all and (c) the crippling effect this will have on web indexers, which now can no longer index a lot of useful material.
When you're parsing $DISPLAY, are you looking
for an IP address? NO! You're looking for:
ip-addr:n[.n]
So you rip of the right hand display[.screen]
spec _first_, then hand the left hand side to your
ascii2address routine.
Of course it matters.
RSA is a perfect fine algorithm.
Lots of folks have RSA keys. GPG's disdain for RSA
because of the patent is a major pain in the arse
to a lot of us. It basicly renders it useless if
we're dealing with someone with an RSA key.
Of course we want RSA if the patent encumbrances lapse!
This all came up about 2 months ago.
Much "new force" and "new fangled gravity theories needed" abounded. As I recall the discrepancies were resolved without resorting the such stuff.
Dig around on space news and the like for the articles.
Look, XML is great for moving info between apps;
nice nested tagged data, easy to parse.
But DO NOT replace the common config files with XMLised
goop! Many of use use plain text editors to
control configs, or many and varied simple tools
to batch edit them. This is very easy with the common line-oriented configs.
Moving to XML will: (a) break every automatic script out there, (b) piss off everyone who hand edits these files.
Plain text configs are a BIG WIN.
Maybe for complex configs with weird nested data structures this might be an ok idea, but even then I'd
go for something terser than XML (even the broken XML-with-short-closing-tags is too verbose).
Our Govt granted ASIO this right, warrantless I think, this year. They aren't your police-at-large
but the whole attitude is vile.
I've a little script called "ring" I use to look up phone lists. For passwords I just have a pgp encrypted file; I decrypt it and pipe it through ring to find the password I need for whatever obscure site I need to visit. I have a few shell aliases for storing (unexported) the passphrase for this file in my shell and for passing it to pgp for the pgp->ring lookup. Works just find.
So I just make random passwords for sites and note 'em down. (md5 on an active log file is a handy way to get arbitrary strings for passwords).
Horms is the mail dude for ZipWorld, one of the
e rs/horms/
larger Asutralian ISPs. They run Linux internally
and he presented a paper at CALU on building a
large and scalable mail system.
See:
http://www.linux.org.au/projects/calu/cdrom/pap
for the conference paper.
"Open Telstra's lines to the others and we all win!"
Well... Yes, it means the competition doesn't
have to lay their own infrastructure. Less waste.
But... Telstra laid this infrastructure. It's big.
Very expensive. They have to maintain it. They need to recoup both their investment in the first place
and their ongoing maintenance costs. Yet the regulatory authority tends to mandate cheap end user cost and unprohibitive access costs to the competition. I know if I were Telstra I'd be damn pissed about this situation.
Also "Forever Peace" by Joe Haldeman.
1: Ssh1 is not that expensive, just ssh2.
2: You don't need the server stuff on your 1000
hosts, just on the central one. Just have the
clients pull the files from the server (eg from
a cron job, like we do here).
3: Use rsync instead of rdist - it's much better.
Firstly, this is not new.
Secondly, this patent should fail the "nonobvious"
test - such an approach is obvious to anyone in
the networking field. Like many patents, this is
a classic example of the ease with which the PTOs
of many countries are abused.
Any competent patent lawyer can probably invalidate the original patent by citing prior art and by getting a few expert witnesses to say this
patent is an obvious application of well known
principles of load distribution.
Go see http://www.jcam.com/
A Linux version exists, and they say the A5 support is due Real Soon Now. Prod them - it may be ready!