This item is to explore the idea of installing some sort of existing, open-source blogging package on Grex. Does any such thing exist and is it supportable in Grex's environment?113 responses total.
My motivation for starting this page is that last night, I ran across the LiveJournal pages for two more people who used to be active in Grex BBS and party.
Well, we could start by removing the restriction on CGI.
Only if we want to be invaded by an army of phishers..
The only open source blogging package that I know much about is Wordpress. For this, we would need to install PHP and give users access to it. I imagine that the security implications of user access to PHP are similar to CGI access. I believe that Jan Wolter is working on blogging support for Backtalk (and by implication, Fronttalk), but I don't know the current status of that project.
Can we move to a real operating system (i.e. that supports Java)? I dare say, I would be writing a lot more software (and a lot of cool software already exists out there) for such a platform. It seems OpenBSD was chosen primarily because of its purported security (note well, my background is in security), but this was neither absolutely necessary nor wise in terms of software applications available, stability, nor support.
There is some free online tax software that requires java, but I don't know of any text browser that supports it. What would the ordinary user of grex do with java? Most of us don't write programs here.
The coolest web applications and libraries for software development are in Java. And, I'm sorry to say this to you Sindi but 99% of the Grex world (or more?) likes the GUI web :) Nevetheless, Java has huge support for text only interfaces, including console and web browser.
Could links at grex be set up to work with java? Why would someone writing programs for use in a GUI compile them at grex, which is text-only? Are you using the same OS on your own computer?
Java is a very flexible language, and has libraries for just about everything imaginable. It is also probably the most ( (popular) AND (most widespreadly taught) ) language today. A lot of text-only interfacing programs could be written in Java for Grex, but also a lot of webfacing software (including blogs and portlets) could be "easily" assembled from existing open-source efforts. I use Windows XP, Mac OS X, Linux variants and Solaris (at home and work) - all of these platforms support Java out of the "box". If we are to modernise, I think we need to move to a platform that is more flexible and has a greater community support base than OpenBSD. Mac OS X 10.3.9+, Linux, or Solaris 10 would all be better solutions for Grex then OpenBSD (the latter two are free, Max OS X is a small cost - about $120 US but I would happily donate a version of it (I have both Panther and Tiger releases of Max OS X)). Moreover, all existing C and Perl centric software on Grex would port without too many dramas to either of these three platforms.
I am surprised to learn that Grex doesn't have a java compiler and runtime environment.
What is a Java plugin - is it the 13MB file I found somewhere? I am told I need it to use one website (free online tax filing).
http://java.sun.com/j2se/reference/faqs/index.html The OpenBSD architecture is not supported by Sun/Java.
FreeBSD also has a rather complete port of the JRE, I believe.
I've installed Java on FreeBSD before. I believe I used the ports. It's kind of complicated, and you have to compile all sorts of files. It took hours ; I ended up putting my laptop beside my window because it kept overheating. I never bothered downloading the JRE for windows once i installed it on FreeBSD.
re #12: Not natively, but it appears there's a port of Sun's java, or one can choose to use jikes.
If an OS doesn't natively support Java, it is really not worth hacking it - and especially frustrating trying to write cool applications with a limited JVM.
What is a JRE, a JVM, or a Jike?
JRE - Java Runtime Environment JVM - Java Virtual Machine jikes is a Java compiler
Which one is the 'netscape java plugin' that is used with Opera to access websites requiring Java? Or where do I find a java plugin for linux? Is JRE similar to solibs?
The Java Plugin is now part of the Java Runtime Environment (JRE), and establishes a connection between popular web browsers and the Java platform. In other words, the Java Virtual Machine - the engine room/translation mechanism - of the Java language is utilised (by whatever interface) to enable Java programs to be embedded and interpreted in web browsers. I recommend you make google your friend (and stick to modern GUI-based browsers). More specifically to your requirements, see http://www.opera.com/support/search/supsearch.dml?index=459
JRE has nothing to do with solibs.
JRE for linux is just under 15MB compressed package. It is quicker to do my taxes with a solar-powered calculator. The time consuming part was assembling the information to be entered. What types of web pages require java besides tax software?
If you used *modern* technology, you would be surprised ***rolls eyes***
actually ; she probably wouldn't be. i almost exclusively use windows for web browsing now, and don't have the JRE for windows installed (i installed it for FreeBSD). most of the cool stuff is flash junk ; i've only come across some java junk that i missed out on.
Yep, but I imagine flash is native compiled not interpreted. Moreover, Flash is just presentation layer-oriented. Java is for all tiers. The least useful parts of Java are presentation, in my experiences working and programming in the language.
Is there a mini-java somewhere that does not waste space on graphics? I don't understand why the government does not provide free software for filing taxes, which would save them the cost of processing returns filled out by hand. Re 23 - no matter what age computer I use to download, it won't make the modem any faster. It would take me more time to go to the public library and download the file there and transfer to a 'modern' USB card reader or camera with card in it, than to do a few calculations at home. Does grex have any graphics conversion software? Jim sent someone a pcx file that he made from his CAD program because it is 'universal' and they don't know how to view it. Maybe a graphical browser could handle it?
i think you guys have confused her into thinking that java and web browsing are one and the same :(
http://nanoblogger.sourceforge.net/ "NanoBlogger is a small weblog engine written in Bash for the command line. It uses common UNIX tools such as cat, grep, and sed to create static HTML content. It's free to use and modify under the GNU General Public License."
I was under the impression that janc was working on a backtalk blogosphere, is he not>
Yes, I have been working on a new blog interface for backtalk. Progress
has not been too fast, but I hope to be able to put more work in soon.
The idea would be that we would create "blog" confererences for users
upon request. These would basically be ordinary Picospan type
conferences, but with a few differences. First, the fairwitnesses would
have more power in them than the have in standard Grex conferences.
Second, there would be a short URL you could go to where you would be
viewing the conference through the "sage" interface, which presents the
conference as a blog.
For instance, if I started a Grex blog, it might be the "janc"
conference. You could read it from Fronttalk by doing "join janc" or
you could read it from Abalone or Pistachio like any other conference,
but the more normal way to access it would be to go to
"http://www.cyberspace.org/janc/", in which case you'd be reading the
conference through the sage interface, which would look pretty much
exactly like a standard blog. Actually, I'd love it if we could do
"janc.cyberspace.org" but don't know if we can. The way it works is
that each item appears as a blog entry. Under the text of each item,
there would be a comments link. Clicking on that, would give you the
list of responses to the item.
The fairwitnesses of these blog conferences would have much more control
over their conferences than those of standard conferences. It would be
treated as a conference that they own and that they fully control. Some
specifics:
- The default setting for a blog conference would be to allow only
the fairwitnesses to post new items (blog entries). The fair
witnesses would be able to change this, allowing any set of users
they want to post items.
- The right to post responses could be also be controlled. A very
common setting would be to allow anyone to post, without even
requiring them to have a Grex account. Or you could restrict it
to Grex accounts, or only a list of specific Grex accounts.
- Normally blogs would allow anonymous reading, so people don't need
Grex accounts to read the blog. But that also can be restricted to
Grex users or to a subset of Grex users.
- Fairwitnesses of blog conferences could determine if users can
edit their past postings.
- Fairwitnesses of blog conferences can delete blog entries, comments
or the whole blog without restriction.
They'd also have deep control over the look and feel of the blog.
Colors, fonts, background images, sidebars with lists of links, sidebars
with calendars to access past postings, etc, etc. My aim is to make it
possible to make the blog closely match the appearance of just about any
other blog on the web. The sage interface includes many admin pages for
controlling the look and feel. You can create multiple "skins" and
allow users to use any one of them to view the conference (one would be
the default skin) or you can read any blog using any system "skin".
There will be full support for permalinks, RSS, trackback, and pingback.
But it's only about half built. The built half is mostly underlying
infra-structure, like tools to create, edit and interpret skins.
It also will not work with Picospan. Picospan doesn't understand
concepts like "only the fairwitness can post items".
I can't really say when the first usuable version will be done. I'm
expecting to be able to put in some more work on it in the coming week.
It sounds really neat.
I second that.
i third with our lovely ladies
Sounds extremely cool. Are you using CSS to implement look-and-feel?
How about Ajax?
IT SMELLS TOO MUCH LIKE SEMEN< AHAHAHAha
Ajax is most appropriately used for applications requiring immediate data rendering like with Google maps. Otherwise, its a waste of resources IMHO.
but why does it smell so much like semen. :(
37: You must be a great engineer. But you'd suck ass as a designer with an attitude like that.
Oh, map rendering --- I have to "play" (code in) with that stuff (amongst a mix of other stuff!) over the next few months!
Re 37: Its funny you say that. I'm currently taking a web design class, and am having a hard time not throwing up looking at the javascript code they're having us write so an image changes when your mouse hovers over it. :)
Maybe the code could be improved. I could think some Ajaxish functionality that would be nice for blogging or conferencing. For example, click on a link to a previous response and have the response open in-place without reloading the whole page. Then click on something to have the response disappear.
Yeah, I agree with John. More ajax would be extremely cool. It's not on the top of my agenda though. I also don't think this should freeze the idea of using alternate blogging software. I haven't exactly promised a delivery date on this.
From what I have read, your design and intended blogging functionality sounds very good Jan and will integrate well - look and feel wise - with Grex's existing software base so no rush - it will be well worth it. <begin-rant> When we wake up to ourselves and move to an OS that supports Java out-of-the-box, assembling and customising new components (from existing OSS efforts) will also assist making Grex more attractive for new users. </begin-rant> Has anyone taken a look at Solaris 10? It is seriously very nice! I was so impressed with my research that I have ordered the full boxed set (with development tools and auxilliary software), and am also seriously considering purchasing a Sun workstation - not compulsory for running Solaris 10, but certainly supported better by the OS than my existing Intel and Apple hardware. I have made a quote for the Sun Ultra 20 Workstation with Opteron 144 Processor - 64-bit computing, very nice.
Washtenaw Community College is running Solaris (I think it is 10). We found and are using Kermit compiled specifically for it. They have a two year old lynx as well. Jim has a shell account. I got up to 170K/sec downloads to his account, compared with 10-15K when grex is not too busy.
I got an amazing quote (proposed by me:) for a Sun Ultra 20 Workstation, see http://www.sun.com/desktop/workstation/ultra20/index.jsp so I'm going to go ahead and purchase it. I can run Solaris 10, Windows XP, and Linux out of the box on it. Will be an awesome Java development and server deployment platform. Who knows, I might even host a minimal Grex shell facility from it (without dialins:) Grex *really* needs to migrate to a true operating system, not a cutdown one without Java like OpenBSD -- Solaris 10 and Mac OS X (Darwin) are good candidates.
Why does Grex need Java?
Well, unless you want to continue living in the last century..... However, if you *seriously* want to consider cool software, rapid development, education, now and the future you *MUST* at least support Java. Not that living in the last century is to be frowned upon, but I thought the consensus was we want to modernise Grex and make it a more attractive place, especially for newcomers.
What would Grex use Java for?
Just to have it. You know, to be all cool and stuff..
I never thought a bunch of techie-minded people could continue living with their blinkers on for so long, but I should not be so surprised by now. It is no wonder that the large majority of staff and member base on Grex are of the older generation, bought up on C (which, sure, has a place and will never be outsourced). But, you insist on missing the boat by living in the dark ages - that's all cool with me, I have not been overly interested in Grex or its dieing conferences in many years now. I'm totally happy to offer my services elsewhere.
I'm not on staff, but I am a member, and I don't like Java -- and I'm not of "the older generation," since I'm under 21. I primarily don't like it because I often find myself on machines with limited bandwidth, limited memory, and/or limited CPU speed -- and "limited" might be what you think of when you say "obsolete" (the fastest computer I've ever owned is 350MHz) -- and Java wastes all of them.
Re: #52. Are you trying to make a point, or just insult people?
I think #52 is saying that java is resource intensive and therefore not suitable for a slow crowded system like grex.
I misspoke myself. The comments in #53 were addressed to the writer of #51.
#52 appears to confuse Java, the programming language, with Java applets, executable code collections which are most often run embedded in a web browser. Java has plenty of other uses, and is, in fact, a useful technology, which is why I find it odd that mic can't put together a more convincing argument in its favor.
i confused twenex with scholar in resp:53. it tripped me out to think that KEESAN was responding to SCHOLAR>< and like ; whoa.
I think twenex's name is dumb. After all, planes don't actually FLY at the airports! They just land there and hang out. :(
Java is an all right programming language, but my sense of it is that its popularity has declined in the last few years. All in all, it is, in some senses, an architectural step backwards (I mean, why couldn't they just gut it up and make integers objects, already? Still trying too hard for that efficiency straw man). A more interesting technology to me is Ruby or Python or another scripting language. If you want to have fun, that's where it's at. That said, I'd agree that another operating system that supported more or better software wouldn't be a bad thing for grex.
Java, which I have been associated with professionally for nearly a decade, continues to grow in popularity. You can earn really large amounts of money if you have advanced Java skills - particularly scarce at the moment, in terms of talented people versus projects in industry, are talented people in the J2EE arena. The supply of work is vastly outnumbering the talented/skilled pool set. Java is massive - from smart portable devices to inter-enterprise applications - Java is thriving. One of the major resources I believe where Grex can benefit from offering Java is attracting and assisting budding Java developers (compared to unix shell script and C programming skills, the market is 10-fold+ after Java skills). Some of the coolest web applications can be built for Grex using Java technologies such as JSP, JDBC, and existing opensource codebases - abundant! - out there. The level of coolness and time to build such applications in Java vastly surpasses anything which can be built in C, Perl, Python, Ruby - I have worked with them all. In some of the coolest operating systems, such as Solaris 10, you can easily constrain users/processes/applications to a size of the resource pool (such as RAM). I think I have responded, in brief, to everyones major points.
Pros and cons of Java vs. other languages aside, I think it's part of Grex's public service mission to install something as widely used as Java if we can. Can anybody think of a reason why I shouldn't install kaffe-1.0.6 here? It's a Java package for OpenBSD 3.8. See http://www.openbsd.org/3.8_packages/i386/kaffe-1.0.6.tgz-long.html (By the way, if anyone has anything to say about blogs, this is the "Brainstorming: Grex Blogs" item. This announcement brought to you as a public service.)
The greatest advantage that I can think of to installing Java on grex is that tools available in Java make unit testing possible for any coding projects that are considered for system-wide deployment on Grex. Unit testing is a way of programming which, if done properly, can identify and thereby allow the complete elimination of buggy code prior to deployment. If Grex installs a Java framework to support unit testing, it may make it much easier for people to contribute tools and applications in a way that the staff will feel comfortable adding capabilities to the system without risking a lot of follow-up work tracking down and fixing bugs.
I'm a terrible person. :(
I tried to address Unit Testing with grexsoft, but no one but me was ever interested. I take exception to Mic's assertion that Java is more efficient to program in (as opposed to machine efficiency) than, say, Python or Ruby. I do note that, according to a cursory search on Freshmeat, the union of Ruby, Python, and Perl projects has the about a thousand more projects in it than the set of Java related projects (at around 4600 projects or so; that's about the same as the number of C++ projects, and probably half the number of C projects). But that's neither here nor there. As a system, we should be trying to get a current, modern JRE and development environment running on grex. That means an operating system with developers more likely to be more responsive than, ``you're on your own'' or ``we don't do that here, and neither should you.''
(Actually, I take that back; Bruce Howard did some work with integrating grexsoft into grexdoc, but I'm not sure how it ever turned out.)
Yay, finally some clearer thinking from folk. Ruby is a VERY promising language, Dan, especially Ruby on Rails framework... BUT, it seriously cannot compete with Java now or in the next decade.
Well, let's agree to disagree.
No problemo.
Hmmm. I installed the kaffe-1.0.6.tgz package, but the only output of the javac and java commands seems to be core dumps... :(
(regarding #68; Well, except that we are agreed that grex needs to move to a better supported OS!) Regarding #69; Kaffe is also no where near the JDK in terms of sophistification. OpenBSD really doesn't support a Java that's worthy of the title.
Geez, Dan - you're clever and street wise, too :)
What can I say? It was all those years living on the lower east side. :-)
I think one of the main promises of Java was machine independence. You could implement a package with functionality like, say, Microsoft Money, and have it run transparently on any machine or OS. The lack of an adequate Java for OpenBSD is a bad sign for OpenBSD, but it is also a bad sign for Java. OpenBSD isn't really very different from Linux or Solaris or FreeBSD, so I assume that the roadblocks to Java are primarily legal. If there are legal encumberances on Java so great that a version for OpenBSD cannot be easily made available, then I think that throws into question Java practical machine independence.
I have done quite a bit of work on the backtalk/sage interface this week. Mostly I've been working on the configuration tools, which are fairly hard to design, since I'm going for massive configurability. Still have a ways to go before I can demo anything though.
Sun openly publishes its JVM specification. It is not obliged, and it would not make good business sense, for it to make a version of its JVM for every available platform. It has done so for the three most important platforms - Windows (greatest user base), Linux (fastest growing, open-source), and Solaris (its own impressive OS). The fact that some group has not ported it properly to OpenBSD, in my opinion, is more a reflection on the lack of interest in OpenBSD as a a development environment. From what I know (and I am coming from a security background), OpenBSD's primary use is as the core of Bastion firewalls. Thus, in conclusion - (1) There is no legal reason, that I am aware of, that prevents a port to OpenBSD or any platform of the JVM, and (2) OpenBSD is NOT, both seen by many and in reality, a serious development platform.
I think the lack of Java on OpenBSD is, as Mic said, more a reflection of the status (or lack thereof) of OpenBSD in the eyes of those in a position to make a Java port. But it also stems from some technical failings of OpenBSD, like the lack of a real, kernel-level POSIX compliant threads implementation. Yeah, there's a library that sort of does the right thing by turning everything into non-blocking calls and trying to multiplex, but the entire system can still freeze on some system calls. Java is quite complex, and porting it to a new platform, particularly one only subtly different from another that's well supported, is tricky.
Re #75: hey spooked, not to be rude, that's not the intention, but reading this thread and all that about Java on grex, I'll say: --> you are pissing me off with Java :) , but that's just me... --> I'm no software engineer, nor computer professional (not now at least) but well the topic Java and BSD's is an old one. The whole availability of JVM/JRE native engines outside Solaris/Win32/Linux/Aix/Irix/Hp-Ux/UnixWare and to some extend FreeBSD, is because Sun imposed license limiting redistribution. It's all on Sun's side. Here's a fucking native and working JVM/JRE for OpenBSD-i386 (was compiled on 3.7 but runs as well on 3.8), demos and all: http://bsd.abravo.org/JAVA/OpenBSD/3.7/i386/jdk-1.4.2p3.tgz it's easily buidable by a simple "make" in the so-called OpenBSD ports system.For NetBSD it's in the wip-pkgsrc.A binary tarball: http://bsd.abravo.org/JAVA/NetBSD/NetBSD-2.1/i386/jdk14-1.4.2.7.tgz The build process is exactly the same than in the Sun specs. About Solaris/OpenSolaris: the current JVM builds upon Xsun + Motif, which makes licensing troubles, because Motif which is needed for the build is no free stuff.One can build with Lesstif and Xorg, well that's yet another story....Just to point out, Sun can still do better. So the OpenBSD tarball I provide in the link is, stricto sensu, not downloadable.Yet only me and the readers here will know, and anyways, I don't care, Sun can well sue me if they want. The point is: it's a native JVM (and the corresponding JRE) v. 1.4.2, so the question is over: native OpenBSD JVM does exist and work.
Does it *all* work, or just parts? Usually, that's the issue. For instance, threads and swing may not work. Also, Java 1.5 really is much better.... I also think it's UNfair to say that it's all licensing on the Sun side.
I still haven't got a satisfactory answer to the question: "why should Grex (or anyone) bother with Java, especially if they've no need or desire to support www applications?"
Anyone who has to resort to, nevertheless start with, abusive language in an attempt to convey an intellgent opinion would suggest their lack of credibility. I stopped reading shortly after starting that post. Bad language is often a sign of (1) bitterness, (2) ignorance, or (3) both.
I fail to see the "abusive language" in #79. Sounds more like you're covering up the fact that the only reason you've latched on to Java is 'cos it's flavour of the month. In which case, you're about four or five years too late.
<no comment> The name says it all.
Well, I don't know where you're from, but round here there are those things called "jokes". They're quite difficult to explain if you don't understand them already.
Re #78: well, I'm not using OpenBSD-i386 much by now, will have to boot one.But the Java engine did work just as expected for me: Swing and popular Java graphical or non-graphical apps, the plugin didn't crash firefox, etc. The 1.5 version doesn't compile by now, but is on the way for FreeBSD. Well, as for the Sun side, they are maybe not all evil,an important issue was about the compliance test (TCK).It's ok to avoid any pile of braces to be called Java, but on the other hand many people on the BSD side are working hard to provide patches to make things work. Re #79: <I still haven't got a satisfactory answer to the question: "why should Grex(or anyone) bother with Java, especially if they've no need or desire to support www applications?"> exactly my question too. Re #80: (2)ignorance: indeed: some Java specialist didn't seem to know that OpenBSD has a native JVM, with bells and whistles, and Duke waving hands, and surfing the waves...
I would not use a hack. And, I can guarantee it does not work as I would expect a fully-compliant JVM to work, even without looking at it.
A screenshot of an OpenBSD-3.8-i386, running few java apps: http://www.abravo.org/misc/obsd_snapshot.jpg a Mozilla connected to Freenet showing the environment: OS=openbsd38 JVM=SUN, HotSpot, version 1.4.2.It says it: vendor=SUN, it's the SUN code build locally for me only, because licensing... below, another Mozilla window showing the Sun Java test page, with Duke dancing.The other apps running: NetBeans-4.1, the JAP anonymizer, the Java2D demo (again: dancing Duke), bottom left: Jedit, very left: Arachnopilia html editor, top: Jftp, plus a couple other not visible... For development, you can run too Ant, Eclipse, etc. ---------- the Java story is a mixture of politic and technical issues. SUN recognizes a JVM when it passes the compliance suite, TCK (former JCK).Otherwise binaries are not redistribuable. The problem is to submit a native JVM (like the OpenBSD one). SUN is changing its licensing schemes every couple years. Up to 2005, FreeBSD (and for a shorter period of time NetBSD) were licensees, under the "scholarship" cheaper agreement.The patchset of the FreeBSD people, which does work for Net and Open, applied to the Java source (SCSL), the use of linux javac for bootstrap and the Lesstif headers, did build a JVM/JRE/JDK that SUN did aknowledge.That was the case for 1.1, 1.2, 1.3. Binaries were distributable as genuine Java. Then, SUN told FreeBSD they were revoking the license,unilateraly, in the turmoil of their legal revamping.So not on a technical (software) ground. Ok, the current state of things is that you can freely ($0) register as individual member in the JCP (the "community" project) and download the TCK suite and summit for compliance approval.BUT the license you get is nominative, ie. only for you (you share alone with yourself...) To get the right to publish binary kits you must purchase $2000 or $5000 membership (non-profit or commercial).Kind of getting like "OEM".Still SUN holds the right to allow or revoke the compliance label anytime. Well, *-BSD are not Microsoft... Practically: is you are a webhoster, a business, and will run OpenBSD: --> you can't, for instance, run Jakarta/Tomcat on all you boxes, by installing the same binary (JVM) on all of them.Instead you must build Java locally on every box... --> you can't expect official Java support So, maybe SUN wants to avoid BSD getting in a market where Linux has already got to outsold Solaris. If SUN has nothing to fear they can well ease the TCK access and compliance process to the BSD folk, without losing on the technical side (software consistency)
Cross says OpenBSD lacks recognition in the eye of "those in a position to make a Java port". That's certainly true. My point however, is that it is a problem that such people exist. Who are "those in a position to make a Perl port?" "Those in a position to make a GCC Port?" Firefox? Apache? Anybody, that's who. There's no select club whose recognition you have to earn to get a port of these pacages. Java will get there, I'm sure. But it's a limitation on the universal applicability of the language.
There's a difference. Those other packages are `pure open source.' Java's licensing structure is, as Antonio points out, much more complex. Those in a position to do an OpenBSD port are those who are so licensed by Sun.
re #88: And that difference is exactly the problem Jan's pointing to.
I think we all agree OpenBSD is not a mainstream development environment.
Oh, I misread. I thought he was saying quite the opposite.
great news about the Java and BSD stuff: http://www.freebsdfoundation.org/press/20060405-PRrelease.shtml since 5th april 2006 and a new agreement between the FreeBSD Foundation and Sun, Java 1.5 is officially available as binary tarball (jre & jdk/sdk). Which means the maturity of the port on FreeBSD (x86) was good enough to get the Sun technical blessing.The rest was political/legal stuff.In short it's fully Java for FreeBSD. So, on the others main BSDs, Net and Open, only the second aspect (political) is still not solved. (Java builds uses all the same FreeBSD patchset + minor system dependent diffs)
I'd say that's an excellent reason to switch to FreeBSD instead of kicking around with clunky old OpenBSD.
I would just like to say that I have been so impressed with FreeBSD that I've begun using it at work. It will be replacing our LAMP-based intranet system, and our Linux-based internet proxy. These are the things I've been most impressed with: 1) Directory heirarchy. This is it folks. The all software that isn't part of the base OS is in /usr/local. I love it. It makes things just so much easier then wondering "is apache in /var/www, /usr/www, /srv/www, /usr/local/www, or /home/www?" 2) Ports. Ports is about as easy to use as Debian's apt, and a whole lost easier than SuSE's YaST. 3) Performance. Even on slower systems, FreeBSD runs faaaast.
I STILL don't know why Grex needs Java. isn't Java only useful in browsers? Re: #94. Gentoo Linux addresses all your concerns there, except (1). Interesting that you say "ports are easir to use than SuSE's YaST." Isn't YaST supposed to be the yardstick for Linux desktop software installation usability?
re #95: > I STILL don't know why Grex needs Java. isn't Java only > useful in browsers? In a word: no. In several words: no, no, no, no, NO. Java isn't restricted to web applets any more than perl is only useful for writing back-end web-server scripts.
I think that Java on grex would be interesting, but I don't go as far as Mic in my accolades for it as a language.
That's probably because you don't have as much exposure to using it, Dan. Look, no language is the bees-end for every application. We are building a very complex Geo-spatial mapping application currently. Among the languages we use (for different purposes in the application) are: - Java (core business logic, used extensively within all 3 MVC tiers including querying/updating to Oracle 10g database's tables/views/synonyms/indexes (incl. geospatial indexes)/sequences/etc) - PL/SQL (for stored procedures including network tracing of Australia's major telecommunication network infrastructure interfacing for engineering complications with proposed powerline networks - from power companies, rail companies, etc) - Crystal suite (for complex/flexible reporting) - Javascript (*gasp* for those few client-side nicities people just can't seem to live wihout) In any non-trivial application of any considerable size, you will have to use a combination of different languages, tools, and people skill resources - otherwise you will never finish the project in a timely fashion and reinvent the world in a language that is best used for other purposes. It not only makes working in IT exciting, but also ensures those who are flexible and quick learners will always be in very high demand.
I need some .NET libraries installed...
(well, me think latest SunOS-4.1.x what good enough for Grex.Powered by some ss20 quad hypersparc or some sparcserver 1000 8x cpu for instance.)
OMG! We forgot APL and PL/1! ;-)
See http://www.citidel.org/?op=getobj&identifier=oai:ACMDL:articles.808118 - nice high-level, flexible language/s
Regarding #98; Actally, it's because I probably have *more* exposure to it and
a lot of other languages. There are certain things in Java that are just poor
design decisions. Among them:
1) (At least initially) lack of a well-designed standard library.
Tell me why each new release of Java seems to reinvent basic libraries? We
went from AWT to Swing. From no threads to coroutine based threads with
monitors for concurrency. From one set of collections to the other.
2) Why aren't `primitive' types objects? Please don't tell me efficiency.
But this means that you can't have a generic, object based container
library that contains int's. You have to wrap them in Integers. This also
means that arrays aren't objects; they're primitive types. C++ made this
mistake, and now we have to pay for it with templates. It's interesting to
note that smalltalk had everything as an object, and ran with good
performance and much smaller hardware than Java ever ran on. So it's not
efficiency.
3) Speaking of efficiency.... Why go with a stack based VM? That sort
of thing just doesn't map well onto actual hardware, which is usually based
on register machine models. Why not go with something like the Dis virtual
machine used in the Inferno system? Based on a memory to memory model, the
VM maps well onto current instruction sets. Thus, it's easy to write a JIT
compiler for it which gives really pretty good performance. With Java, the
compiler is simple (since the ``machine code'' is very similar to the ADT's
the compiler spits out - one of the nicities of the stack based VM), but
the JIT is rather more complex. This makes Java code have a high startup
cost, which is rather annoying. I'd rather Josling et al had taken the
middle ground that Phil and Rob did with Inferno.
4) The concurrency model is based on the 1960's style of coroutines and
explicit mutexes. Why not make it based on CSP? Come on, we could have
moved boldly into the 1980's!
5) Java has a high start up and entry cost; it discourages casual programs.
It is difficult to write a one-off program in Java whereas it's almost
trivial in a higher level language like Python or Ruby.
This is just a sampling of the things I think Java is imperfect on; I could go
on. Like I said, I think Java on grex would be interesting, but I don't think
it's a great language. Better than most of its predecessors, it failed to
learn some essential lessons from some of the better ones, and the result has
been an often inconsistent and a moving target. The fact that they just added
a form of ``for (item in someset) { ... }'' syntax in Java 1.5 tells me they
didn't quite think it through the first time, even though a lot of other
languages have been doing similar things for a *long* time (e.g., smalltalk
and awk, which both predate Java and have similar mechanisms. While awk
doesn't have the semantic expressiveness of the type system that Java does,
smalltalk certainly does).
Mic, please don't insult me by saying it's just because I don't know enough
about it; I've implemented enough things of sufficiently large scale that I
have some idea of what I'm talking about when it comes to language design.
I think we could open a whole new conference on language design, libraries, pros and cons... if you look at any language deep enough of course it's going to have weaknesses and places where it excels... It's like anything - including programmers, you never find a perfect programmer (just ask any team leader) - like people, we/languages all have pros/cons and what it boils down to is a tradeoff. You can't get perfect, you can only strive to do better (improve, but improvement is naturally a slow process, especially the older/larger a person/language grows -- and, in that respect Java continues to evolve and improve itself, beyond debate.
That's true, but what I'm trying to point out is that a lot of the
`improvements' that have been made to Java are to make up for defenciencies
in the initial language design. Some of these changes are clunky. Consider
the following, added in Java 1.5:
public void manipulate_things(Collection<Thing> things) {
for (Thing thing : things) {
thing.manipulate();
}
}
This is equivalent to the following:
// Note how in Java before 1.5, I couldn't use generics, so there
// wasn't any type checking on what was in things....
public void manipulate_things(Collection things) {
Iterator i = things.iterator();
while (i.hasNext()) {
Thing thing = i.next();
thing.manipulate();
}
}
Well. The former is certainly prettier (and safer) than the latter, but now I
have this syntax (for (Thing thing : things)) that's built into the language
but relies on an interface provided by a library. Not a good separation of
functionality, and the language and library are no longer orthogonal.
Other languages tend to do better (for instance, Ruby's blocks do away with
the need for a generalized for loop at all - the resultant code is often much,
much cleaner).
And Collections only work on objects, not primitive types. How do I have a
List of int's? I don't; I've got to wrap primitives in object types. Java
1.5 makes this a little more transparent by supporting autoboxing, but it's
still a bit clunky; there was some ambiguity around what happens when you try
to unbox a null reference, for instance (and indeed, what *should* happen
there?). So, now as I iterate over a list of ints, I have to check for null
ints, which is very much non-intuitive. At least with C++, std::set<int> does
something sensible.
Now, like I said, I think Java does a bit better than a lot of its peers.
Overall, for instance, I'd say it's a better language than C++ (just try
putting a polymorphic type into a generic container without using pointers,
contrast Java's references!). But that doesn't make it a great language. Is
it improving? Perhaps; I think some of the `improvements' are debatable. For
instance, maybe the Collections issues would have been solved more elegantly
with the Ruby approach of blocks and iterators. I would argue that a lot of
the improvements are necessary because the designers didn't think through some
of their choices when they were designing the language in the first place. In
particular, the split type system and lack of something like generics in the
beginning have been persistent sources of headaches. Reviewing other
languages like smalltalk and Eiffel (both of which predate Java by a fair
bit) may have eliminated some of these issues.
Yeah, Dan, you make some good points but you just have to get on using the language as is... I can tell you some horrible (NIGHTMARE) stories of outdated technology investment in our major telco... but, it won't help bitching about it, won't make the project magically finish on or near on time. Remember, technology often - like most things in life - is about politics as much as good design.
Right. But I was responding to your assertion that my statement that Java wasn't *great* was due to my inexperiene with it, Mic.
My experience working with Java is admittedly limited but I felt when using it that I spent far too much time thinking about the language as opposed to thinking about the problem I was trying to solve. Doubtless that complaint would lessen after a while as one internalizes the language concepts and forms Java-specific coding habits but I agree with the general thrust of Dan's criticisms -- that aspects of Java's design make some things needlessly complicated and that lack of foresight regarding some issues has led to a confusing mess of language revisions and toolkit versions and whatnot.
Thanks, Mike, that accurately summarizes what I was trying to get across.
across...heh
I'm Java incaffeinated, Mike/Dan - which is partly the bias.
Assert.booleanEquals("That was part of what I was saying") ---> true
Assert.booleanEquals("Wasn't trying to infer Dan was Java incompetent, by
any means") ---> 1 == 1
Okay, Mic. :-)
TROGG IS DAVID BLAINE
You have several choices: