in general, what people need to understand is that the packaging isn't as all-important as a lot of decision-makers like to think. what matters is if the site is able to deliver a service.
creating good services is hard work.
most of the time neat packaging is a bonus, but too often the packaging gets in the way and it becomes something the user must tolerate rather than something the user will enjoy.
the web is not a novelty anymore. it is something almost everyone has access to. people are less inclined to find eye-candy on corporate websites amusing. especially when it represents an impediment.
I've been working with web related technologies for a decade now and while the breadth and depth of technological development in this field has steadily increased over the years, sensible adoptation of available technology has slowed down relatively speaking.
new standards are created and old standards are improved, but people are too entrenched in the old ways of doing things to provide any forward momentum.
as more gadgets with limited screen real-estate and input interfaces become web enabled, the problems with bad web design practices become more obvious.
it is funny how the people who are the problem pop their empty heads up in discussions like these and actually whine when someone has to come up with ways to manouver around their incompetent designs.
this is a great big "we told you so" to the duh-signers and they still don't get it. I find that pretty amazing.
marketing people and executives won't understand how to do web design well, they lack a thorough understanding of the technology. they are mostly concerned with doing whatever the competition is doing.
therefore it is your task to a) educate yourself so you can do your job better, but more importantly, b) educate them so they are able to make better decisions.
as a bonus you won't have to waste your life churning out things you know to be pointless crap.
there's a saying that goes something like "if you wrestle with the pig, you both get dirty" which would apply nicely here. trying to have any sort of meaningful discussion with someone who is ignorant on the topic at hand seldom bears any fruit, so I'm not expecting you to grow any sort of clue any time soon. however, once you get over your silly pride in your own ignorance you might be able to learn something.
a good starting point for you would be to realize what problem the web was supposed to solve and the nature of this problem. Tim Berners Lee has written various pieces on this topic over the years. I'll leave it as a exercise to you to find this information.
spoiler: no, the primary objective was not to eliminate paper based publishing. you need to brush up on your history of the web.
you might also want to develop a deeper understanding of SGML, and how SGML relates to HTML and other applications of SGML, before you start lecturing people on SGML. this will eventually prevent you from future embarassment and perhaps even help you understand where things like XML, XSLT, DSSSL and related standards fit into the big picture.
be warned though, digesting SGML and its related standards takes a lot of effort. don't expect any quick wins. if you think that SGML is something you'll understand in 21 days you are in for a serious
reality-check
as for lack of screwdrivers, you do have a point: there was a lack of adequate screwdrivers. the problem is that the effort that has gone into specializing hammers for the purpose of driving in screws is a waste of time. it would have taken a lot less effort to develop adequate screwdrivers than it took to develop the first 3 generations of specialized hammers. not only that, but having made adequate screwdrivers we would have been able to develop them much further than any hammer can currently go.
the tragedy is that all the effort that has gone into bad use of HTML to kludge up content is a major impediment for taking the web further. a lot of it stems from the fact that people who are introduced to the web are often newcomers to a lot of the problems the web was supposed to solve -- hence they are doomed to repeat past mistakes.
as I've mentioned elsewhere in this thread, a sensible approach to publishing content on the web starts with developing a thorough understanding of the problems one should strive to solve. for web designers like yourself, who lack the technological and historical background for understanding the fundamental problems and ideas of this problem domain, a good start is to focus on understanding that the web is not a paper based medium and that different rules should be applied when designing for the web.
of course, this is difficult. it is difficult because there's so much horrible web design out there (and I am not referring to aesthetics here) already to distract you and it takes a fair share of mental discipline to understand that just because "everyone else" is banging away at screws with hammers or rocks doesn't make it the right thing to do.
this is what you get when consistently using a hammer to drive in a screw -- after a while someone will just give up trying to teach people to use a screwdriver and invent a hammer that is better at driving in screws.
blaming the people providing the hammers and screwdrivers is hardly fair. blame the monkeys. blame the web-duh-signers who can't seem to evolve past designing for paper media.
I can't help but feel that if more energy had been devoted to making designers more aware of how WWW differs from designing for paper, the web would have looked a lot better than it does today. not to mention that it would probably have depended less on outdated, kludgy techniques for forcing a particular look given a very narrow list of target user agents.
whenever I read comments from people who abhor the idea of content being adaptable to a wider range of user agents, I can't help but feel that these people have missed the entire point and are very much part of the problem.
perhaps what one should ask is how these people can be educated? how do you explain the basic idea of creating content that can be accessed on a wide range of user agents in a manner where the content can benefit from the feature richness of some UAs while still being usable on UAs that are more constrained?
to me the biggest problems seem to be that a) people are too lazy to care, b) too incompetent to understand why this is a good idea and c) too occupied defending their suboptimal use of technology to sit down and have a good, hard think.
besides, the rocks and sticks approach to "web design" doesn't exactly do wonders for things like getting browser developers to maximize the subset of CSS that actually works across products. the list of CSS-features that are broken in various browsers, and thus shouldn't really be used, is too long.
...is that The Register looks a lot better when rendered on a small screen and converted to a single column rather than their braindamaged layout with multiple misaligned columns.
I have to admit that I don't read The Reg nearly as often as I'd like mainly because of their awfully clumsy layout. keeping it is apparently important to them.
However, the reason it's automatically accepted is because VeriSign is suppose to verify the identity of the business. This is why they require a Duns and Bradstreet # (It's a business credit identifier).
knowing your social security number does not make me you. it makes me someone who knows your social number. nothing more. nothing less.
while a lot of people seem to think they know the mechanics of cryptography pretty well (and probably do), there still seems to be a lot of people who aren't really in the habit of thinking where security supposedly comes from in any given scheme.
Why blow $400 on a certificate from a company that doesn't really provide a useful service. How much is their promise really worth that the holder of a certificate is authentic? I can't remember anyone actually checking if we were who we said we were the few times I've been involved in getting certificate -- apart from sending some papers and making some calls.
Nothing an even half competent con artist can't deal with.
I think the whole CA-business is rather fishy.
The only thing people are paying for is to have the pesky warnings that pop up if the certificate is not signed by a CA known by the browser removed. I have yet to see a single individual with even half a clue about cryptography state that he or she actually believes that the big certificate authorities actually provide any form of useful service.
I wish I had started a CA a decade ago and then jumped into bed with Netscape a few years later. This must be the single most profitable business online.
lying on the specs seems rather commonplace when it comes to gadgets. I recently discovered that a camera I own does not have 3 different resolutions. in fact it has only two, but the software that came with the camera for downloading pictures from it uses interpolation to generate images of the highest "resolution".
you have no idea how common this is and how painful it is to make something which is fairly reliable *and* efficient to, if not solve, at least reduce the problem.
designing and implementing aggregation systems for large scale search engines in general is a rather challenging task which is not often mentioned when people talk about search engines. It challenging because it is the part of a search engine that has to deal with all the foolishness of the web.
for the past year or so I've been thinking that it might be time to see if it would be practical to set up an account which will only accept email signed with GnuPG or PGP or perhaps email that has been encrypted with my public key. (actually, that wouldn't stop anyone fom sending me spam, although I suspect the cost of encrypting huge amounts of email might make it unfeasible for most spammers, but I might be mistaken in the longer run)
any message that has not been signed is discarded. an additional requirement could be that the the key used for signing the message has to be present in a list of authors I want to accept email from.
I haven't given this scenario any thorough analysis, so I'm sure there are a lot of problems I haven't anticipated. for one it is going to be rather inconvenient having to exchange keys. not to mention that mail might become significantly more CPU intensive -- but on the other hand; I'd rather burn a few extra CPU cycles than waste my time deleting spam, always risking that legitimate mail gets deleted because some people insist on using silly aliases in their From fields.
has anyone given the use of cryptographic signatures for filtering mail much thought? it shouldn't be too hard to make a mail delivery agent that is easy to use and easy to configure.
"superiority commplex"? so now it is my problem that I know something about DoS-attacks and you obviously have no idea? I'm the bad guy here for pointing out that your naive view of the world is not exactly correct?
get real.
come back when you've learned the difference between implementational flaws and design problems. come back when you can tell me how to distinguish valid traffic from traffic generated for the purpose of overloading a service. come back when you have some experience and some real knowledge, because any idiot on slashdot can point out that something is wrong, but actually coming up with a real and working solution is pretty hard and *way* beyond what you seem capable of.
you don't seen to have the faintest idea what sort of problems need to be solved in order to counter the kinds of DoS attacks. do you really think it is as simple as "applying safeguards we use in regular programming to net code too"?
here's a challenge for you: show me what safeguards used in regular programming that will make my TCP/IP stack immune to being pounded by a million "flood agents". (since you are obviously not a technical person we will ignore the fact that the link will be saturated for now and assume a pipe of infinite bandwidth to the machine in question).
I don't think the article was aimed at people like you. I think it was aimed at people with at least some technical background.
as for the moderators: what have you been smoking?
I find it interesting you refer to 30 lines as a substantial amount of code. The article
suggests the program was a rather large one, and that 30 lines was a small fraction of the
overall code. My own computer science experience in the past suggests 30 lines probably
was a teeny fraction of the code.
if those 30 lines contain the solution to the hard part of the problem to be solved than those 30 lines are the only lines that really matter. the rest is not interesting. besides, the overall program was supposedly "hundreds" of lines of code. that is not "large" by any standard.
discussing this without seeing the source is futile and pointless and we DO know better, don't we?
so this is the new buzzword now? public data repositories? everyone is going to run around and find ways to do it without asking if they really need it? like the p2p frenzy. give me a break; when are people going to start solving real problems rather than just wanking. why not spend those research dollars on finding ways to improve the systems we know we need instead, rather than jumping bandwagon because everyone else is.
why is it that the software world is so full of these obsessive notions that everyone has to use a certain technology, appropriate or not, for whatever they do in order to be cool. I know several examples of companies doing stupid products, just because they felt they had to do something that allows them to say they follow the latest silly trend in software.
besides: we don't have public data repositories already? that is certainly news to me.
although what you describe in this case is
a very "benign" form of DoS, in that it is limited to a very specific target and probably does not cause a lot of "collateral damage", you are doing something very dangerous in that you condone activities that can be labeled as acts of vandalisom and/or terrorism.
if you ask the palestinian suicide bombers they will tell you that they are committing acts of terrorism as a form of self defence. in their eyes they are applying the last desperate measure available to them since their conventional military capabilities are significantly below those of Israel.
to these people the means are justifiable exactly the same way you find DoS justifiable to get rid of spammers.
I've been on the receieving end of many huge DDoS attacks for no other reason that running an IRC server. usually they don't even have an axe to grind with me; they just want to take over some channel and in order to do that need to split up the net for a significant period of time. a conflict between a few people that at times has affect as several hundred thousand people.
just a few weeks ago a few kids from Iceland DDoS'ed my IRC server for almost 6 hours -- just so they could try to take over some channels, collide off a few users etc. the tragedy is that while they hurled about 100Mbit/sec at my server, they indirectly DoS'ed other sites since my server responded to spoofed packets.
at best DoS is an illegal act of vandalism. in the worst case it might be considered an act of terrorism. the problem is that given the vast difference in how the authorities react to different attacks, a lot of naive people are starting to think that it is a legitimate means of achieving various goals.
if you condone DoS you are no better than the people who condone terrorism.
I can certainly understand your frustration with spammers and the authorities' impotence when it comes to dealing with them, but I can guarantee you that NOTHING will change unless you push the authorities to deal with the problem.
If you directed your efforts toward the authorities instead of stooping to the lowest level, even below spammers, you would do some good. what you are doing is providing a short term relief from one spammer. sure it probably makes you feel like you've achieved something, but the unpleasant truth is that you have just become something even more loathsome than the spammers: a terrorist.
DoS is never justifiable, just as terrorism is never justifiable.
The golden rule in HCI is "Developers are not target users"
In most of the cases you are right: the target audience should be Joe User and not developers, but I've made an interesting observation on a few web services where I've had the chance to have a look behind the scenes.
especially one of the systems was particularly interesting. the service they produced was one that is supposed to make life easier for you by providing a web interface to certain tasks that you would otherwise spend a lot of time on. the problem was that it didn't.
the user interface was so full special gags that it would only render reliably on IE 5 with the browser stretched to exactly the right proportions. for all other browsers it would be unreliable and often not work at all. also the service was incredibly sluggish because of all the UI sugar.
now, it turns out that the developers of the system are pretty heavy users of their own product. they spend several hours using it every day. since they too were annoyed with the utter crap that the web designer morons had slapped on top of their system, they made their own UI. and lo and behold: their UI was much better.
not only was it faster since it didn't make excessive use of graphics and UI sugar, but it worked in a wide range of browsers and for most sensible browser geometries -- plus, it had some new ways to handle certain very common operations with only one page load. big wins all around. it looked tidy and neat, and the fonts were actually readable on my screen.
why didn't they offer this UI to the customers? well, because in the opinion of the worthless people who are supposed to know about web design it didn't look "professional".
what I am trying to say is that when designing an UI, the people you should listen to are the people who use the application a lot. the case described above is not unique; I have seen this pattern many times before: developers make their own interfaces because the official interface is usually not practical.
but since we're talking about an installer here you would be absolutely right: most people will run across an OS installer very seldomly and it is absolutely critical that novice users are shielded from complexities. but it is also an important point that OS installers provide flexibility so users who know what they are doing have some choice as to which tasks they want to perform differently. (for instance I might have certain preferences for how I want my filesystems, but I might be less interested in having to answer 29365 questions about what software I want to install).
As an example of what can go wrong, look at your
average TeX-written math/cs paper on your average
PC screen. The font's too grainy and greeky to read at 75-100dpi [...]
I usually generate two outputs of my LaTeX documents: Postscript and PDF. The PDF version usually looks a bit better on screen than the PostScript version.
mind you: I generate the PDF version using pdflatex. I can't remember exactly, but I think I've seen a utility that converts DVI files to PDF and that this produced horrible output. use pdflatex.
because generate multiple output formats (PS, PDF and HTML) from the same LaTeX document, I usually use a package I wrote that contains a lot of convenient macros to make use of the different features in the different formats -- in addition to automating a lot of boring tasks.
I remember how delighted I was when I discovered pdflatex. once you work it into your repertoire you get all this cool stuff for free, like hyperlinks in PDF documents etc. I really recommend you give it a try.
That's talking about an entirely different thing: to install up-to-date packages, you have to put unstable (or testing) in sources.list, and deal with the issues that arise from that.
just out of curiosity: what issues? I've been running woody for a few months now and I've had very few "issues" at all. in fact, I've had an order of a magnitude fewer issues with woody than I've had with ANY RedHat dot-release.
this makes me curious: what are you (or I) doing differently?
then why do they complain? if they cared they'd install a newer kernel. I think it is just too daft to nix a very good OS distribution just because there are clueless people in the world.
the default kernel is there to reliably bootstrap the system. it doesn't really matter if it's 2.2 or 2.4 -- it's going to be replaced anyway. at least when the installer has a clue. whatever works on the greatest number of systems for the duration of the install.
Slashdot Mirror
how do you figure that the market for virtualizing servers isn't big?
creating good services is hard work.
most of the time neat packaging is a bonus, but too often the packaging gets in the way and it becomes something the user must tolerate rather than something the user will enjoy.
the web is not a novelty anymore. it is something almost everyone has access to. people are less inclined to find eye-candy on corporate websites amusing. especially when it represents an impediment.
I've been working with web related technologies for a decade now and while the breadth and depth of technological development in this field has steadily increased over the years, sensible adoptation of available technology has slowed down relatively speaking.
new standards are created and old standards are improved, but people are too entrenched in the old ways of doing things to provide any forward momentum.
as more gadgets with limited screen real-estate and input interfaces become web enabled, the problems with bad web design practices become more obvious. it is funny how the people who are the problem pop their empty heads up in discussions like these and actually whine when someone has to come up with ways to manouver around their incompetent designs.
this is a great big "we told you so" to the duh-signers and they still don't get it. I find that pretty amazing.
marketing people and executives won't understand how to do web design well, they lack a thorough understanding of the technology. they are mostly concerned with doing whatever the competition is doing.
therefore it is your task to a) educate yourself so you can do your job better, but more importantly, b) educate them so they are able to make better decisions.
as a bonus you won't have to waste your life churning out things you know to be pointless crap.
a good starting point for you would be to realize what problem the web was supposed to solve and the nature of this problem. Tim Berners Lee has written various pieces on this topic over the years. I'll leave it as a exercise to you to find this information.
spoiler: no, the primary objective was not to eliminate paper based publishing. you need to brush up on your history of the web.
you might also want to develop a deeper understanding of SGML, and how SGML relates to HTML and other applications of SGML, before you start lecturing people on SGML. this will eventually prevent you from future embarassment and perhaps even help you understand where things like XML, XSLT, DSSSL and related standards fit into the big picture.
be warned though, digesting SGML and its related standards takes a lot of effort. don't expect any quick wins. if you think that SGML is something you'll understand in 21 days you are in for a serious reality-check
as for lack of screwdrivers, you do have a point: there was a lack of adequate screwdrivers. the problem is that the effort that has gone into specializing hammers for the purpose of driving in screws is a waste of time. it would have taken a lot less effort to develop adequate screwdrivers than it took to develop the first 3 generations of specialized hammers. not only that, but having made adequate screwdrivers we would have been able to develop them much further than any hammer can currently go.
the tragedy is that all the effort that has gone into bad use of HTML to kludge up content is a major impediment for taking the web further. a lot of it stems from the fact that people who are introduced to the web are often newcomers to a lot of the problems the web was supposed to solve -- hence they are doomed to repeat past mistakes.
as I've mentioned elsewhere in this thread, a sensible approach to publishing content on the web starts with developing a thorough understanding of the problems one should strive to solve. for web designers like yourself, who lack the technological and historical background for understanding the fundamental problems and ideas of this problem domain, a good start is to focus on understanding that the web is not a paper based medium and that different rules should be applied when designing for the web.
of course, this is difficult. it is difficult because there's so much horrible web design out there (and I am not referring to aesthetics here) already to distract you and it takes a fair share of mental discipline to understand that just because "everyone else" is banging away at screws with hammers or rocks doesn't make it the right thing to do.
blaming the people providing the hammers and screwdrivers is hardly fair. blame the monkeys. blame the web-duh-signers who can't seem to evolve past designing for paper media.
I can't help but feel that if more energy had been devoted to making designers more aware of how WWW differs from designing for paper, the web would have looked a lot better than it does today. not to mention that it would probably have depended less on outdated, kludgy techniques for forcing a particular look given a very narrow list of target user agents.
whenever I read comments from people who abhor the idea of content being adaptable to a wider range of user agents, I can't help but feel that these people have missed the entire point and are very much part of the problem.
perhaps what one should ask is how these people can be educated? how do you explain the basic idea of creating content that can be accessed on a wide range of user agents in a manner where the content can benefit from the feature richness of some UAs while still being usable on UAs that are more constrained?
to me the biggest problems seem to be that a) people are too lazy to care, b) too incompetent to understand why this is a good idea and c) too occupied defending their suboptimal use of technology to sit down and have a good, hard think.
besides, the rocks and sticks approach to "web design" doesn't exactly do wonders for things like getting browser developers to maximize the subset of CSS that actually works across products. the list of CSS-features that are broken in various browsers, and thus shouldn't really be used, is too long.
I have to admit that I don't read The Reg nearly as often as I'd like mainly because of their awfully clumsy layout. keeping it is apparently important to them.
knowing your social security number does not make me you. it makes me someone who knows your social number. nothing more. nothing less.
while a lot of people seem to think they know the mechanics of cryptography pretty well (and probably do), there still seems to be a lot of people who aren't really in the habit of thinking where security supposedly comes from in any given scheme.
I think the whole CA-business is rather fishy. The only thing people are paying for is to have the pesky warnings that pop up if the certificate is not signed by a CA known by the browser removed. I have yet to see a single individual with even half a clue about cryptography state that he or she actually believes that the big certificate authorities actually provide any form of useful service.
I wish I had started a CA a decade ago and then jumped into bed with Netscape a few years later. This must be the single most profitable business online.
...yet to a propellerhead anything-point-oh sounds terrifying. :-)
hey presto! three resolutions.
mod up parent.
designing and implementing aggregation systems for large scale search engines in general is a rather challenging task which is not often mentioned when people talk about search engines. It challenging because it is the part of a search engine that has to deal with all the foolishness of the web.
for the past year or so I've been thinking that it might be time to see if it would be practical to set up an account which will only accept email signed with GnuPG or PGP or perhaps email that has been encrypted with my public key. (actually, that wouldn't stop anyone fom sending me spam, although I suspect the cost of encrypting huge amounts of email might make it unfeasible for most spammers, but I might be mistaken in the longer run)
any message that has not been signed is discarded. an additional requirement could be that the the key used for signing the message has to be present in a list of authors I want to accept email from.
I haven't given this scenario any thorough analysis, so I'm sure there are a lot of problems I haven't anticipated. for one it is going to be rather inconvenient having to exchange keys. not to mention that mail might become significantly more CPU intensive -- but on the other hand; I'd rather burn a few extra CPU cycles than waste my time deleting spam, always risking that legitimate mail gets deleted because some people insist on using silly aliases in their From fields.
has anyone given the use of cryptographic signatures for filtering mail much thought?
it shouldn't be too hard to make a mail delivery agent that is easy to use and easy to configure.
-Bjørn
at least you seem to have understood that your original posting was clueless. that at least is an improvement.
get real.
come back when you've learned the difference between implementational flaws and design problems. come back when you can tell me how to distinguish valid traffic from traffic generated for the purpose of overloading a service. come back when you have some experience and some real knowledge, because any idiot on slashdot can point out that something is wrong, but actually coming up with a real and working solution is pretty hard and *way* beyond what you seem capable of.
here's a challenge for you: show me what safeguards used in regular programming that will make my TCP/IP stack immune to being pounded by a million "flood agents". (since you are obviously not a technical person we will ignore the fact that the link will be saturated for now and assume a pipe of infinite bandwidth to the machine in question).
I don't think the article was aimed at people like you. I think it was aimed at people with at least some technical background.
as for the moderators: what have you been smoking?
yeah, that Mozilla sure runs smoothly on my
old 386 with 6Mb RAM.
PS: can you spot the sarcasm?
-Bjørn
if those 30 lines contain the solution to the hard part of the problem to be solved than those 30 lines are the only lines that really matter. the rest is not interesting. besides, the overall program was supposedly "hundreds" of lines of code. that is not "large" by any standard.
discussing this without seeing the source is futile and pointless and we DO know better, don't we?
-Bjørn
why is it that the software world is so full of these obsessive notions that everyone has to use a certain technology, appropriate or not, for whatever they do in order to be cool. I know several examples of companies doing stupid products, just because they felt they had to do something that allows them to say they follow the latest silly trend in software.
besides: we don't have public data repositories already? that is certainly news to me.
if you ask the palestinian suicide bombers they will tell you that they are committing acts of terrorism as a form of self defence. in their eyes they are applying the last desperate measure available to them since their conventional military capabilities are significantly below those of Israel.
to these people the means are justifiable exactly the same way you find DoS justifiable to get rid of spammers.
I've been on the receieving end of many huge DDoS attacks for no other reason that running an IRC server. usually they don't even have an axe to grind with me; they just want to take over some channel and in order to do that need to split up the net for a significant period of time. a conflict between a few people that at times has affect as several hundred thousand people.
just a few weeks ago a few kids from Iceland DDoS'ed my IRC server for almost 6 hours -- just so they could try to take over some channels, collide off a few users etc. the tragedy is that while they hurled about 100Mbit/sec at my server, they indirectly DoS'ed other sites since my server responded to spoofed packets.
at best DoS is an illegal act of vandalism. in the worst case it might be considered an act of terrorism. the problem is that given the vast difference in how the authorities react to different attacks, a lot of naive people are starting to think that it is a legitimate means of achieving various goals.
if you condone DoS you are no better than the people who condone terrorism.
I can certainly understand your frustration with spammers and the authorities' impotence when it comes to dealing with them, but I can guarantee you that NOTHING will change unless you push the authorities to deal with the problem.
If you directed your efforts toward the authorities instead of stooping to the lowest level, even below spammers, you would do some good. what you are doing is providing a short term relief from one spammer. sure it probably makes you feel like you've achieved something, but the unpleasant truth is that you have just become something even more loathsome than the spammers: a terrorist.
DoS is never justifiable, just as terrorism is never justifiable.
In most of the cases you are right: the target audience should be Joe User and not developers, but I've made an interesting observation on a few web services where I've had the chance to have a look behind the scenes.
especially one of the systems was particularly interesting. the service they produced was one that is supposed to make life easier for you by providing a web interface to certain tasks that you would otherwise spend a lot of time on. the problem was that it didn't.
the user interface was so full special gags that it would only render reliably on IE 5 with the browser stretched to exactly the right proportions. for all other browsers it would be unreliable and often not work at all. also the service was incredibly sluggish because of all the UI sugar.
now, it turns out that the developers of the system are pretty heavy users of their own product. they spend several hours using it every day. since they too were annoyed with the utter crap that the web designer morons had slapped on top of their system, they made their own UI. and lo and behold: their UI was much better.
not only was it faster since it didn't make excessive use of graphics and UI sugar, but it worked in a wide range of browsers and for most sensible browser geometries -- plus, it had some new ways to handle certain very common operations with only one page load. big wins all around. it looked tidy and neat, and the fonts were actually readable on my screen.
why didn't they offer this UI to the customers? well, because in the opinion of the worthless people who are supposed to know about web design it didn't look "professional".
what I am trying to say is that when designing an UI, the people you should listen to are the people who use the application a lot. the case described above is not unique; I have seen this pattern many times before: developers make their own interfaces because the official interface is usually not practical.
but since we're talking about an installer here you would be absolutely right: most people will run across an OS installer very seldomly and it is absolutely critical that novice users are shielded from complexities. but it is also an important point that OS installers provide flexibility so users who know what they are doing have some choice as to which tasks they want to perform differently. (for instance I might have certain preferences for how I want my filesystems, but I might be less interested in having to answer 29365 questions about what software I want to install).
I usually generate two outputs of my LaTeX documents: Postscript and PDF. The PDF version usually looks a bit better on screen than the PostScript version.
mind you: I generate the PDF version using pdflatex . I can't remember exactly, but I think I've seen a utility that converts DVI files to PDF and that this produced horrible output. use pdflatex .
because generate multiple output formats (PS, PDF and HTML) from the same LaTeX document, I usually use a package I wrote that contains a lot of convenient macros to make use of the different features in the different formats -- in addition to automating a lot of boring tasks.
I remember how delighted I was when I discovered pdflatex. once you work it into your repertoire you get all this cool stuff for free, like hyperlinks in PDF documents etc. I really recommend you give it a try.
Check out the PDFTeX web page for more information.
Also have a look at Matt Welsh' page about creating presentations in PDFLaTeX. He has some useful information on how to install TrueType fonts for use by PDFLaTeX.
-Bjørn
just out of curiosity: what issues? I've been running woody for a few months now and I've had very few "issues" at all. in fact, I've had an order of a magnitude fewer issues with woody than I've had with ANY RedHat dot-release.
this makes me curious: what are you (or I) doing differently?
then why do they complain? if they cared they'd install a newer kernel. I think it is just too daft to nix a very good OS distribution just because there are clueless people in the world.
why can't they run Windows instead?
the default kernel is there to reliably bootstrap the system. it doesn't really matter if it's 2.2 or 2.4 -- it's going to be replaced anyway. at least when the installer has a clue. whatever works on the greatest number of systems for the duration of the install.