Slashdot Mirror

not really ... my home comcast is still ipv4-only. i have to tunnel out to get to v6 space to test http://ipv6.linuxhomepage.com/

Agreed. When I try to browse Slashdot using my Kindle, it is redirected to the mobile version which then goes into an infinite reload loop and never renders. Thank goodness for the Linux Home Page!

This means shared web sites can't make the switch to HTTPS just yet. However, those web sites that own a specific IP address can do it. The more that at least begin to use or allow HTTPS, the better.

Right now if you visit Slashdot's HTTPS URL it redirects you back to clear HTTP. That's where we need to start changing things. Someone who specifically wants their web requests in HTTPS where it can be delivered, should get it.

At least my page delivers in HTTPS, even if it is just a self-signed certificate that causes the browser to ask if you want to do this. I need to get a real signed certificate soon.

But there are problems with table-based designs, first and foremost being user presentation, in the form of increased load times for the increased amount of text, AND because browsers can't render the table until the entire thing is downloaded. I have seen some website that don't come up for quite sometime because their entire 226kb layout is contained within a single outer table, so it doesn't show up on the screen until the whole page is downloaded.

There is nothing inherint in a table that prevents it from being incrementally displayed as it is arriving. You're speaking of a browser issue. I know this is the case because I've seen browsers vary in the way they handle this. I've seen many pages load their tables as they arrive. My own LinuxHomePage does, though that's hard to see because its layout table is just one row and three columns. A better example is here. Of course it helps to speed up layout if everything inside the table has a known layout size as soon as possible. That's one reason why my images in LinuxHomePage have the width and height specified explicitly in the HTML.

I'm glad you don't use JavaScrap in your web sites. I don't either.

On their slow computers, the older browser renders fine. It's the newer browsers with their many deeper layers of object abstracting in the code that run slower on the new browsers. I benchmarked NS4 as 22.5 times slower than NS3 at rendering nested tables. So NS3 can handle my table based pages back to very very slow CPUs. NS6 was more than 4 times slower than NS4. NS3 had a nice tight (although buggy) rendering engine.

Feel free to look at my site and tell me how you would do it. But I want it to generally look the same in my NS4 browser that has CSS disabled for integrity purposes. I'm going to be re-designing the whole site soon, to include customization, so any ideas you have would be nice. But if they include CSS, then I probably won't use that for at least another year or so.

You say to pick one standard and use it? Well, I pick HTML 3.2. So there. Now why didn't I pick any version of CSS, or XHTML? Well, simply put, my goals are to make a site not only work, but work better than just barely working, in older browsers that are still in common use. And right now based on logged User Agent data, that looks like back to Netscape 3 and IE 4. And the goal of a state government, unlike a corporation, is to make things work for all citizens of the state, including poor ones that are given old hand-me-down computers (often donated by those corporations).

CSS certainly has many benefits for the designer. And as long as your target audience is using browsers that support CSS correctly, you should use it. And for many corporations and person web sites, that's fine. Where I think CSS still needs to be avoided is where the goals are so broad that users w/o CSS capable browsers still need to be accomodated. Where we will probably differ in opinion is just how good the site will need to be in say NS4. Some will accept default gray backgrounds, sloppy layout, and mangled color schemes, so long as the text is readable. My goals are higher than that, so the philosophy of doing nothing else but CSS cannot be used since it cannot achieve my goal.

I think you still misunderstand the older computer problem. That older computer can't run a new OS. It can't run a new browser. Or in cases where it can be squeezed in, it's too slow to be comfortable. Try Mozilla on a 25 MHz machine. The older browsers like NS4 and NS3 actually render tables faster. I actually stayed with NS3 for a while back when I was on 100 MHz because NS4 was just too damned slow at rendering tables (I benched NS3 as 22.5 times faster than NS4 on a deeply nested table).

I won't dispute that CSS would be faster than the corresponding same thing in raw HTML. But if you can't get a browser working that does CSS right, or at all, and won't die when it sees it (like NS4 does), then you're basically locked out and have to limit your browsing to what works. Some sites can be made to work in NS4 anyway, but look ugly in the process. Mine will look nice in NS4.

As for coding for different browsers, the only difference I have ever done is graphical vs. non-graphical (e.g. lynx). Look at linuxhomepage.com and see.

My goal, which may not be what the standards set as a goal, is to do the best that a given browser can do with a common set of code. What I end up seeing is stuff like no background color at all in some of these sites in Netscape 4. That's because the background color was put in the stylesheet and NOT put in the HTML. But if it were put in the HTML, then it would still work on both old and new browsers, and work better in the older ones compared to leaving it out.

CSS is the way of the future ...

I'll agree with you on this. Now we need to debate whether CSS is the way of the present.

The reviewer cited a goal that was to make the web site work in as many browsers as possible. The goal statement isn't entirely clear. He needs to define what "work" means. If he's willing to give up looking as good as a given browser can look, in order to achieve standards compliance, and has a goal of merely making sure the text can be see, then his goal is not the same as mine. But I've seen people who do things with this total standards compliance goal and come up with totally a totally crappy site.

As for K10k, I do see a lot of layout on this page, but I can't tell if you've completed it or not. It looks like a nice design, but it lacks content. Here (and scrolled) is what it looks like to me in Netscape 4 (with CSS off, because it is unsafe to browser in NS4 with CSS on due to bugs). I certainly wouldn't call that usable (but like I say, I don't know if this is "under construction" or not ... it looks like a half way done site). I included the scrolled down image of it so that I could also point out the fact that the form elements are out of bounds of what appears to be areas where maybe it isn't intended. I see many sites where the designer tries to fix things to a specific number of pixels, and this simply does not work on the web unless you can make those be images and control them exactly (which can be done for the submit button, but only in a limited way by changing font for the input fields and drop down menus).

What this K10k page does in NS 4 is certainly not what I want to let happen on any web page I design. This page does a lot better in NS 3 and 4, as well as IE 4, 5, and 6, and even Gecko, Konq, and Opera. I'm happy with it because I got what I wanted. Of course it is table driven, so NS 1 is out of luck and will have to use the Lynx version. But at least there is a link to that.

Yes, I'll take a 5% commission on a new Mustang someone buys. But how likely is that to happen through my web page? Of course things like that are decisions I have to make. And I end up having to make that based on the demographics I bring in. Since my web page isn't about cars, or Mustangs, I suspect the probablity to be way too low to be worth it. I'll go with impression ads.

If people come to the site for just content, then why are the designers jerking around with the gloss and flashiness? I do get colors on www.alistapart.com, but the layout is horrible. I don't have that kind of trouble doing layout that works on a wide variety of browsers, and I don't even check the browser type to customize. If you want to know what features are only available in the newer browsers, maybe you should ask the developers of www.alistapart.com what it is they use that won't work on anything but the newer browsers. The features I use seem to be working fine on older browsers.

I just see too many web sites that appear to be more intended to show off the designer's l33t w36 sk1llz that an ability to stick to information and readability. That turns me off from many sites quickly. Things like pointless use of flash will do that. Things like using Javascript to implement a hyperlink will do that.

Oh, and yeah, I am guilty of sticking in some of my own l33t HTML sk1llz on linuxhomepage.com, but at least it works everywhere.

They need to use the right tools for the job. If the job says make it look exactly like this paper brochure, then they have to choose something like a giant image or PDF. Sure, it can be approximated in HTML, but they need to not whine when it fails because a different environment with a different look and feel ends up showing it differently. Do you know how many pixels wide an 18pt font is on my display?

As for XHTML and CSS, they might not be there. Sure, feel free to use them where they are, but don't expect me to have to deal with the problems of some new browser just for your benefit. What if the CEO's cousin's computer ... the one that is so old that it only has 256 colors ... can't even run the new browser at all, and therefore has no XHTML or CSS?

If the designer loses his job working for a PHB, at least now he has a chance to get a decent one. Sure, I can understand he would rather keep the job and make a real honest attempt to accomplish the task in a way that keeps everyone in the company and West BFE happy. But who is to blame when someone reports to the company that the site shows up lousy on some other computer?

You can design for the middle or you can design for the CEO's cousin. If management makes the decision, then the web designer is just doing what he can with what he's allowed to do. The real culprits are the ones that don't allow the web designer to design it as content.

Do you see any XHTML or CSS on http://linuxhomepage.com/? Does it look on your browser today like it looked in Netscape 3 back when I originally designed it?

The links at linuxhomepage.com go direct to the article page.

If someone comes to my site to get information, and if I describe what they might find on the internet, and point to where to find it, and it's a public method of access (e.g. not information on how to crack into someone's server), then I should be allowed to offer this information under the rights of the First Amendment of the Constitution of the United States. A link is nothing more than information, and there is no crime implied by providing it (offering cracking information, for example, might well be a crime).

Why web site owners whine about people linking should be what you fuss about. If they don't like the fact that the HTTP Referer: gives a URL they don't approve of, then they can reprogram their site to deliver something different, or deliver nothing at all if they wish.

This might be different if the links were the kind to trick multitudes of web browsers into improper accesses. For example, if CmdrTaco were to hate some web site out there and wanted to cause it harm, he could stick in a few hundred 1x1 image references to the site's main page right here on slashdot and really clobber them. Imagine slashdot effect multiplied. But this isn't about that kind of linking. This is about the kind of linking that simply directs someone to visit another site for what is there.

And this isn't about copyrights or trademarks. Sure, those things can often be infringed on by those doing the linking. If they improperly copy parts of thet target site, such as using images or icons from there, even just to form the link, then that is an infringement, but it is not the linking issue.

Linking is not at all like spam as long as the information that describes the link is truthful and accurate. If I point to some page at some computer vendor site and say you can get fine warez there, that would be wrong. That should be prohibited. But if I deep link to the Linux section of www.ibm.com, and say "This is IBM's Linux section", and IBM is offering it to the public, then I should be able to. Afterall, all that I am doing is simply saying to whoever visits my site, there is a place that IBM offers this information to the public. If IBM wanted to close it to say just subscribed customers with password access, I'd think someone there would know how to do it. If they don't want the link coming from, say, a Lolita Porn site, they can certainly suppress the link on their end and redirect it to say the main page, or their legal page, or bring up a blank page. I'd think someone there would be able to do it.

The comparison to spam is all wrong. This is NOT a "push" issue like spam is. If I didn't want people to visit my site, I'd take it down.

I just wish I had the resources to build a better system. I know what to do to make it; I just don't have the cash to put it together.

• A backend database/information system.
• A middle enterprise/business logic layer.
• A frontend/presentation layer.

That's a fairly standard model. That's not specific to Java, J2EE, or Tomcat. What you do get is that in some environments, the 2nd and 3rd are not separated (or maybe not very well). PHP comes to mind.

I built this site with PHP in one day and it was my first PHP project. The backend (1st in your list) was written in C and a shell script and not built on a usual SQL DB engine. It just consists of a cron triggered script that fetches backend data with lynx and reformats it with a different C program customized for each site (some in text format and some in RDF which was added later). The PHP code can be seen here.

But I have concluded that fully integrated logic and presentation is not a good thing. And I've also concluded that more than one class of logic can and should exist in a single presentation. The logic to select the banner ad should be separate from the logic to summarize some news on the side rail, while yet different logic selects the main forum body (in an example forum site). I feel all those elements should be discrete reusable elements of logic. The ad banner selector could be used on other pages, for example. The page would then be built for layout and style much as a regular static web page would be, with tag elements to notate where other "sub-presentations" go. Those can then be other static elements, or logic (dynamic) elements.

I have thought this was what JSP was supposed to be about, and the logic elements would be servlets. But I don't see where it has to be done in Java. Now that doesn't mean I hate Java. I admit I dis-like C++, but not Java. I do OO design and code it in C, but I haven't found any real advantage to doing it in C++. But I've done some programming in Pike, which I believe is better OO than C++ (but also has some limitations). Java looks to be the current state of the art in reasonably clean OOL.

The trouble I have with Java is the JVM. I don't feel the whole portable environment thing is necessary for statically maintained applications. What I mean by that is something that stays where it is sufficiently long term to make a compilation worth while (a day). To make downloadable applications to run in a web browser, portability is now more needed since a site needs to be able to deliver something on demand that works on many different platforms. But for this I don't feel that a compiled to byte code environment is the right way to go. If Java had been compiled down to a stack engine environment somewhat like Forth, or maybe just use Forth, then I would have agreed with it.

Basically, my goal for the server side is to have an environment that allows working with elements in the binary format of the host machine compiled from C or Java (for my choices) or any other language (compiled to binary like C++, precompiled like Perl, or interpreted at run time like Bash) that can run on the host, and integrate those as logic elements in a template based server engine. I see Java as a good choice in the system, but I also believe it should be that, a choice.

• cgi requires forking an external process, tomcat throws up a new thread inside of a virtual machine process that is already running which is much less overhead than the cgi fork. also it is faster to develop inside java as well as being safer in general (no memory leaks, better object-oriented design etc.)
• Besides having all of the disadvantages of cgi, gcj is not a perfect rendition of java. Last I checked it was still missing a number of key pieces including good multi-threading and reflection.

I'm currently designing a new server which will eliminate the forking in certain cases. Assuming you don't have a switch-userid problem (which would require some kind of forking somewhere) the way it would work is that a piece of logic would be coded in C and compiled not into an executeable but into a simple module file with a .so extension. The template processor would parse for tags (and I have planned a parsing cache for static templates) in the template, and for those it finds, it would "call" the appropriate element for that tag. That could be another template (recursion loop detection engaged) or some logic. If the logic is the .so file, then it would be loaded as a dynamic library right then and called directly in the same process. If the logic is an executeable file (or a module owned by a different user in a switch-userid situation), then it would be run in a forked process. The point of the design is that all the elements can be made from any kind of executeable element the host OS can handle. And that would include Java, either as a binary compiled module (if I can figure out how to do that), a binary compiled executeable, or as a class file run by the appropriate byte code engine.

• A backend database/information system.
• A middle enterprise/business logic layer.
• A frontend/presentation layer.

That's a fairly standard model. That's not specific to Java, J2EE, or Tomcat. What you do get is that in some environments, the 2nd and 3rd are not separated (or maybe not very well). PHP comes to mind.

I built this site with PHP in one day and it was my first PHP project. The backend (1st in your list) was written in C and a shell script and not built on a usual SQL DB engine. It just consists of a cron triggered script that fetches backend data with lynx and reformats it with a different C program customized for each site (some in text format and some in RDF which was added later). The PHP code can be seen here.

But I have concluded that fully integrated logic and presentation is not a good thing. And I've also concluded that more than one class of logic can and should exist in a single presentation. The logic to select the banner ad should be separate from the logic to summarize some news on the side rail, while yet different logic selects the main forum body (in an example forum site). I feel all those elements should be discrete reusable elements of logic. The ad banner selector could be used on other pages, for example. The page would then be built for layout and style much as a regular static web page would be, with tag elements to notate where other "sub-presentations" go. Those can then be other static elements, or logic (dynamic) elements.

I have thought this was what JSP was supposed to be about, and the logic elements would be servlets. But I don't see where it has to be done in Java. Now that doesn't mean I hate Java. I admit I dis-like C++, but not Java. I do OO design and code it in C, but I haven't found any real advantage to doing it in C++. But I've done some programming in Pike, which I believe is better OO than C++ (but also has some limitations). Java looks to be the current state of the art in reasonably clean OOL.

The trouble I have with Java is the JVM. I don't feel the whole portable environment thing is necessary for statically maintained applications. What I mean by that is something that stays where it is sufficiently long term to make a compilation worth while (a day). To make downloadable applications to run in a web browser, portability is now more needed since a site needs to be able to deliver something on demand that works on many different platforms. But for this I don't feel that a compiled to byte code environment is the right way to go. If Java had been compiled down to a stack engine environment somewhat like Forth, or maybe just use Forth, then I would have agreed with it.

Basically, my goal for the server side is to have an environment that allows working with elements in the binary format of the host machine compiled from C or Java (for my choices) or any other language (compiled to binary like C++, precompiled like Perl, or interpreted at run time like Bash) that can run on the host, and integrate those as logic elements in a template based server engine. I see Java as a good choice in the system, but I also believe it should be that, a choice.

• cgi requires forking an external process, tomcat throws up a new thread inside of a virtual machine process that is already running which is much less overhead than the cgi fork. also it is faster to develop inside java as well as being safer in general (no memory leaks, better object-oriented design etc.)
• Besides having all of the disadvantages of cgi, gcj is not a perfect rendition of java. Last I checked it was still missing a number of key pieces including good multi-threading and reflection.

I'm currently designing a new server which will eliminate the forking in certain cases. Assuming you don't have a switch-userid problem (which would require some kind of forking somewhere) the way it would work is that a piece of logic would be coded in C and compiled not into an executeable but into a simple module file with a .so extension. The template processor would parse for tags (and I have planned a parsing cache for static templates) in the template, and for those it finds, it would "call" the appropriate element for that tag. That could be another template (recursion loop detection engaged) or some logic. If the logic is the .so file, then it would be loaded as a dynamic library right then and called directly in the same process. If the logic is an executeable file (or a module owned by a different user in a switch-userid situation), then it would be run in a forked process. The point of the design is that all the elements can be made from any kind of executeable element the host OS can handle. And that would include Java, either as a binary compiled module (if I can figure out how to do that), a binary compiled executeable, or as a class file run by the appropriate byte code engine.

Gee, and I thought much of the blame was on so many artists coming from the world of print media (e.g. paper brochure layout) to the web (e.g. electronic brochure layout) and not having a clue about basic concepts of adaptable layout (not dynamic, necessarily, just the ability to adapt to different window sizes, different fonts, different widgets, etc). But it has become clear that much of the blame, if not most, is on the part of the programmers (and more likely their managers) for producing crap that doesn't even have the capability to do the right thing.

I've found many a GUI app that had really good graphical layout, sometimes awesomely cool stuff, and did shit when it came to what the coded logic was. But then again, you shouldn't expect protein and vitamins in candy.

Tell me how well linuxhomepage.com does on your web browser in your preferred window size (as long as it's not itsy bitsy) on your desktop with your fonts and widgets.

Virtually every form, and most pages, I've built are really dynamic. There are lots of static pieces, but overall it's dynamic. I've done this in C and PHP. One example is http://linuxhomepage.com/ done in PHP on the front end and C on the back end. I'm not sure how anyone would build that using all GUI tools. That's not to say that GUI tools couldn't be used for at least some of it. But being more familiar with CLI tools, I found it easier to build that site originally in half a day using CLI tools alone. And I did it in text console mode (not xterm) switching to X, or my Win98 box, to test the rendition via a few different browsers. You can peek at the PHP source here. I'm thinking out the plans for the next version of the site now, and it will be more dynamic than the first, allowing you to choose your own boxes, number of stories in each, where to lay them out, and maybe even a display theme.

Virtually every form, and most pages, I've built are really dynamic. There are lots of static pieces, but overall it's dynamic. I've done this in C and PHP. One example is http://linuxhomepage.com/ done in PHP on the front end and C on the back end. I'm not sure how anyone would build that using all GUI tools. That's not to say that GUI tools couldn't be used for at least some of it. But being more familiar with CLI tools, I found it easier to build that site originally in half a day using CLI tools alone. And I did it in text console mode (not xterm) switching to X, or my Win98 box, to test the rendition via a few different browsers. You can peek at the PHP source here. I'm thinking out the plans for the next version of the site now, and it will be more dynamic than the first, allowing you to choose your own boxes, number of stories in each, where to lay them out, and maybe even a display theme.

I'll let Woofcat go into the speed differences more, since he said it first. But I do find PHP to run faster than Perl, and from what I read, it therefore must be faster than Java.

If you're doing DB backed stuff, then Java is probably not going to be your bottleneck unless you improperly misbalance the machines. I do agree with you that speed of development is secondary (although try convincing most project managers or CTOs/CEOs). And yes, separating logic/process/application from presentation/content is the way to go for anything short of little one day PHP knockoffs like I did with http://linuxhomepage.com/. I'm currently building up my own toolkit to do that in the language I now do my web stuff in (which is faster than PHP).

Actually, BOTH HTML-in-code and code-in-HTML are dead. The one and true answer is separation of content vs. application, and total pluggability between the two. The ultimate solution will work with any content/information form (HTML, XML, etc) and application form (C, C++, Perl, Java, Scheme, etc). This is organization and the web still majorly lacks it.

Don't get me wrong here. I love PHP. I did LinuxHomePage.Com in PHP in one day as my very first PHP project. It was great and PHP was very easy to work with.

Some people are inherintly more program/application development oriented. Other people are more information/content development oriented. And still others are graphical/artistic oriented. Few people have the capability to be all that and good at all of it at the same time. So it will be necessary to divide the development (and change) functions and thus also necessary to divide up the entities these different people work with to implement and deploy the components they do.

An author of an article can't write the page layout, but she does need to write the article. She can't concern herself with what tag needs to be inerted at the top to get the properly rotated ad banner inserted. She can't concern herself with how to lay out the menus on the left side or the right side.

The very model of dividing things up at the page boundary is what is wrong. We got fooled into thinking of that with HTML itself because the tags were (at least early on) easy enough for even a non-techie document writer to work with. But today's web applications bear little resemblence to a hierarchy of documents for which HTML was designed. Our thinking needs to be along the lines of keeping separate, and dynamically merging in the appropriate way, the various components that make up what it is we are accessing. That is where we are headed and we best be prepared to deal with it, regardless of what our preferences are for things like content language or programming language.

My site lays out fine in IE/NS/OP.

Look here full examples of names you can no longer get unless you pay money.

And I have several of them myself, such as linuxhomepage.com :-)