If WindowMaker is the only thing going, then defacto it is the standard.
Additionally, my understanding is that the applications, such as the workplace manager, are GNUstep applications. What functionality is missing when I run it under WindowMaker?
Logically, something would have to implement the GNUstep framework, in order for GNUstep applications to run - I don't see how you would build a GNUstep GNUstep emulator, as a result.
His program was sending malformed HTML. Logically, you could collect the 'failures' and do correlation on what you found - hence his estimation of some of the problems being related to specific C library functions and their misuse (calloc, strlen etc...).
This is a good thing, because the developers of the browsers in question will now be able to refactor their code to handle error conditions properly.
On the other hand, while IE may have passed this 2 hour (his admition) test - that is certainly not definitive proof because there are too many unknowns (did the tests go through every HTML construct in all possible permutations? I am guessing not). Given the subset of potential malformed HTML thrown at these systems - yes IE won. Is that the final word on this? No, MicroSoft has a long history of poor software security that we can't simply sweep under the rug. Without the source, barring a complete test that covers all possible permutations, we will never be able to validate that assumption.
At any rate, yes GNUstep is the framework that WindowMaker and its tools are built on to be completely accurate.
For all intents and purposes, GNUstep is a free implementation of the NEXTstep specification, which underpins every native WindowMaker application. However, WindowMaker also allows you to run other X11 (XFree86 and its successor) applications as well.
So I was right - depending upon what your definition of 'is' is.
This also points to an interesting aspect: companies are short sighted - and only focus on the current year's revenue at the expense of long range planning.
Rather than create a longterm situation where large sums of money could have been made satisfying the customers, they chose the short term solution of 'lets make money now - screw the customer'. Imagine the tools we would have today if it had gone the other way.
IBM is atoning for its early blunder by supporting Linux and OpenSource - as long as it is profitable for them, of course.
I thank the Almighty (whatever, he, she or it may, or may not be) every day for Linux and the choice not to use Microsoft software.
Hypersonic Ramjet technology would be able to use the atmosphere to compress a fuel/air mixture for produce thrust into near earth orbit. You wouldn't have to take as much fuel - which would increase your payload potential.
I have two U.S. Army issue rucksacks - one small and one large with a metal frame that fits both - both of which have a pouch at the top for mounting one of the old PRC box-style radios. This pouch is sufficient size to hold a laptop, and you have the added storage to cover your other travel gear as required. Open the cover flap, and release a strap - and the computer is in your hands. The computer is closest to your back - and with a full pack, would be surrounded on the outside by other things.
These systems are tough - and having them for over 10 years now, they appear to be brand new.
Because Sun has the deepest pockets. Who else will they sue for OpenOffice? The developers, most of who make much less than the cost of pursuing such a case?
Finally, Microsoft would lose for many reasons (prior art, fundamental differences between the implementations etc...)
Purpose/usr is the second major section of the filesystem./usr is shareable, read-only data. That means that/usr should be shareable between various FHS-compliant hosts and must not be written to. Any information that is host-specific or varies with time is stored elsewhere.
Large software packages must not use a direct subdirectory under the/usr hierarchy. Requirements
The following directories, or symbolic links to directories, are required in/usr.
Directory Description bin Most user commands include Header files included by C programs lib Libraries local Local hierarchy (empty after main installation) [my emphasis] sbin Non-vital system binaries share Architecture-independent data
...
/usr/local : Local hierarchy
Purpose
The/usr/local hierarchy is for use by the system administrator when installing software locally. It needs to be safe from being overwritten when the system software is updated. It may be used for programs and data that are shareable amongst a group of hosts, but not found in/usr.
Locally installed software must be placed within/usr/local rather than/usr unless it is being installed to replace or upgrade software in/usr.
So,/usr/bin would be where the distribution deposits user commands, or a package updates said commands, whereas/usr/local/bin is left for the administrator(you) to put additional software added after installation that is not part of the regular distribution.
As for/opt:
/opt : Add-on application software packages
Purpose/opt is reserved for the installation of add-on application software packages.
A package to be installed in/opt must locate its static files in a separate/opt/ or/opt/ directory tree, where is a name that describes the software package and is the provider's LANANA registered name.
So,/opt is used for add-on packages whereas/user/local would be the target for the output of such packages - if not part of a regular distribution; as mentioned above, if the package updates an existing part of the distribution in/usr, then it can put it in the normal location (instead of/usr/local). This is why you have to be careful to grab the package from the same distribution - because, by definition, certain assumptions are being made by the distributors that may be different from that of another. This is also good - because it allows wiggle room for a distribution to extend the directory structure.
As a matter of policy, I install all non-distribution packages/builds into/usr/local. This avoids any conflicts, and makes backing up and restoring my stuff easy (tar -cvf usrlocal.tar/usr/local) - not to mention, I know where to look when there is a problem with an app. System upgrading and restoration is as easy as sftp'ing that tarball to another machine, then loading the new OS, and restoring the tarball.
Finally, the Linux Standard Base is an attempt to close the doors on areas of paticular contention. The LSB states, among other things:
An LSB conforming implementation shall provide the mandatory portions of the filesystem hierarchy specified in the Filesystem Hierarchy Standard (FHS) 2.3 (FHS), together with any additional requirements made in this specification.
On the one hand pressure exerted by management rolls off like water on a duck's back. I spent 4 years in the AirForce, and 7 years in the Army (11B, 19D) - so someone telling me nicely that they are piling on yet another project to my already overloaded schedule, or that they are moving my due date up 2 weeks, or that they disagree with how I intend to implement this software, is nothing in comparison to having a bunch of armed men around who can inflict bodily harm, or death at any moment, who are looking to you for guidance.
On the other hand, the pressure that really gets me is when I don't live up to my own expectations and I slip a deadline that I have committed to. This rarely occurs - but when it does, it raises my bloodpressure, and I lose my composure. I equate some of this to the work, but largely my overreaction I believe to be the result of delayed stress from events in my previous life.
I never consider this as me 'cracking' under the pressure - in all cases, while I may be cussing and fuming, I am still performing the job - in some cases at a higher level (to get done ASAP).
Is this 'Thriving' under pressure? I wouldn't consider it that, either, because I would not be able or willing to keep up such a level of performance indefinitely (peaks of this is okay to get the job done - but time inbetween is needed to recharge the battery).
Why are there twenty different ways to install the same piece of software depending on what distribution of Linux you're using?
Because, as some folks misunderstand, Linux is just the kernel. All the other stuff that surrounds it (GNU applications, Redhat package manager, The Gimp, Gnome, KDE, and on and on...) are individual applications that have to be integrated together - either by you if you build your own distribution, or the developers of the distribution you are using. If you pick a distribution, then you are bound by what they determine is the best way to deliver software. In many cases, you can actually have a voice in this process by joining the distribution's development team. In some cases the distribution development is created by a proprietary company - so your choices are limited to what they want you to have (no different than Windows) - unless you want to roll up your sleeves and do your own integration work (which you can do without having to drink the grape koolaid).
This is actually a good thing, since it allows the most flexibility; I can pick a distribution that satisfies how I like to install software, with most if not all the software packages I need. Unlike Windows, this takes some research - and in my case years of loading and administering many different distributions (Slackware, Redhat, Turbolinux, Suse, Debian, Mandrake, Gentoo,...). Until someone writes a book (maybe I will) on the subject, that is the only way I can see to get the wisdom.
My quick and dirty picks: pick Fedora (Redhat) if you want a more GUI oriented admin interface, or Debian if you don't mind getting your hands dirty in the CLI - and you generally can't go wrong. These distributions probably have the largest selection of software available as packages. If you are more willing to dig into the nitty gritty, and prefer a more BSD-ish layout of the startup files as well as systemV compatibility, I would suggest Slackware - my distribution of choice.
The key to avoiding these problems is, as I see it, when you see a piece of software you want to load - look at your distribution first, to see if it is available, or maybe even already loaded on your system. In most cases I have been able to download and install my distribution's version without a hiccup. In those rare cases when I do have to go outside of the distribution, I have had few problems due to the adherence of most major distributions to the Linux Filesystem Hierarchy standard and the Linux Standard Base.
One 'Linux' install standard imposed (how?) from above is not the solution.
Slackware has a package manager - but I usually don't bother because it uses plain tar balls; I download the tar balls from a Slackware mirror (the distro generally has everything I need) and extract what I need. Haven't run into any compatibility issues - ever.
I think if you stay inside of your distribution you won't have problems. The problem is when you download something outside of the distro and try to integrate it with your system. Then you get what you are asking for.
If you want to load a particular application - see if your distro has it on their package list first before downloading it from somewhere else. The distribution creators will have integrated it with your distro elimenating headaches for you.
If you must download something from outside of your distro - understand that you may have to do some integration work.
That being said, I have had very good luck loading some packages outside of what Slackware provides. I attribute it to the following:
1. Slackware conforms to the Linux filesystem standard. 2. The applications I have downloaded also conform to the Linux filesystem standard. 3. The applications I have downloaded did not use deprecated or experimental functions within the libraries they call (most libraries are good about staying backwards compatible for standard functions).
The most problems I have had doing integration was trying to get OSS applications to build under SUN Solaris. SUN packages change the default locations for various things (most notably, apps you would normally find under/usr/local/... end up in/opt/sfw/...) - and the apps I have to build by hand are looking elsewhere. I have also had environment problems - mostly missing path variables for libraries. Given that, the problem is not unique to Linux - but I would suggest it is less of a problem with Linux (provided you try to stay inside of your distribution - and only integrate outside apps when absolutely necessary) than with other operating systems, from my own experiences.
I was going to say - as a solution, why not set up a spare laptop as a wireless access point. When they come to ask you about it you say, "this is my workstation - who I share my workstation with, and more importantly, what processes I run and sockets my machine opens is my business".
Of course, if someone does something bad via your access point, you are responsible - but no less than would be the case for a dedicated piece of hardware attached to the same connection in your dormroom.
Re:Practical Common Lisp
on
Dive Into Python
·
· Score: 0, Flamebait
Is there anything mainstream, other than emacs (and considering emacs mainstream is a stretch at that), that uses Lisp as the implementation/macro language? There are probably good reasons for this.
I've used Lisp in the past; however there is nothing I can't do in other languages that I can do in Lisp. To me Lisp is very much like Cobol - you still see it around from time to time doing important things, but would never consider choosing it in preference to other more modern tools for any new projects.
Finally, and this is probably more important to me: ease of use. It takes me longer to write working Lisp code - primarily because I have to translate how my mind normally thinks in a structured/object oriented way, into a functional realm. IANAM (I am not a mathematician) - so do not feel drawn to Lisp, or limited by my lack of embracing Lisp as my general purpose programming language. I have been to the river, drank the water, and it was bitter to me. This is my experience informing my choices - not zealotry. It would be a pretty boring world if we all thought alike, and there was only one programming language.
Sadly, I am running Sun boxen (Solaris) - not supported by psyco.:(
Re:Joy of programming...
on
Dive Into Python
·
· Score: 4, Interesting
My language experience going back 24 years:
Basic, Fortran, Assembly (Intel and Sparc), Pascal, C, C++, Java, Lisp, shell(sh,awk,sed), Perl, and most recently Python. (roughly in that order; I saw some COBOL code once when a young programmer, but was immediately repulsed - thank heavens)
I actively use Perl and Python myself for everything now for several reasons:
1. All of the machines at my job (800+) are all preloaded with Perl - so I have to use it for automation (better than shell scripts particularly for mission critical one-off applications that have to be fault tolerant but deployed at the whim of our marketing and operations staff). If I didn't have to maintain Python myself on all of those machines, I would port everything over to Python in a heartbeat. However it took me 2 years to get management to agree to loading Perl in the first place - and there is no reason to incur the costs associated with validating a new scripting language for use in our production environment. So I live with it - and keep the footprint small.
2. For all other tasks - I use python.
Some neat things fall out of python that even as a neophyte I can appreciate:
a) clean syntax (if I only had all the time spent finding dangling semicolons in perl, I could take a sabbatical)
b) full featured web development tool (Zope - provides a framework for developing and hosting full service applications - designed to make building products to run under Zope easy - seperates the presentation from the logic using ZPT cascading style sheets and DTML for presentation, and python for the program logic [unless you are masochistic enough to depend upon DTML alone] - has a built-in database for managing Zope objects - and built-in httpd and ftpd servers - which can be further frontended using Apache as desired - can communicate with other databases [oracle, ODBC, postgreSQL, etc... many database plugins available] - has a large library of predeveloped products [modules for you perlmongers] that you can load and be up and running, or modify to your heart's content - and did I mention that its GPL'd?)
c) platform independent (just as with java and perl, python scripts can run without modification on many operating systems - keeping porting costs down to a bare minimum.
d) built-in documentation functionality - not as full featured as Perl's perldoc - but I might not have found the right product yet to do that (ideas anyone? or, is this a python project waiting for me to jump on - perhaps something that ouputs XML?)
The only drawbacks (and I use this term with trepidation - because they can seem positively refreshing after 10 years with perl) that I can see are:
A. Does not have the sheer amount of user contributed products (modules) when compared to CPAN^. Of course I wouldn't judge the quality of my carreer based on the weight of all of my program printouts either. Quantity does not equate to quality.
B. Slower than Perl and Java. Again, something I can throw hardware at to rectify. Squid goes along way to making web pages generate faster too - so you can ameliorate some of the problems without having to kill yourself.
C. Sometimes it takes longer to find resources online than with other languages because of the difference in popularity. However, the time spent needing to refer to reference material for Perl and Java is many times larger than the time spent doing the same with Python.
D. Because of my long experience with Perl, I find myself immediately jumping to a predetermined algorithm/function that is implemented differently in Python and thus create syntax errors in my code. This last is really a personal problem that time will erase.
My whole programming paradigm has changed. The advent
I was going to echo this same advice. Redhat looks good to management because there is an entity behind it they can hold 'feet to the fire' for outages and lost revenue.
With Debian, a business has no one to sign a contract with, and no one to sue if everything goes to pot. While you may not worry about this because you have your arms around it (and you certainly won't die, get a bump on the head, or otherwise become incapacitated), you can be assured that this, and everything else we might consider 'paranoia' flickers through the brains of the management and their lawyers on a daily basis (that and maximizing profits, of course).
While we on the outer edge of the operational tree may not like what goes on in the middle - it behooves us to at least understand why seemingly brain dead things happen so we can work around it.
Perhaps to settle this once and for all, we should have a 'shoot out' - a test to implement 10 specifications using our respective tools of choice:
1. oneliner specification (or verbal) do X 2. implement grep (man page serves as spec) 3. implement a web based database application that has X functionality 4. etc.... (all 10 acceptable tests for all parties)
First team to finish all projects (testplan based on specification given) wins a $25 gift certificate from ThinkGeek...:)
There are thousands of developers that would disagree with your myopic viewpoint.
If it's worth doing, it's worth doing with some confidence of reliability...
Not every application need be gold plated - and still serve a useful purpose. Data integrity can be ensured in the data prior to reading into the application. For certain system administration tasks, you can make assumptions regarding formatting.
For example, the/etc/passwd file has a standard format that any program can read without explicit checks. Why waste time building an application that is going to be bullet proof - when you will only use it once or twice or for a clearly defined purpose?
This cuts to the core differences of the *nix OS and other less robust OSes - the tool making paradigm versus the monolithic application paradigm. I can get more done in a shorter time using tool building and interprocess communication than I can building stand alone apps. On the one hand you have the best of both worlds - you can build one-off apps, as well as full blown 'proper' applications; on the other hand (your hand) you can only build monolithic apps for everything - which leads you to try to build one app that does everything but nothing well.
Python/Zope will allow me to interface with multiple RDBMSs easily. The key is to use the tool that best fits the job. One size does not fit all. There is room for Java solutions; however, I have seen no pressing need to change from the perl/python I am using now for those server-side solutions.
Enterprise application development involves much more than just hacking together app in a a few hours...
My job is to make my customers (be they internal or external) happy. If that means hacking together something in a few hours - then I am going to do it. I am going to use every tool in my arsenal to deliver the solution when (before if possible) they need it - and then factor out any bottlenecks not anticipated (something you will still have to do regardless of what environment you use).
This goes to the core of the difference between classic 'waterfall' development techniques, and more progressive agile software development. The focus in classic design is to have everything defined up front and is reflected in the tools chosen for particular jobs. In reality, unless the application is trivial, this is not attainable in practice. Given that - I can't see any convincing argument that will bring me to embrace Java (on the server or client side).
I liken the difference between classic development methodology and agile development as the difference between a boxer and a streetfighter. The boxer is constrained by the rules, whereas a streetfighter will hit you with a brick if that is the most effective way to bring you down. Results are the touchstones of successful software development projects. I have seen enough projects go massively over budget and fail to deliver the promised functionality to know that classic 'authorities' do not trump results.
I also specifically loved the good type checking and the like. I want that from my languages.
What you gain in stability you lose in flexibility.
Python/Perl have very smart primitive types (basically: string, array, hash [not correct terminology for either language - but a good approximation]) that can be retyped depending on the context in which they are used. For example, a string can be used in a numerical context for calculations without having to waste space translating the string to a number, then assigning it to a numerical type. This typecasting is automatic - something the programmer doesn't have to think about.
However, now the programmer is responsible for his own data integrity. In practice this is far less time consuming than in traditional 3GLs. Furthermore, for those 'one-off' administrative/glue type apps - you can ignore it entirely if the manipulation of the data is well defined (such as in filtering) - you don't have that luxury in Java, where you must define your variables up front - a fixed overhead cost to every application.
I don't grok functional-programming...
By functional-programming, I assume you mean structured programming? I think it is safe to say that every programming language, save Schema / Lisp, can be used in a structured (non-object oriented) manner. I can't imagine understanding OO without having first understood the basics of structured programming. Having the reverse be true boggles the mind...considering that structured programming is simpler than OO in most cases.
Slashdot Mirror
So what is a complete implementation, then?
If WindowMaker is the only thing going, then defacto it is the standard.
Additionally, my understanding is that the applications, such as the workplace manager, are GNUstep applications. What functionality is missing when I run it under WindowMaker?
Logically, something would have to implement the GNUstep framework, in order for GNUstep applications to run - I don't see how you would build a GNUstep GNUstep emulator, as a result.
Am I off base here? If so, how?
What about using hydrogen gas? It would produce H2O as a result of burning.
This would be great on a survival phone - the more you talk the more fresh water you produce!
His program was sending malformed HTML. Logically, you could collect the 'failures' and do correlation on what you found - hence his estimation of some of the problems being related to specific C library functions and their misuse (calloc, strlen etc...).
This is a good thing, because the developers of the browsers in question will now be able to refactor their code to handle error conditions properly.
On the other hand, while IE may have passed this 2 hour (his admition) test - that is certainly not definitive proof because there are too many unknowns (did the tests go through every HTML construct in all possible permutations? I am guessing not). Given the subset of potential malformed HTML thrown at these systems - yes IE won. Is that the final word on this? No, MicroSoft has a long history of poor software security that we can't simply sweep under the rug. Without the source, barring a complete test that covers all possible permutations, we will never be able to validate that assumption.
nitpicker....
At any rate, yes GNUstep is the framework that WindowMaker and its tools are built on to be completely accurate.
For all intents and purposes, GNUstep is a free implementation of the NEXTstep specification, which underpins every native WindowMaker application. However, WindowMaker also allows you to run other X11 (XFree86 and its successor) applications as well.
So I was right - depending upon what your definition of 'is' is.
I have an old PIII 500 mhz machine I use as my file server, running linux.
On a lark I loaded GNUstep as the default windowing environment. I like it - but haven't explored all of its capabilities and limitations yet.
This also points to an interesting aspect: companies are short sighted - and only focus on the current year's revenue at the expense of long range planning.
Rather than create a longterm situation where large sums of money could have been made satisfying the customers, they chose the short term solution of 'lets make money now - screw the customer'. Imagine the tools we would have today if it had gone the other way.
IBM is atoning for its early blunder by supporting Linux and OpenSource - as long as it is profitable for them, of course.
I thank the Almighty (whatever, he, she or it may, or may not be) every day for Linux and the choice not to use Microsoft software.
Hypersonic Ramjet technology would be able to use the atmosphere to compress a fuel/air mixture for produce thrust into near earth orbit. You wouldn't have to take as much fuel - which would increase your payload potential.
I have two U.S. Army issue rucksacks - one small and one large with a metal frame that fits both - both of which have a pouch at the top for mounting one of the old PRC box-style radios. This pouch is sufficient size to hold a laptop, and you have the added storage to cover your other travel gear as required. Open the cover flap, and release a strap - and the computer is in your hands. The computer is closest to your back - and with a full pack, would be surrounded on the outside by other things.
These systems are tough - and having them for over 10 years now, they appear to be brand new.
Because Sun has the deepest pockets. Who else will they sue for OpenOffice? The developers, most of who make much less than the cost of pursuing such a case?
Finally, Microsoft would lose for many reasons (prior art, fundamental differences between the implementations etc...)
So, /usr/bin would be where the distribution deposits user commands, or a package updates said commands, whereas /usr/local/bin is left for the administrator(you) to put additional software added after installation that is not part of the regular distribution.
/opt:
As for
So, /opt is used for add-on packages whereas /user/local would be the target for the output of such packages - if not part of a regular distribution; as mentioned above, if the package updates an existing part of the distribution in /usr, then it can put it in the normal location (instead of /usr/local). This is why you have to be careful to grab the package from the same distribution - because, by definition, certain assumptions are being made by the distributors that may be different from that of another. This is also good - because it allows wiggle room for a distribution to extend the directory structure.
/usr/local. This avoids any conflicts, and makes backing up and restoring my stuff easy (tar -cvf usrlocal.tar /usr/local) - not to mention, I know where to look when there is a problem with an app. System upgrading and restoration is as easy as sftp'ing that tarball to another machine, then loading the new OS, and restoring the tarball.
As a matter of policy, I install all non-distribution packages/builds into
Finally, the Linux Standard Base is an attempt to close the doors on areas of paticular contention. The LSB states, among other things:
On the one hand pressure exerted by management rolls off like water on a duck's back. I spent 4 years in the AirForce, and 7 years in the Army (11B, 19D) - so someone telling me nicely that they are piling on yet another project to my already overloaded schedule, or that they are moving my due date up 2 weeks, or that they disagree with how I intend to implement this software, is nothing in comparison to having a bunch of armed men around who can inflict bodily harm, or death at any moment, who are looking to you for guidance.
On the other hand, the pressure that really gets me is when I don't live up to my own expectations and I slip a deadline that I have committed to. This rarely occurs - but when it does, it raises my bloodpressure, and I lose my composure. I equate some of this to the work, but largely my overreaction I believe to be the result of delayed stress from events in my previous life.
I never consider this as me 'cracking' under the pressure - in all cases, while I may be cussing and fuming, I am still performing the job - in some cases at a higher level (to get done ASAP).
Is this 'Thriving' under pressure? I wouldn't consider it that, either, because I would not be able or willing to keep up such a level of performance indefinitely (peaks of this is okay to get the job done - but time inbetween is needed to recharge the battery).
Why are there twenty different ways to install the same piece of software depending on what distribution of Linux you're using?
...). Until someone writes a book (maybe I will) on the subject, that is the only way I can see to get the wisdom.
Because, as some folks misunderstand, Linux is just the kernel. All the other stuff that surrounds it (GNU applications, Redhat package manager, The Gimp, Gnome, KDE, and on and on...) are individual applications that have to be integrated together - either by you if you build your own distribution, or the developers of the distribution you are using. If you pick a distribution, then you are bound by what they determine is the best way to deliver software. In many cases, you can actually have a voice in this process by joining the distribution's development team. In some cases the distribution development is created by a proprietary company - so your choices are limited to what they want you to have (no different than Windows) - unless you want to roll up your sleeves and do your own integration work (which you can do without having to drink the grape koolaid).
This is actually a good thing, since it allows the most flexibility; I can pick a distribution that satisfies how I like to install software, with most if not all the software packages I need. Unlike Windows, this takes some research - and in my case years of loading and administering many different distributions (Slackware, Redhat, Turbolinux, Suse, Debian, Mandrake, Gentoo,
My quick and dirty picks: pick Fedora (Redhat) if you want a more GUI oriented admin interface, or Debian if you don't mind getting your hands dirty in the CLI - and you generally can't go wrong. These distributions probably have the largest selection of software available as packages. If you are more willing to dig into the nitty gritty, and prefer a more BSD-ish layout of the startup files as well as systemV compatibility, I would suggest Slackware - my distribution of choice.
The key to avoiding these problems is, as I see it, when you see a piece of software you want to load - look at your distribution first, to see if it is available, or maybe even already loaded on your system. In most cases I have been able to download and install my distribution's version without a hiccup. In those rare cases when I do have to go outside of the distribution, I have had few problems due to the adherence of most major distributions to the Linux Filesystem Hierarchy standard and the Linux Standard Base.
One 'Linux' install standard imposed (how?) from above is not the solution.
2. A consistent filesystem hierarchy is followed from distribution to distribution...
Actually all distributions should be following the Linux Filesystem Hierarchy Standard.
If yours isn't, then you need to get them to follow it, or find another distribution that does.
Slackware has a package manager - but I usually don't bother because it uses plain tar balls; I download the tar balls from a Slackware mirror (the distro generally has everything I need) and extract what I need. Haven't run into any compatibility issues - ever.
/usr/local/... end up in /opt/sfw/...) - and the apps I have to build by hand are looking elsewhere. I have also had environment problems - mostly missing path variables for libraries. Given that, the problem is not unique to Linux - but I would suggest it is less of a problem with Linux (provided you try to stay inside of your distribution - and only integrate outside apps when absolutely necessary) than with other operating systems, from my own experiences.
I think if you stay inside of your distribution you won't have problems. The problem is when you download something outside of the distro and try to integrate it with your system. Then you get what you are asking for.
If you want to load a particular application - see if your distro has it on their package list first before downloading it from somewhere else. The distribution creators will have integrated it with your distro elimenating headaches for you.
If you must download something from outside of your distro - understand that you may have to do some integration work.
That being said, I have had very good luck loading some packages outside of what Slackware provides. I attribute it to the following:
1. Slackware conforms to the Linux filesystem standard.
2. The applications I have downloaded also conform to the Linux filesystem standard.
3. The applications I have downloaded did not use deprecated or experimental functions within the libraries they call (most libraries are good about staying backwards compatible for standard functions).
The most problems I have had doing integration was trying to get OSS applications to build under SUN Solaris. SUN packages change the default locations for various things (most notably, apps you would normally find under
I've got a Knoppix CD that says their wrong...
I was going to say - as a solution, why not set up a spare laptop as a wireless access point. When they come to ask you about it you say, "this is my workstation - who I share my workstation with, and more importantly, what processes I run and sockets my machine opens is my business".
Of course, if someone does something bad via your access point, you are responsible - but no less than would be the case for a dedicated piece of hardware attached to the same connection in your dormroom.
Is there anything mainstream, other than emacs (and considering emacs mainstream is a stretch at that), that uses Lisp as the implementation/macro language? There are probably good reasons for this.
I've used Lisp in the past; however there is nothing I can't do in other languages that I can do in Lisp. To me Lisp is very much like Cobol - you still see it around from time to time doing important things, but would never consider choosing it in preference to other more modern tools for any new projects.
Finally, and this is probably more important to me: ease of use. It takes me longer to write working Lisp code - primarily because I have to translate how my mind normally thinks in a structured/object oriented way, into a functional realm. IANAM (I am not a mathematician) - so do not feel drawn to Lisp, or limited by my lack of embracing Lisp as my general purpose programming language. I have been to the river, drank the water, and it was bitter to me. This is my experience informing my choices - not zealotry. It would be a pretty boring world if we all thought alike, and there was only one programming language.
Sadly, I am running Sun boxen (Solaris) - not supported by psyco. :(
My language experience going back 24 years:
Basic, Fortran, Assembly (Intel and Sparc), Pascal, C, C++, Java, Lisp, shell(sh,awk,sed), Perl, and most recently Python. (roughly in that order; I saw some COBOL code once when a young programmer, but was immediately repulsed - thank heavens)
I actively use Perl and Python myself for everything now for several reasons:
1. All of the machines at my job (800+) are all preloaded with Perl - so I have to use it for automation (better than shell scripts particularly for mission critical one-off applications that have to be fault tolerant but deployed at the whim of our marketing and operations staff). If I didn't have to maintain Python myself on all of those machines, I would port everything over to Python in a heartbeat. However it took me 2 years to get management to agree to loading Perl in the first place - and there is no reason to incur the costs associated with validating a new scripting language for use in our production environment. So I live with it - and keep the footprint small.
2. For all other tasks - I use python.
Some neat things fall out of python that even as a neophyte I can appreciate:
a) clean syntax (if I only had all the time spent finding dangling semicolons in perl, I could take a sabbatical)
b) full featured web development tool (Zope - provides a framework for developing and hosting full service applications - designed to make building products to run under Zope easy - seperates the presentation from the logic using ZPT cascading style sheets and DTML for presentation, and python for the program logic [unless you are masochistic enough to depend upon DTML alone] - has a built-in database for managing Zope objects - and built-in httpd and ftpd servers - which can be further frontended using Apache as desired - can communicate with other databases [oracle, ODBC, postgreSQL, etc... many database plugins available] - has a large library of predeveloped products [modules for you perlmongers] that you can load and be up and running, or modify to your heart's content - and did I mention that its GPL'd?)
c) platform independent (just as with java and perl, python scripts can run without modification on many operating systems - keeping porting costs down to a bare minimum.
d) built-in documentation functionality - not as full featured as Perl's perldoc - but I might not have found the right product yet to do that (ideas anyone? or, is this a python project waiting for me to jump on - perhaps something that ouputs XML?)
The only drawbacks (and I use this term with trepidation - because they can seem positively refreshing after 10 years with perl) that I can see are:
A. Does not have the sheer amount of user contributed products (modules) when compared to CPAN^. Of course I wouldn't judge the quality of my carreer based on the weight of all of my program printouts either. Quantity does not equate to quality.
B. Slower than Perl and Java. Again, something I can throw hardware at to rectify. Squid goes along way to making web pages generate faster too - so you can ameliorate some of the problems without having to kill yourself.
C. Sometimes it takes longer to find resources online than with other languages because of the difference in popularity. However, the time spent needing to refer to reference material for Perl and Java is many times larger than the time spent doing the same with Python.
D. Because of my long experience with Perl, I find myself immediately jumping to a predetermined algorithm/function that is implemented differently in Python and thus create syntax errors in my code. This last is really a personal problem that time will erase.
My whole programming paradigm has changed. The advent
I was going to echo this same advice. Redhat looks good to management because there is an entity behind it they can hold 'feet to the fire' for outages and lost revenue.
With Debian, a business has no one to sign a contract with, and no one to sue if everything goes to pot. While you may not worry about this because you have your arms around it (and you certainly won't die, get a bump on the head, or otherwise become incapacitated), you can be assured that this, and everything else we might consider 'paranoia' flickers through the brains of the management and their lawyers on a daily basis (that and maximizing profits, of course).
While we on the outer edge of the operational tree may not like what goes on in the middle - it behooves us to at least understand why seemingly brain dead things happen so we can work around it.
Perhaps to settle this once and for all, we should have a 'shoot out' - a test to implement 10 specifications using our respective tools of choice:
:)
1. oneliner specification (or verbal) do X
2. implement grep (man page serves as spec)
3. implement a web based database application that has X functionality
4. etc....
(all 10 acceptable tests for all parties)
First team to finish all projects (testplan based on specification given) wins a $25 gift certificate from ThinkGeek...
Sorry, that's a bug, not a feature...
/etc/passwd file has a standard format that any program can read without explicit checks. Why waste time building an application that is going to be bullet proof - when you will only use it once or twice or for a clearly defined purpose?
There are thousands of developers that would disagree with your myopic viewpoint.
If it's worth doing, it's worth doing with some confidence of reliability...
Not every application need be gold plated - and still serve a useful purpose. Data integrity can be ensured in the data prior to reading into the application. For certain system administration tasks, you can make assumptions regarding formatting.
For example, the
This cuts to the core differences of the *nix OS and other less robust OSes - the tool making paradigm versus the monolithic application paradigm. I can get more done in a shorter time using tool building and interprocess communication than I can building stand alone apps. On the one hand you have the best of both worlds - you can build one-off apps, as well as full blown 'proper' applications; on the other hand (your hand) you can only build monolithic apps for everything - which leads you to try to build one app that does everything but nothing well.
You are quite right - my brain fart. We are both of the same mind on functional programming. (insert foot firmly in mouth)
I can't think of anywhere I would use Lisp - save tweaking emacs macros...
Python/Zope will allow me to interface with multiple RDBMSs easily. The key is to use the tool that best fits the job. One size does not fit all. There is room for Java solutions; however, I have seen no pressing need to change from the perl/python I am using now for those server-side solutions.
Enterprise application development involves much more than just hacking together app in a a few hours...
My job is to make my customers (be they internal or external) happy. If that means hacking together something in a few hours - then I am going to do it. I am going to use every tool in my arsenal to deliver the solution when (before if possible) they need it - and then factor out any bottlenecks not anticipated (something you will still have to do regardless of what environment you use).
This goes to the core of the difference between classic 'waterfall' development techniques, and more progressive agile software development. The focus in classic design is to have everything defined up front and is reflected in the tools chosen for particular jobs. In reality, unless the application is trivial, this is not attainable in practice. Given that - I can't see any convincing argument that will bring me to embrace Java (on the server or client side).
I liken the difference between classic development methodology and agile development as the difference between a boxer and a streetfighter. The boxer is constrained by the rules, whereas a streetfighter will hit you with a brick if that is the most effective way to bring you down. Results are the touchstones of successful software development projects. I have seen enough projects go massively over budget and fail to deliver the promised functionality to know that classic 'authorities' do not trump results.
I also specifically loved the good type checking and the like. I want that from my languages.
What you gain in stability you lose in flexibility.
Python/Perl have very smart primitive types (basically: string, array, hash [not correct terminology for either language - but a good approximation]) that can be retyped depending on the context in which they are used. For example, a string can be used in a numerical context for calculations without having to waste space translating the string to a number, then assigning it to a numerical type. This typecasting is automatic - something the programmer doesn't have to think about.
However, now the programmer is responsible for his own data integrity. In practice this is far less time consuming than in traditional 3GLs. Furthermore, for those 'one-off' administrative/glue type apps - you can ignore it entirely if the manipulation of the data is well defined (such as in filtering) - you don't have that luxury in Java, where you must define your variables up front - a fixed overhead cost to every application.
I don't grok functional-programming...
By functional-programming, I assume you mean structured programming? I think it is safe to say that every programming language, save Schema / Lisp, can be used in a structured (non-object oriented) manner. I can't imagine understanding OO without having first understood the basics of structured programming. Having the reverse be true boggles the mind...considering that structured programming is simpler than OO in most cases.