However, PHP, even well-written PHP. will never be as fast as a well-written mod_perl handler, for the simple reason that mod_perl handlers are compiled once and live in memory for the life of the Apache server (parent) process.
Fixed in php4. Next?
You want to modify how the URI gets translated into a filename? You can't do that in PHP.
Yes, you can. I'm beginning to think you haven't used PHP.
You want to customize the authentication process? Nope, you can't do that in JSP.
That may be true in JSP (I haven't tried it), but in PHP it's a cakewalk (can you tell which side I'm taking?).
For anything other that generating output, you have to use either C or mod_perl.
I'm thinking you're smoking something. I consider socket communications, DB access, mailing, LDAP/SMB/PAM access, and the ability to run any executable in reach... a bit more powerful than just producing output. Don't know again about JSP (did I mention I don't use it?) but PHP can do these, and I'd grudgingly admit you can pull off the same tricks with ASP if you know where the right hooks are.
And the beauty of the whole thing is -- yup, you guessed it, it runs at memory speeds -- no filesystem accesses (unless you write them in specifically), no scripts to stat, no logic/HTML combination to parse.
This is a bit of a red-herring. Everything that doesn't need pre-processing will run at memory speed (or the closest approximation thereof since you ignore paging/swapping/etc. in your discussion, which is fine as we aren't holding an operating systems seminar here) as long as it has everything it needs. Talk to a database? Open a socket? Open a file? Run an outside script? The point about compilation is essentially dead-on (which is why the Zend engine for PHP is a Good Thing(tm)). If you're really pressed for time/memory however, right your own mod_* for Apache.
Most of this is merely for the sake of argument though -- I've been a Perl zealot for years. Now I do a lot of presentation in PHP, and save Perl for the heavy lifting. I optimize THE HELL out of my perl though, and use mod_perl when possible. I hate the thought of JSP (what an abortion) and so don't use it, and ASP is of course "right out".
And hence the immediate stream of replies from the green-haired/. crowd ensues to let us all know that any attempt at certification, any actual experience, or the actual effort at making one's self appear professional are not only unimportant but most likely a strike against the potential employee.
I went through so many hairstyles, fashions, music trends, the occasional piercing and tattoo that my family started referring to me as Rodman a number of years ago. However, I've been writing code for 16 years now. And I'm good. I'm good enough that now I also get to see the streams of applicants coming in and get to decide whom to hire and how to put together the teams.
Get this straight: If I get a group of "green-hair"s in, I'll hire the ones that can code, work together, and who won't steal from the company. If I get the GH's and some poindexter's, I'll hir the ones that can code, work together, and who won't steal from the company. If I get a group of poindexter's, I'll hire the ones that can code, work together, and who won't steal from the company.
Part of the problem in hiring is knowing whether or not the prospective (green haired or not) can code, work with others, and won't steal from the company. Your credentials, I'm afraid to say, are what get you in the door. [ If you know someone who can recommend you, that can get you in the door as well, but I really consider that a social credential more than a side-stepping of the system. ] If you've never done anything productive, you could very well be the best programmer in the world, but you've never worked on anything. This means (to me) that you probably don't know how to work with people, or how to pursue joint code development, or what deadlines are, or why tasks are prioritized, etc.
A degree, certification, or award, is an indication that you have completed some structured program designed to increase or test your assimilation of a body of knowledge. Are there people with the proper certifications who aren't qualified to work in this industry? Certainly. Are there people with the proper certifications who are able to work? Certainly. Are there people without those certifications who can do the work? Certainly.
So, certifications are worthless then. Bullshit. Like I said before, they are an indication of completion of a structured program. Given two applicants for one position whom I judge to be of equal capability, willing to work for the same pay, I'm generally going to hire the one with more certification -- primarily because I know that person is more likely to be able to work under deadlines and prioritized sets of goals.
Similarly, given a set of qualified applicants (can do the work, can work together, won't rob us blind, have the same relative qualifications) and too few positions, I will often favor the applicants who put the most effort into applying: well written resume/cover letter, well-dressed, punctual, polite, aggressive (no there's no contradiction there), excited, motivated, etc. These people are more likely to work hard, stay with the company, act on their own initiative, and so on.
The perceived tightness of the job market (and, actually, it's not quite as tight as has been made out) has brought to the average technophile an attitude that not only are they in high demand, but also that their intrinsic coolness, which derives from often dubious technical ability, is a substitute for proof of ability. Only one component of employability is technical competence, the other more important ones include social maturity, dependability, commitment, responsibility, ambition, and respect. Some will certainly whine that technical ability is the most important, but in this day (contrary to what many of you seem to believe) that's simple to find. If that's all you have, you lose out, because the next person in the door has the others too.
any suggestions? hm.... well, given that the US is going to soon be governed by either Gore or Bush, that's out (talk about a no-win situation); I hear Canada's nice -- if you don't mind the chill; and I *still* hear people talking about Singapore. Anyone else have any ideas?
Linux has at least two major vulnerabilities to viruses. The first doesn't affect Linux directly, but is still embarrasing. If you run Linux as a file server for Win32 machines, and a (usually macro) virus gets a decent foothold in the network, you rely on the Win32 virus checkers to fix it. But they can't (easily) clean it from the file server. The Linux boxes can quite happily continue serving infected files to clean Win32 boxes. Whoops. I believe that we need a native Linux virus checker built as close to the file system as you dare.
Maybe I'm misunderstanding you, but when I use Linux as a file server (Samba), and there is a virus which has infected files being served from the fileserver, I launch a scanner on the Windoze client's mounted network drive and it detects, cleans, disinfects just as if the drive were a Windoze drive. Windoze thinks the Linux share is a Windows network drive, scanner (Norton, NA, etc.) is perfectly willing to scan it, and viruses are detected and removed.
Of course the client doing the scanning has to have sufficient privilege to do the scanning and disinfecting, but I consider this a feature above and beyond what is allowed by NT. On my shares I generally use Linux file permissions to lock down binaries, so the luser who can munge his own files to his heart's content can read and run shared.exe's, but not write to them, even on the same share.
Go read about XPCOM. The bulk of the portable code for mozilla is c/c++. Use the right idioms, and the portable types, libraries, and factories, and your c/c++ is portable with Mozilla.
Agent CiXeL: your post violated some of our principle style guidelines for propaganda distribution. Please have future posts cleared through the Propaganda Directorate.
On 1, 2, and 4 I'll have to agree (for #1 a friend of mine just today did a search and came up with nothing particularly good). For #3 I'm completely confused with your claims that there is no groupware for Linux. I suppose we must be working from differing concepts of groupware. Essentially forums, mailing lists, web repositories, messaging, docbases, search integration, flexible access and updates, transparent referencing of information in different formats and the like are what I think of when I think of groupware. Exchange and Notes allow GUI clients for accessing some groupware facilities, but in my experience both of these put up arbitrary roadblocks in the way of the user trying to make good use of information resources. Groupware should make possible communication on many different levels between many different groups of people, reducing unnecessary communication, and creating a long-lasting accessible knowledge repository which can be processed with great flexibility. When I think of groupware generally the implementation language and tools are not the important part, it's how information enters the system, can be accessed, and how it can be manipulated. Generally Exchange and Notes based systems by themselves make this hard, but they can be a useful component in a good Groupware implementation. Heck, tin, lynx, and mutt can be very powerful as groupware interfaces as long as the docbase is powerful and easy to use.
It's not a Linux problem, not a *nix problem, not a hacker culture problem. It's a problem of trying to be an administrator without using the proper tools.
For instance, try out cfengine for a way to handle some of your distributed administration pains. As networks grow ad hoc administration becomes more and more difficult. If all you need is to keep your software in sync maybe you should try out Debian with dselect, apt-get, etc. If you need more rdist/rsync or even cfengine will give you more power. Perhaps you will end up at the point where you need to use Kerberos, NIS+, LDAP, etc. There is a long continuum between using a standalone machine and administering a large heterogenous network of systems. Sometimes it's hard to know when to apply new administration techniques -- and often even harder to know which techniques and tools to use (each time you go through the process you get more "experience" and become more qualified to actually administer systems). It sounds like you are at the point where you need to reevaluate your needs and decide on a more powerful scheme to administer your systems.
Just be glad you've got a Unix workalike at your disposal for administration purposes.
There needs to be a Linux standard that the distributions have to support.
No. The nature of the GPL is such that not only cannot you not enforce such a thing, the Free Software and/or the Open Source philosophies are fundamentally against this sort of restriction. While I agree it would be nice for something like the LSB to be widely adopted (and a given distribution could provide support for a configuration meeting LSB version such and such), the majority of current Linux users (particularly the ones who develop Linux, which is the important group when we discuss how Linux "should be") don't want to be constrained on their systems by some standard way that a configuration has to be. Enforce a mainstream configuration standard and developers will move to a non-mainstream distribution. Ironic maybe, but that's why many people use Linux in the first place.
While the goal of "Linux world domination" might be the rallying cry of some enamoured of Linux, I believe most people capable of making that goal a reality would rephrase it as "Linux world domination, so long as I can configure EVERYTHING the way I want it".
The interesting thing about this particular troll is that I think it might be a Bruce Perens comment generating Perl script. Dude - open the source, please!
copy and paste on *nix under X has always been a bit of a struggle (you might dig around on jwz's site for one of his rants on the matter) --although on win32 and mac I think this should be pretty much there; as for CRYPTO, well, it's coming (clearly); prefs have been updated greatly and window size persistence is fixed now; as for Java issues: ya got me -- I have no idea.
Following recent news that Intel is providing mechanisms to provide encoding support all the way to the display device, and recent maneuvers by content conglomerates, perhaps USB support for such ``copy-proof'' displays is being developed. It would be better to keep such work away from the eyes of the average Open Source developer.
I do not scoff design time. Design time is the most important phase of development. Doubling design time because of the choice of pointlessly rigid implementation language is however ridiculous.
One number: $769. What, do you work for Adobe? A word processor (sorry, I don't care how much "layout" it does it's still a word processor) for 5 times the cost of Windows? No thanks. I could buy a 21" monitor and a stick of 128Mb RAM for that. Hell, I could hire migrant workers to write my documents with calligraphy pens (for a couple of years if I'm willing to go offshore). My previous car didn't cost that much!
I think the light was in the emergency room after you went into shock from the price tag.
Yeah, wiseass, I've heard of implements, and delegation, abstract base classes and factories, and design patterns, and UML, and all the other supposed means to get around Java's problems. Fact is, Java has them, and for any large scale project overall implementation time is increased over other common procedural and/or OO languages due to the fact that the design phase of a large project is longer than for other languages (due to the narrow ways that you are allowed to express designs in code). All that for a not-quite-portable slow language?
No, dillwad AC loser, we are using XUL and writing our own XPCOM components using NSPR, and delivering our "content" along with integration to our network services (almost hard to explain without showing the product). We are tracking the changes in Mozilla and the product works better now than it could work with any extant Java system (particularly when WORA practicality is a factor). The product won't be available for another couple of months, but we are already in testing.
3.Get rid of the UNIX model. Yeah, no more user IDs, passwords or any of that. It can be too confusing on your grandma to have more names and numbers to remember.
4.Get rid of GNU. Yeah, that's right, drop the command line utilities that you know and love, and lose all that power. If granny can't remember her password how's she supposed to remember arcane commands?
5.The gui must be the OS. This means, goodbye X. Most of the newbies who ask me for help request help with setting up X (well, networking comes close). X must disappear, or it must become so much a part of Linux that it's just there, and it just works, no matter what video card, RAMDac, or whatever the user has on their machine.
Sounds like an "updated" version of windows or a working OS X to me.
While that's what you may want, or you may want for the unwashed masses, I won't be using it (and neither will hundreds of thousands of other people who are the core of the Linux community). Some of us choose to use Linux for more than just the ideological reasons. Removing the ability to get under the hood and manipulate the system removes a very big reason for using Linux.
Removing the user and permissioning model may make it easy for grandma to use, but it also reverts to the "useful only as an appliance" paradigm. If there is only one user then that user can do anything to the system (which is why "try reinstalling windows" is the most common final tech support answer), and if you restrict the capabilities of the user to damage the system you then create an appliance/toy that is of little use to most of us.
Part of the problem with "the gui is the OS" is that in nearly every implementation I've ever seen, if the GUI has a problem you're left high and dry with no way to fix the problem -- because the GUI, which *is* the OS, is hosed.
I would venture to say that you don't "get" Linux (or any UNIX or Unix-workalike).
Wes, I'm glad to see you say this (as someone who has been supportive of Java in general) -- I've personally been burned by this to the point of using Mozilla for portable deployment: even with changing API's and alpha-level code Mozilla is more "write once run anywhere" than Java for desktop apps. Of course, few people take me seriously when I say this, but then again, we are able to deploy now thanks to Mozilla, where we *still* wouldn't be able to if we had stayed with Java.
work seems to be dreadfully slow or the game seems to be dreadfully slow:-) they probably got tangled in the no-multiple inheritance mess that is java OO and had to flip their code inside out to get what they wanted (can you tell I'm bitter), but seriously, I would like to see more java games so I could crank them up on the Sun and the Alpha and the p3's and have a real in-house fragfest.
Well, you can check my number too:-) But I agree with the observations you've made. At threshold==1 the main page shows an obscene difference between the posts at my threshold and the total posts. This is a pretty recent phenomenon (on the order "42 of 328 posts" -- this wasn't happening even two weeks ago) in a sense, but has been coming on for quite some time now. I guess it's always September on/., but some change in the moderation or posting system is definitely in order. Just my opinion.
Their are two major security advantages to OpenBSD and you have hit upon one of them, namely that it ships in a "secure by default" state. Linux can be tightened down to the same state (no unnecessary services, verbose logging, tighten file permissions, apply all known patches, etc.).
The other is not so obvious, but even more important: the source distributed with OpenBSD has undergone an extensive (years long) line by line security audit. Bugs that were fixed in OpenBSD two years ago and posted to various advisories lists are still turning up in Linux (and Free/NetBSD, and even proprietary Unix variants) to this day.
In addition, even given that a Linux distribution which has been audited to the degree that OpenBSD has (btw, there isn't one) is shipped in a secure-by-default (which I don't know of either...) state, this does not imply security. Security is a process which transcends a particular software installation (as the thousands of dumpster-diving and social engineering tales make clear).
There is a tradeoff, however, between security and usability. Most Linux newbies (or anything else newbies for that matter) don't want to be told that they have to reconfigure 10 security settings to easily reset the permissions on their sound card. People run X as root. People, for some reason, like to run anonymous ftp servers. And so on. The distro that strikes a balance between ease of use and default security will go a long way towards widespread adoption.
It has been stated before in this forum and others that the last coherent thought Bob Metcalfe had was when he helped design ethernet (a technology which would have come about in much the same way regardless of who announced it first). He has been riding that wave to spew incoherent babble for years, and is basically an annoyance to the Thinking Reader. Yet another gem in Metcalfe's crown of idiocy.
Slashdot Mirror
Fixed in php4. Next?
You want to modify how the URI gets translated into a filename? You can't do that in PHP.
Yes, you can. I'm beginning to think you haven't used PHP.
You want to customize the authentication process? Nope, you can't do that in JSP.
That may be true in JSP (I haven't tried it), but in PHP it's a cakewalk (can you tell which side I'm taking?).
For anything other that generating output, you have to use either C or mod_perl.
I'm thinking you're smoking something. I consider socket communications, DB access, mailing, LDAP/SMB/PAM access, and the ability to run any executable in reach... a bit more powerful than just producing output. Don't know again about JSP (did I mention I don't use it?) but PHP can do these, and I'd grudgingly admit you can pull off the same tricks with ASP if you know where the right hooks are.
And the beauty of the whole thing is -- yup, you guessed it, it runs at memory speeds -- no filesystem accesses (unless you write them in specifically), no scripts to stat, no logic/HTML combination to parse.
This is a bit of a red-herring. Everything that doesn't need pre-processing will run at memory speed (or the closest approximation thereof since you ignore paging/swapping/etc. in your discussion, which is fine as we aren't holding an operating systems seminar here) as long as it has everything it needs. Talk to a database? Open a socket? Open a file? Run an outside script? The point about compilation is essentially dead-on (which is why the Zend engine for PHP is a Good Thing(tm)). If you're really pressed for time/memory however, right your own mod_* for Apache.
Most of this is merely for the sake of argument though -- I've been a Perl zealot for years. Now I do a lot of presentation in PHP, and save Perl for the heavy lifting. I optimize THE HELL out of my perl though, and use mod_perl when possible. I hate the thought of JSP (what an abortion) and so don't use it, and ASP is of course "right out".
I thought it was just because the code was poorly written. Have you looked at it? :-)
I went through so many hairstyles, fashions, music trends, the occasional piercing and tattoo that my family started referring to me as Rodman a number of years ago. However, I've been writing code for 16 years now. And I'm good. I'm good enough that now I also get to see the streams of applicants coming in and get to decide whom to hire and how to put together the teams.
Get this straight:
If I get a group of "green-hair"s in, I'll hire the ones that can code, work together, and who won't steal from the company.
If I get the GH's and some poindexter's, I'll hir the ones that can code, work together, and who won't steal from the company.
If I get a group of poindexter's, I'll hire the ones that can code, work together, and who won't steal from the company.
Part of the problem in hiring is knowing whether or not the prospective (green haired or not) can code, work with others, and won't steal from the company. Your credentials, I'm afraid to say, are what get you in the door. [ If you know someone who can recommend you, that can get you in the door as well, but I really consider that a social credential more than a side-stepping of the system. ] If you've never done anything productive, you could very well be the best programmer in the world, but you've never worked on anything. This means (to me) that you probably don't know how to work with people, or how to pursue joint code development, or what deadlines are, or why tasks are prioritized, etc.
A degree, certification, or award, is an indication that you have completed some structured program designed to increase or test your assimilation of a body of knowledge. Are there people with the proper certifications who aren't qualified to work in this industry? Certainly. Are there people with the proper certifications who are able to work? Certainly. Are there people without those certifications who can do the work? Certainly.
So, certifications are worthless then. Bullshit. Like I said before, they are an indication of completion of a structured program. Given two applicants for one position whom I judge to be of equal capability, willing to work for the same pay, I'm generally going to hire the one with more certification -- primarily because I know that person is more likely to be able to work under deadlines and prioritized sets of goals.
Similarly, given a set of qualified applicants (can do the work, can work together, won't rob us blind, have the same relative qualifications) and too few positions, I will often favor the applicants who put the most effort into applying: well written resume/cover letter, well-dressed, punctual, polite, aggressive (no there's no contradiction there), excited, motivated, etc. These people are more likely to work hard, stay with the company, act on their own initiative, and so on.
The perceived tightness of the job market (and, actually, it's not quite as tight as has been made out) has brought to the average technophile an attitude that not only are they in high demand, but also that their intrinsic coolness, which derives from often dubious technical ability, is a substitute for proof of ability. Only one component of employability is technical competence, the other more important ones include social maturity, dependability, commitment, responsibility, ambition, and respect. Some will certainly whine that technical ability is the most important, but in this day (contrary to what many of you seem to believe) that's simple to find. If that's all you have, you lose out, because the next person in the door has the others too.
hm.... well, given that the US is going to soon be governed by either Gore or Bush, that's out (talk about a no-win situation); I hear Canada's nice -- if you don't mind the chill; and I *still* hear people talking about Singapore. Anyone else have any ideas?
Maybe I'm misunderstanding you, but when I use Linux as a file server (Samba), and there is a virus which has infected files being served from the fileserver, I launch a scanner on the Windoze client's mounted network drive and it detects, cleans, disinfects just as if the drive were a Windoze drive. Windoze thinks the Linux share is a Windows network drive, scanner (Norton, NA, etc.) is perfectly willing to scan it, and viruses are detected and removed.
Of course the client doing the scanning has to have sufficient privilege to do the scanning and disinfecting, but I consider this a feature above and beyond what is allowed by NT. On my shares I generally use Linux file permissions to lock down binaries, so the luser who can munge his own files to his heart's content can read and run shared .exe's, but not write to them, even on the same share.
Go read about XPCOM. The bulk of the portable code for mozilla is c/c++. Use the right idioms, and the portable types, libraries, and factories, and your c/c++ is portable with Mozilla.
"Troll", not "DumbMarketingGuy".
For instance, try out cfengine for a way to handle some of your distributed administration pains. As networks grow ad hoc administration becomes more and more difficult. If all you need is to keep your software in sync maybe you should try out Debian with dselect, apt-get, etc. If you need more rdist/rsync or even cfengine will give you more power. Perhaps you will end up at the point where you need to use Kerberos, NIS+, LDAP, etc. There is a long continuum between using a standalone machine and administering a large heterogenous network of systems. Sometimes it's hard to know when to apply new administration techniques -- and often even harder to know which techniques and tools to use (each time you go through the process you get more "experience" and become more qualified to actually administer systems). It sounds like you are at the point where you need to reevaluate your needs and decide on a more powerful scheme to administer your systems.
Just be glad you've got a Unix workalike at your disposal for administration purposes.
No. The nature of the GPL is such that not only cannot you not enforce such a thing, the Free Software and/or the Open Source philosophies are fundamentally against this sort of restriction. While I agree it would be nice for something like the LSB to be widely adopted (and a given distribution could provide support for a configuration meeting LSB version such and such), the majority of current Linux users (particularly the ones who develop Linux, which is the important group when we discuss how Linux "should be") don't want to be constrained on their systems by some standard way that a configuration has to be. Enforce a mainstream configuration standard and developers will move to a non-mainstream distribution. Ironic maybe, but that's why many people use Linux in the first place.
While the goal of "Linux world domination" might be the rallying cry of some enamoured of Linux, I believe most people capable of making that goal a reality would rephrase it as "Linux world domination, so long as I can configure EVERYTHING the way I want it".
Just my conspiracy theorist notion.
I do not scoff design time. Design time is the most important phase of development. Doubling design time because of the choice of pointlessly rigid implementation language is however ridiculous.
I think the light was in the emergency room after you went into shock from the price tag.
4.Get rid of GNU. Yeah, that's right, drop the command line utilities that you know and love, and lose all that power. If granny can't remember her password how's she supposed to remember arcane commands?
5.The gui must be the OS. This means, goodbye X. Most of the newbies who ask me for help request help with setting up X (well, networking comes close). X must disappear, or it must become so much a part of Linux that it's just there, and it just works, no matter what video card, RAMDac, or whatever the user has on their machine.
Sounds like an "updated" version of windows or a working OS X to me.
While that's what you may want, or you may want for the unwashed masses, I won't be using it (and neither will hundreds of thousands of other people who are the core of the Linux community). Some of us choose to use Linux for more than just the ideological reasons. Removing the ability to get under the hood and manipulate the system removes a very big reason for using Linux.
Removing the user and permissioning model may make it easy for grandma to use, but it also reverts to the "useful only as an appliance" paradigm. If there is only one user then that user can do anything to the system (which is why "try reinstalling windows" is the most common final tech support answer), and if you restrict the capabilities of the user to damage the system you then create an appliance/toy that is of little use to most of us.
Part of the problem with "the gui is the OS" is that in nearly every implementation I've ever seen, if the GUI has a problem you're left high and dry with no way to fix the problem -- because the GUI, which *is* the OS, is hosed.
I would venture to say that you don't "get" Linux (or any UNIX or Unix-workalike).
work seems to be dreadfully slow or the game seems to be dreadfully slow :-) they probably got tangled in the no-multiple inheritance mess that is java OO and had to flip their code inside out to get what they wanted (can you tell I'm bitter), but seriously, I would like to see more java games so I could crank them up on the Sun and the Alpha and the p3's and have a real in-house fragfest.
The other is not so obvious, but even more important: the source distributed with OpenBSD has undergone an extensive (years long) line by line security audit. Bugs that were fixed in OpenBSD two years ago and posted to various advisories lists are still turning up in Linux (and Free/NetBSD, and even proprietary Unix variants) to this day.
In addition, even given that a Linux distribution which has been audited to the degree that OpenBSD has (btw, there isn't one) is shipped in a secure-by-default (which I don't know of either...) state, this does not imply security. Security is a process which transcends a particular software installation (as the thousands of dumpster-diving and social engineering tales make clear).
There is a tradeoff, however, between security and usability. Most Linux newbies (or anything else newbies for that matter) don't want to be told that they have to reconfigure 10 security settings to easily reset the permissions on their sound card. People run X as root. People, for some reason, like to run anonymous ftp servers. And so on. The distro that strikes a balance between ease of use and default security will go a long way towards widespread adoption.