I don't need 3D as I don't see 2D well enough. So, I guess I need such eye (better two) for living.
What you need is a toy for entertainment. similar toy military and other extreme seperts need to extend the natural vision. But that is completely different task and perhaps a different market.
For personal (as well as small to mid size corporate) information and document management the CPU speed today is less important. I still see more suffering from the lack of RAM and from slow system buses.
I've got a grey color box when a terminal window was full of error messages about fonts not found
You've specified fonts - that's the shortest way to break portability of Java applications as every system has different available fonts and Java VM (remember a myth about java portability?) behaves in such situations differently on different platforms. I've tried it on Yellod Dog Linux v2.1 ("Grey" G4 box).
Re:This book is destined
on
Perl and XML
·
· Score: 1
I've got the point - you have a fun from obfuscation only on competitions. Sorry that I got you wrong.
Now let's get back to Perl. My point is that even programmers experienced in several programming languages, well CS educated and having years of successfull experience, they have problems of reading their own code in Perl after awhile. I can speak for myself and for several others. We can write quickly well working programs, but with increasing of the code size the ability to read and understand the progam is declining. Thus, we call Perl as a "self-obfuscated" language. Even having some general comments in the text it's hard to read. The reason I see is in regexps and awk roots.
Other languages used to compare a capability of self-obfuscation: Python, Tcl, C, C++, Java, Lisp, Scheme, Prolog, Oz, Haskell, Erlang, OCaml.
Personally, I have the best result with Lisp, Scheme, Prolog and Oz, when I can unnderstand the code after years and I can easily read the code of other programmers without "over-comments". I can do even "eye-debugging", running ever the code back and forth and predicting without mistakes what's going on. The reading such text is like reading some English text. And the writing is like the rythming of poetry.
Good results I have with: Python, Java, Haskell, OCaml and Erlang. The reading reminds me XML and RDF. The writing is like the compocing an article or a book.
Bad results - with C, C++, Tcl. The reading reminds me TeX. The writing is like creating a legal or medical document.
The worst result - with Perl. I can compare it only with Postscript and m4. The writing is like you to it blind - you cannot read.
Re:This book is destined
on
Perl and XML
·
· Score: 1
Your definition of "quick hack" seems to be questionable
So is yours.
Every language can be used to write obfuscated code.
Here we go. I hack (and have a pleasure from it) in order to "crack" the puzzling problem and to reduce the overall obfuscation in the environment around me. Think about enthropy. You increase disoreder by writing an obfuscated code when it is not originally required. You do it for "fun" - you receive a pleasure when other people are suffering looking at your code or trying to fix it. So, you should go out off the kitchen as you make a life of other people harder. You are a cyber-punk.
The rest of your comments, both about me and about Perl is just a troll and thus should be ignored.
I don't think that HomeBaseis good or bad in any functions, considering how it would bring "M$-Outlook" capabilities to OpenOffice.org. But I know for sure that I want all HomeBase's functions in my OpenOffice. And I want them on any platform where OpenOffice works. The last argument saves Evolution from being bothered by integration with OpenOffice - There is no such thing as Gnome for Win32 and MacOS/*. I love Gnome, but with all do respect, I prefer the path of Mozilla and OpenOffice.org - work the same way across all platforms. And HomeBase is perfectly completing the picture of Mozilla/OpenOffice.
That's the keyword to fire a new round of war with vim zealots:)
Coming back to the subject, I would compare also Linux vs BSD:
Linux Kiosk project may exist only as GPL and any kiosk provider cannot make any money on licensing it.
BSD Kiosk is better to make some fee-based profits, but there might be some lack of modern hardware device support (USB, FireWire, Bluetooth etc).
Short-term solution: it's not difficult to make a "userland" level of the KIOSK commercial (Mozilla, some other X11 applications, some monitoring tools), keeping the "system" level (Linux, boot sequence, most of system services) still GPLed. When Apple/MacOS/X will finally contribute to FreeBSD with such new hardware support, then the whole system might close the sources.
That's the reason, why BSD license still exists, right?
B/c Win2K is not much more stable then Win(3-98) - the today's practical experience shows that you should schedule for rebooting your win-based kiosks every night (or be prepared for daily surpises) against every several months in case of Linux. There are several reasons, one of themis IE is integrated to GUI, which is integrated to OS, and that drammatically increases the chance that the whole system should be reboot in order to clean the problem up. In Linux you may restart Mozilla or X11 keeping the kernel and other services up and running.
Besides, remote login (SSH, with X11 or without) is much more convinient, secure and economical way for remote troubleshooting, comparing to M$ Terminal Server or any other VNC.
No need to mention that having available source you can customize Linux system from top to bottom, from boot to monitoring. That's a real flexibility and customization. And no need to mention that you will not pay a fee for MSDN and other devlopement tools.
Speaking about money - why would taxpayers want to pay Microsoft for licenses when Microsoft keeps screwing users' right up, while there is the easy, reliable, secure and flexible choice?
Why not use the power of GNU/Linux to give users real accounts? You know, so they can save their work and eventualy retrieve it?
That is actually a good idea. It will require a more advanced GDM, but that is not a big problem to to redesign it, adding some self-registration forms.
If some installations will require Smart Card, there should not be a problem to integrate GDM with a card reader as well.
The only problem I see is in potential overflow of the user base. But I think that some database-beckended LDAP (OpenLDAP with PostgreSQL) will solve the issue.
This book is primitive
on
Perl and XML
·
· Score: 1
Who cares about "raw" XML? Only experimenting engineers. Real-world application require either XSLT (which is poorly presented in the book) or RDF (wich is not presented at all).
Show me use cases, styles, patterns and examples of developing web applications with AxKit. Same about Redland, which suffers from the lack of documentation.
This book just repeats about XML what was already said in other books.
Re:This book is destined
on
Perl and XML
·
· Score: 1
If your quick hacks are unmaintainable, get another job.
Or rather get another language. It's not difficult to guess that it should be Python.
You cannot hack on Java - you change the task requirements to fit all the limitation, restrictions of the language and of proprietary frameworks. Your hacks on Ruby will be very limited and immature. Your Tcl hacks will be same unmaintainable with a grown project size, although at least you will be able to read your code.
OCaml, Haskell, Oz and Erlang are still too exotic for Linux/BSD world. Although, when I've tried them I've got a real and fresh entertainment. However, there is a real lack of good libraries. Lisp and Scheme have the same problem.
Conclusion: writing over-obfuscated code was not in the job requirements. Pick the right tool for your job.
That was a key phrase. Most of programmers (open-source ones) love Emacs. Most of admins love Vi. The reason? Different tasks, a different style of thinking, sometimes even a different education.
Almost every Emacs user also runs vi...
on
Vi IMproved -- Vim
·
· Score: 1
... at least (and mostly at most) one time: write after the system installation is completed to edit Makefile or some just in order to comile Emacs or Xemacs. Right after that - Emacs (or Xemacs) forever.
OfB: The GNOME Project recently released the second major version of its desktop. Have you had a chance to look at this desktop? Briefly, what are you thoughts on the other available GNU/Linux desktops?
AFP: Actually, Tim, I do not concern myself with using other FS / OS (Free Software / Open Source) desktops very much. This protects me from having to answer questions like this one that involve making comparisons . I can just honestly answer, "I don't know about XYZ," and leave it at that.
I don't see KDE as having competition with these desktops as a primary motivator or purpose. What KDE tries to do is to be the best it can be, and to provide a nice, easy-to-use alternative for others. The main interaction I see with other desktops centers around a mailing list and website established for discussing potential desktop standards.
How do you intend to provide a nice, easy-to-use alternative for others if you avoid making comparisons?
With XSLT (for example Cocoon) I can create as much of tiers as I need, balancing and clustiring them, connecting them with Pipes (locally) or with SOAP (remotely), or even with CORBA.
XSLT separates aspects using different templates. There is no problem with sessions (I have it in servlets) and DB connectivity (XSLT extensions work fine for it).
With XSLT I can cache (save on the disk) XML (or HTML) output (in fact - every output) of intermediate tiers - that may give a very great perfomance improvement if you do it right. Can you do it with EJB?
So, does it mean that if I know more than only Java (if I know also XSLT) then Cocoon or the other XSLT frameworks are more appropriate for those scenarios, which do not require EJB explicitely? Is this the real bottom line - to use EJB only if it is required to connect to pre-required 3rd party EJB components?
Speaking about Java, with EJB I am limited to Java . Some people love Java for OOP
(especiaally after C, Perl and Visual Basic), some people hate it for its imperative paradigm (especially after Lisp, ML, Haskell, OZ, Erlang and Mercury). With XSLT I can use any language with XSLT binding. Or even any combination of languages: Perl, Tcl, Python, some of Lisps or any others (with XSLT). Why would I do it? Again - to meet a combination of specific scenarios. For example, Java is too bad to work with OS. Another bottom line. It seems to me that EJB has very poor interoperability. You buy EJB and you are a poisoned slave of Java.
J2EE servers. They provide support for Enterprise Java Beans, as well as a lot of other technologies in J2EE, including Servlets and JSP.... Comparing Tomcat to those is like comparing apples to fruits.
Let's put it then in anoter way:
If I write the web application from scratch and I don't have any other infrastructure yet (besides, probably, SQL/JDBC database), then what kind of JBoss (or other EJB servers) would I need comparing to a standalone installation of Tomcat?
The installation of JBoss requires more time and efforts than the installtion of a standalone Tomcat. The development with EJB requires drammatically more time and effort than the development of servlets, especially, servlets with XSLT or other template toolkits. So, how would such diference be compensated?
The problem with Lisp is more than that: most of programmers are not educated (in terms of CS theories) enough to understand FP. That's also the reason why XSLT is still not popular. By the way, there is XSLT for Java, C, Tcl, Perl and Python. Google doesn't find any XSLT for Lisp. Actually, Google doesn't find much of good modern libraries for Lisp. And those available - they work only on some implementations. Forget about portability.
Scheme, having Lisp-like syntax and same pradigms, has the same problem as Lisp. Also, Scheme in avergae requires not so high level of CS education as Lisp does. And Scheme is much better scalable down: VM startup time is really short, especially in "tiny" implementations. And, of course, the portability of Scheme makes it much more attractive: I have Scheme in both open source licenses (GPL and BSD) for all platforms I work with (Linux/86, Linux/PPC, Win32/Cygwin, MacOS/X). Personaly, the only problem I have with Scheme - there is not enough of libraries.
I would better consider Python, as it is a language combining both imperative and functional programming paradigms, and at the same time having not-bad OOP model.
Plus, Python has pretty good various libraries (OS, web, databases, regexps, RDF, XSLT) and a very good web application server (Zope). Would Lisp has such libraries and application (available in open source) - the situation might be different today.
My point was rather that whatever you pick, it's not going to be popular for a lot of people.
You are right. Most of software development is performed using very primitive tools. Professional software developers prefer either VB or Java, mistaking professional programming tools (which Java and VB are not) with programming tools professionally marketted (by MS and Sun).
Unfortunately, Linux faces the same problem. For example RBAC is well known for awhile, but for Linux it's still in experimental dreams. Python was proved as the best scripting and OS-automation language, but sysadmins still keep creating write-only Perl kludges. Long time ago CVS was proved as too primitive for serios and complex development projects, but alternative versioning systems still are not popular. RPM is known as the most primitive package management tool, but Gentoo's Portage was even not considered for LSB.
Too bad, the world doesn't love the best. The world loves tools, which everyone can understand quickly. Everyone, including uneducated ones.
There is a lot of comparing of RPM versus DEB. But is that it? How about Gentoo Portage system? It seems even more advanced than Debian packaging system. You can get more info here and here.
Our company seriously considers Gentoo as it helps to build a Linux distro (or two) customized for specific corporate needs. Our research shows that with RPM or DEB we'd spend more resources on creating and supporting own distros.
Slashdot Mirror
Does it *legally* exist?
What you need is a toy for entertainment. similar toy military and other extreme seperts need to extend the natural vision. But that is completely different task and perhaps a different market.
For personal (as well as small to mid size corporate) information and document management the CPU speed today is less important. I still see more suffering from the lack of RAM and from slow system buses.
You're right, but ...
Vim is better than Emacs
Java is a dead buzzword
You're tight again
PHP is far too slow
You're right again.
Python is for hippies
Again, you're a moron.
*BSD is dying, OS X is just eyecandy
But here you are right again.
Mozilla is a buggy piece of shit
That's stupid.
spaces are better than tabs
The final point is correct.
So, it seems to me you've let your brother/friend type every other sentence for you and one of you is normal, while the other is stupid idiotic moron.
Next time make a separate ./ account for you brother/friend.
You've specified fonts - that's the shortest way to break portability of Java applications as every system has different available fonts and Java VM (remember a myth about java portability?) behaves in such situations differently on different platforms. I've tried it on Yellod Dog Linux v2.1 ("Grey" G4 box).
Now let's get back to Perl. My point is that even programmers experienced in several programming languages, well CS educated and having years of successfull experience, they have problems of reading their own code in Perl after awhile. I can speak for myself and for several others. We can write quickly well working programs, but with increasing of the code size the ability to read and understand the progam is declining. Thus, we call Perl as a "self-obfuscated" language. Even having some general comments in the text it's hard to read. The reason I see is in regexps and awk roots.
Other languages used to compare a capability of self-obfuscation: Python, Tcl, C, C++, Java, Lisp, Scheme, Prolog, Oz, Haskell, Erlang, OCaml.
Personally, I have the best result with Lisp, Scheme, Prolog and Oz, when I can unnderstand the code after years and I can easily read the code of other programmers without "over-comments". I can do even "eye-debugging", running ever the code back and forth and predicting without mistakes what's going on. The reading such text is like reading some English text. And the writing is like the rythming of poetry.
Good results I have with: Python, Java, Haskell, OCaml and Erlang. The reading reminds me XML and RDF. The writing is like the compocing an article or a book.
Bad results - with C, C++, Tcl. The reading reminds me TeX. The writing is like creating a legal or medical document.
The worst result - with Perl. I can compare it only with Postscript and m4. The writing is like you to it blind - you cannot read.
So is yours.
Every language can be used to write obfuscated code.
Here we go. I hack (and have a pleasure from it) in order to "crack" the puzzling problem and to reduce the overall obfuscation in the environment around me. Think about enthropy. You increase disoreder by writing an obfuscated code when it is not originally required. You do it for "fun" - you receive a pleasure when other people are suffering looking at your code or trying to fix it. So, you should go out off the kitchen as you make a life of other people harder. You are a cyber-punk.
The rest of your comments, both about me and about Perl is just a troll and thus should be ignored.
Any screenshot?
I don't think that HomeBaseis good or bad in any functions, considering how it would bring "M$-Outlook" capabilities to OpenOffice.org. But I know for sure that I want all HomeBase's functions in my OpenOffice. And I want them on any platform where OpenOffice works. The last argument saves Evolution from being bothered by integration with OpenOffice - There is no such thing as Gnome for Win32 and MacOS/*. I love Gnome, but with all do respect, I prefer the path of Mozilla and OpenOffice.org - work the same way across all platforms. And HomeBase is perfectly completing the picture of Mozilla/OpenOffice.
Any screenshots?
That's the keyword to fire a new round of war with vim zealots :)
Coming back to the subject, I would compare also Linux vs BSD:
Linux Kiosk project may exist only as GPL and any kiosk provider cannot make any money on licensing it.
BSD Kiosk is better to make some fee-based profits, but there might be some lack of modern hardware device support (USB, FireWire, Bluetooth etc).
Short-term solution: it's not difficult to make a "userland" level of the KIOSK commercial (Mozilla, some other X11 applications, some monitoring tools), keeping the "system" level (Linux, boot sequence, most of system services) still GPLed. When Apple/MacOS/X will finally contribute to FreeBSD with such new hardware support, then the whole system might close the sources.
That's the reason, why BSD license still exists, right?
Besides, remote login (SSH, with X11 or without) is much more convinient, secure and economical way for remote troubleshooting, comparing to M$ Terminal Server or any other VNC.
No need to mention that having available source you can customize Linux system from top to bottom, from boot to monitoring. That's a real flexibility and customization. And no need to mention that you will not pay a fee for MSDN and other devlopement tools.
Speaking about money - why would taxpayers want to pay Microsoft for licenses when Microsoft keeps screwing users' right up, while there is the easy, reliable, secure and flexible choice?
That is actually a good idea. It will require a more advanced GDM, but that is not a big problem to to redesign it, adding some self-registration forms.
If some installations will require Smart Card, there should not be a problem to integrate GDM with a card reader as well.
The only problem I see is in potential overflow of the user base. But I think that some database-beckended LDAP (OpenLDAP with PostgreSQL) will solve the issue.
Show me use cases, styles, patterns and examples of developing web applications with AxKit. Same about Redland, which suffers from the lack of documentation.
This book just repeats about XML what was already said in other books.
Or rather get another language. It's not difficult to guess that it should be Python.
You cannot hack on Java - you change the task requirements to fit all the limitation, restrictions of the language and of proprietary frameworks. Your hacks on Ruby will be very limited and immature. Your Tcl hacks will be same unmaintainable with a grown project size, although at least you will be able to read your code.
OCaml, Haskell, Oz and Erlang are still too exotic for Linux/BSD world. Although, when I've tried them I've got a real and fresh entertainment. However, there is a real lack of good libraries. Lisp and Scheme have the same problem.
Conclusion: writing over-obfuscated code was not in the job requirements. Pick the right tool for your job.
That was a key phrase. Most of programmers (open-source ones) love Emacs. Most of admins love Vi. The reason? Different tasks, a different style of thinking, sometimes even a different education.
... at least (and mostly at most) one time: write after the system installation is completed to edit Makefile or some just in order to comile Emacs or Xemacs. Right after that - Emacs (or Xemacs) forever.
This the only thing I still cannot find in Emacs. But I'll keep trying, it must be mentioned somewhere in *info* ...
OfB: The GNOME Project recently released the second major version of its desktop. Have you had a chance to look at this desktop? Briefly, what are you thoughts on the other available GNU/Linux desktops?
AFP: Actually, Tim, I do not concern myself with using other FS / OS (Free Software / Open Source) desktops very much. This protects me from having to answer questions like this one that involve making comparisons . I can just honestly answer, "I don't know about XYZ," and leave it at that.
I don't see KDE as having competition with these desktops as a primary motivator or purpose. What KDE tries to do is to be the best it can be, and to provide a nice, easy-to-use alternative for others. The main interaction I see with other desktops centers around a mailing list and website established for discussing potential desktop standards.
How do you intend to provide a nice, easy-to-use alternative for others if you avoid making comparisons ?
XSLT separates aspects using different templates. There is no problem with sessions (I have it in servlets) and DB connectivity (XSLT extensions work fine for it).
With XSLT I can cache (save on the disk) XML (or HTML) output (in fact - every output) of intermediate tiers - that may give a very great perfomance improvement if you do it right. Can you do it with EJB?
So, does it mean that if I know more than only Java (if I know also XSLT) then Cocoon or the other XSLT frameworks are more appropriate for those scenarios, which do not require EJB explicitely? Is this the real bottom line - to use EJB only if it is required to connect to pre-required 3rd party EJB components?
Speaking about Java, with EJB I am limited to Java . Some people love Java for OOP
(especiaally after C, Perl and Visual Basic), some people hate it for its imperative paradigm (especially after Lisp, ML, Haskell, OZ, Erlang and Mercury). With XSLT I can use any language with XSLT binding. Or even any combination of languages: Perl, Tcl, Python, some of Lisps or any others (with XSLT). Why would I do it? Again - to meet a combination of specific scenarios. For example, Java is too bad to work with OS. Another bottom line. It seems to me that EJB has very poor interoperability. You buy EJB and you are a poisoned slave of Java.Let's put it then in anoter way:
If I write the web application from scratch and I don't have any other infrastructure yet (besides, probably, SQL/JDBC database), then what kind of JBoss (or other EJB servers) would I need comparing to a standalone installation of Tomcat?
The installation of JBoss requires more time and efforts than the installtion of a standalone Tomcat. The development with EJB requires drammatically more time and effort than the development of servlets, especially, servlets with XSLT or other template toolkits. So, how would such diference be compensated?
The problem with Lisp is more than that: most of programmers are not educated (in terms of CS theories) enough to understand FP. That's also the reason why XSLT is still not popular. By the way, there is XSLT for Java, C, Tcl, Perl and Python. Google doesn't find any XSLT for Lisp. Actually, Google doesn't find much of good modern libraries for Lisp. And those available - they work only on some implementations. Forget about portability.
Scheme, having Lisp-like syntax and same pradigms, has the same problem as Lisp. Also, Scheme in avergae requires not so high level of CS education as Lisp does. And Scheme is much better scalable down: VM startup time is really short, especially in "tiny" implementations. And, of course, the portability of Scheme makes it much more attractive: I have Scheme in both open source licenses (GPL and BSD) for all platforms I work with (Linux/86, Linux/PPC, Win32/Cygwin, MacOS/X). Personaly, the only problem I have with Scheme - there is not enough of libraries.
I would better consider Python, as it is a language combining both imperative and functional programming paradigms, and at the same time having not-bad OOP model.
Plus, Python has pretty good various libraries (OS, web, databases, regexps, RDF, XSLT) and a very good web application server (Zope). Would Lisp has such libraries and application (available in open source) - the situation might be different today.
You are right. Most of software development is performed using very primitive tools. Professional software developers prefer either VB or Java, mistaking professional programming tools (which Java and VB are not) with programming tools professionally marketted (by MS and Sun).
Unfortunately, Linux faces the same problem. For example RBAC is well known for awhile, but for Linux it's still in experimental dreams. Python was proved as the best scripting and OS-automation language, but sysadmins still keep creating write-only Perl kludges. Long time ago CVS was proved as too primitive for serios and complex development projects, but alternative versioning systems still are not popular. RPM is known as the most primitive package management tool, but Gentoo's Portage was even not considered for LSB.
Too bad, the world doesn't love the best. The world loves tools, which everyone can understand quickly. Everyone, including uneducated ones.
Our company seriously considers Gentoo as it helps to build a Linux distro (or two) customized for specific corporate needs. Our research shows that with RPM or DEB we'd spend more resources on creating and supporting own distros.
What's wrong with Haskell and is it related here?
I assume we talk about the same language