We were *not* supposed to hate Magneto. It's not supposed to be as simple as "X-Men good. Magneto bad. Humanity innocent victims."
The lines are not so well defined. Sometimes humanity isn't worth saving. Sometimes Prof. X's quest seems rather quixotic. Sometimes Magneto has the right idea -- fighting for the survival of his species. But that's why X-Men is so great.
Hotmail's choice of OS is irrelvent to my point. I was making a comment about their *business model* being such that forcing them to give up their source code would entirely eliminate Open Source/Free Software as an option for them. The same would apply if they were using Hurd, or NT.
Slashdot can afford to give away the Slash engine source -- their business model doesn't center around the functionality of the site, but rather the content.
If I allow you to run my application via an X server, it is MY CPU time being used, MY memory, MY storage space, etc.
You don't have a copy of the software. You're not even running it on your system. Why should I be forced to turn over my source code to you when it's not even running on your machine?
But if you really want to do this, go right ahead. It will force many companies now using Open Source software to abandon it entirely. Not all business models have software as an "incidental" -- like Slashdot. Most Internet business models would be incompatible with such a license.
Kiss IBM's support of Linux and use of/contribution to Apache goodbye. Kiss most of the.com's goodbye as they move to another platform.
Let us say that eProject.com used Linux, Apache, Perl, and some CPAN modules. If you changed the license as everyone is advocating, how would their business model work? What business model could you find that would be even close to viable -- and still use Free software?
While some people see this "loophole" as a flaw(CmdrTaco included) I see it as being a *neccesary* "loophole" if you want the commercial Internet industry to adopt open source/Free software.
Why would I use Free software for my web based application if I had to redistribute my code?
If my only means of competing right now are features, performance, database (I.E. the breadth and depth of data -- content, etc...), and marketing then this would eliminate features and performance as a competitive advantage. Not all web based companies are content-based like Slashdot: Some, like Hotmail, are based on functionality.
It just doesn't make business sense to have to redistribute your code unless your code doesn't give you a significant competitive advantage. So for sites like Slashdot it's not a problem. For sites like Hotmail, eProject.com, or wherver -- it's a problem.
My employer uses Perl, Apache, Linux, MySQL, and other such systems right now. If the licenses were changed such that we'd have to redistribute our code, we'd be forced to either not upgrade to a version under the new license, or to rewrite everything in a system that doesn't have such draconian licensing.
The ideals of the Free software movement are all well and good, but even RMS hasn't shown a viable (read: profitable) business model that fully adopts them -- and even if he could, one business model doesn't cover every idea.
That's a different issue. Lewinsky's purchase history was based on *financial* records. Financial records MUST MUST MUST be kept to help eliminate errors, and correct them when they do arise. Not to mention for tax purposes...
I'll look into it, but I doubt I'll get the go ahead for such a thing...
<<Depending on the nature of the application, you could consider using something like a server program with either memory-resident data or fixed-format data files (perhaps even using MySQL for this limited application), to act as a buffer between the web server and the database.>>
Actually, our Oracle-experienced engineer says that this is what he had to do for (I think) AT&T because of Oracle's abysmal write performance.
However, this depends on a couple things...
First, that your system traffic is cyclical in nature, having a period of time where the traffic on the system is lower than the write performance of the database (the catch-up period) that is proportional to the period of time where write-performance is exceeded.
Second, that you don't immediately need the data, or that you be willing to institute a failover lookup mechanism that allows you to check the buffer for pending data.
For us, our performance cycle is narrowing as we start handling more and more international clients. And for our application, delaying commitment of data for a few hours is just unacceptable.
The solution we're considering would best be described as "perpendicular" to this line of thought, although I can't really go into much more detail.
<<For example, as a large schema evolves, views can be used to support legacy code with the table structure they expect, when the underlying tables may have changed or been split into multiple tables.>>
Eek. In a perfect world one would not be re-normalizing schema periodically *after* you go to production... But it does happen. One would think however that to do so, it would be wise to review dependent code to eliminate "bit-rot" anyway.
<<They can also be very useful during development as a way of reusing queries, i.e. a particular multi-way join that gets used repeatedly can be implemented as a view and then used in other queries.>>
I'll concede this one... Although most of the situations I've encountered involved either fairly simple queries, or complex queries that were put together very dynamically. (picture a natural join that can have between 3-10 tables and *lots* of context-dependent conditions...)
<<Finally, views can support standard ways of browsing and querying the data using client tools, by users or support personnel who would find the highly normalized underlying schema difficult to deal with. >>
Only if they are using a generalized table-browser -- yech! A web-based front-end application is usually pretty trivial to put together, and generally far more intuitive to use. Although again, I can see instances where this makes sense...
<<The feature I suspect I would find most difficult to live without, using MySQL, is enforcement of referential integrity.>>
It's one of those sacrifice-features-for-performance type of deals. If you have transactions, it shouldn't be neccesary. If you don't have transactions then you'd better be darn careful.:) Yes, it can be annoying, but certainly not a critical failing...
<<Also, what about stored procedures? I have the impression it doesn't support them? In more complex systems, more work is done in stored procedures that feed the results of one query into subsequent queries, than is done by stand-alone queries, so doing without stored procedures would be a crippling problem. But I admit I'm now talking about far more complex applications than the target audience for MySQL.>>
Never used them myself... But yeah, having them would be nice...
Unfortunately the big commercial databases (read: Oracle and DB2) have some critical limitations of their own.
I work at a company that has dozens of tables, some of which have tens of millions of rows. We're a web based company and we serve millions of dynamically generated page views per day. We use MySQL, and are debating our options for the future right now.
In the past we looked at DB2 (ported our flagship product to it for testing), and we've spoken with people who've used Oracle -- the conclusion we've come to is that for certain classes of problems, performance is just unacceptably bad for Oracle and DB2.
Specifically, write performance is a problem. Now, MySQL isn't uniformly better: Table level locking is a SERIOUS problem, but at least there is a window of load where write performance is acceptable, and some tuning of your application can usually alleviate related problems quite well.
In our test of DB2, versus MySQL, using a C-based client in a fairly "real world" (read: Access patterns similar to our product) Db2 was only able to get 9 inserts per second into a crucial table. If we turned transaction logging off (which the DB2 guys said was a Very Bad Thing -- and did in fact cause massive problems) we got that up to 31 inserts per second. We tweaked and tuned things with help from IBMs engineers.
MySQL consistently got over 1,000 inserts/sec on the same hardware, with the same schema, and the same access patterns.
Also, the time it takes to establish/break down a connection to the database can be an issue. Connection pooling helps, but if you've got a situation where you have more clients than possible connections, and not all of the clients will always need a connection then you can get into a situation where clients that *do* need a connection have to wait because clients that *dont* need one still have the connection in their pool. In such a case, if you are using MySQL, one can get better performance by turning connection pooling *off*. That's not a *common* occurence, but certain classes of web applications can experience it.
Also, some features of MySQL can obviate the need for some of the "advanced" features of the commercial databases. Consider "views". As I understand it, there are two basic reasons to use a view: 1) To provide finer-grained security than is otherwise attainable with table-level security. (essentially, per-column security) MySQl already supports per-column access priviledges, so this use of views is unnecesary.
2) To allow/simplify some complex joins. I'm told by an engineer here with Oracle experience that left joins with multiple unprotected tables and one protected table aren't *directly* possible with Oracle -- the solution is to use views. You want to join A, B, C, and D with only A being protected. Make a view called A1 of A and B, make a view called C1 of A1 and C, and then left join C1 and D. MySQL supports left joins with multiple unprotected tables very easily -- so no need for views here.
Obviously these features aren't applicable in 100% of cases, but in a great many situations, the "limitations" of MySQL really aren't as bad as they sound.
And just for the record,as is briefly noted in the article, transaction support and page level locking is supported in the 3.23.x development series using Berkeley DB as the table handler. You have a per-table choice of which handler you want -- ISAM/MyISAM is the "normal" type (fast, disk-based, no transactions, table level locking), Heap (very fast, memory based, no transactions, table level locking), and BDB. (somewhat slower, full transactions, page level locking)
That's because PacBell charges them so much for the line. Remember that to get IDSL, you have to have an ISDN line. It was a losing deal for them. It probably still is.
PacBell charges less for a "normal" grade phone line used for ADSL/SDSL...
<<I'm shopping around for another DSL provider as I type. >>
I doubt you'll find a better situation. Everyone has to go through PacBell. (or whoever your regional baby bell is...)
<<If you can foot the bill Megapath is nice.. but it's creeping up towards business class DSL pricing that others offer.>>
Didn't they *lower* prices for ADSL/SDSL at the same time that they raised IDSL prices?
MegaPath has a distinction between personal and commercial accounts, however personal accounts can be used to run servers. You cannot use the server for commercial purposes however. That means no banner ads, e-commerce, etc...
Even when I had a personal account they were quite friendly helping me set up my domain name and the like...
We think of Linux and Open Source projects as being "secure." They are safe from most attacks in general... Once a problem arises, it is quickly fixed by the community -- and it is very likely to be found quickly.
The problem is that "trusted" within the infosec community means that you can reliably assume in a beyond-mission-critical environment that the system is totally secure from attack.
This means a careful, meticulous design, and very rigid, formal implementation and testing. The aspects involved are far more comprehensive and cohesive than Open Source generally considers...
We look at Open Source software in terms of the safety of a package. Sendmail is not secure, or QMail is secure, and imapd is not secure or... You get the idea... Building a trusted system means looking at the big picture -- as low level as how kernel data structures are defined and manipulated, to as high level as individual file permissions and pretty much everything in between...
IIRC, "trusted" Solaris tends to lag a couple versions behind the general release of Solaris and takes a bit of a performance hit. Why? Because it takes a lot of time to evaluate, and fix an OS to make it "trusted."
A simpler way of looking at the difference is this: A "trusted" system goes to great lengths to meticulously ensure that no edge cases exist. A "secure" Open Source system takes the shotgun approach: With enough monkeys pounding on enough keyboards for a long enough time you'll get the works of Shakespeare... Translation: Open Source counts on enough talented, skilled developers working on a project to cover all the cases without anyone specifically telling them to do so.
In the end, Open Source may or may not come out with a product whose security matches that of a "trusted" system -- but you wouldn't be able to recognize it if it did come out. You couldn't *verify* it.
NSI changed their polices so they own your domain name no matter what. Now if they get your contact info wrong for some reason or you change email addresses, its next to impossible to change said information.
That is an entirely seperate issue.
So, yes, everyone using NSI is at risk of being affected by this, not just deadbeats.
How? If the bill is paid on time the domain does not go up for auction. Period. I fail to see how the issue of screwed up contact info relates to this. They don't have to have your contact info right for your to pay your bill on time.
Using user submitted data is a double-edged sword. On the one hand it gives you a more realistic way to gather the neccesary information but then you have quality control issues. Bad data will necesarily lead to bad translations and just because you speak a language fluently or natively does not mean that you can accurately relate the rules of the language or describe contextual/circumstantial disambiguating information.
Such an engine would *not* be as good as current systems at the start because current systems are designed with their own weaknesses in mind. To get translation comparable to what current systems can do you'd either have to *use* a current system until enough data was provided, or you would have to start with a VERY large dataset.
But then there is an insurmountable theoretical problem: The smaller the corpus being translated, the less accuracy you will be able to get no matter how large your database. A single ambiguous sentence by itself can often not be disambiguated by even a human. If it is in the context of a paragraph or a page then more context is provided.
But the extraction and interpretation of contextual information is a task which by itself remains almost wholly unaddressed.
But let us for a moment assume that you have a system that using a large enough database (I'd guess we're talking TBs here, but that's pure speculation...) and was able to gather contextual information and disambiguate sentences. So now, you have a data structure that represents all the ideas you wish to convey in your text in a language-neutral fashion.
Then you have the problem of going the other direction. Now, you need a similar database for your target language, and your databases both must contain information about language-specific idioms and customs.
As my Japanese professor said "you do not *translate* English to Japanese (or vice versa), you *restate* your idea."
Even if your program could understand cultural context and understand the weight certain grammatical constructs/words/phrases are given in different contexts, how does the software "restate" your idea in a culturally meaningful manner?
Consider the Japanese phrase: "Nodo ga kawakimashita." Accurately translated it is "My throat has become dry." But a translation is clumsy at best here. A better way of stating it is "I am thirsty."
So you would need for each language, a HUGE, extremeley detailed database of grammatical, lexical, contextual, idiomatic, and cultural information for a given language that is interrelated at a higher level than just words or sentences. It would have to have culturally-significant weighting of concepts, ideas, grammatical structures, and words. On top of that you would need a very complex, detailed mapping between the database of each language.
Just as it is theoretically possible to move three tons of sand from New York to California using only a unicycle and a pair of tweezers, such a project is possible. However, the complexity and resource constraints make it all but impossible even for thousands go-get-em open source coding wizards and hundreds of thousands of community members.
The problem with translation systems is grammatical ambiguity. Computers lack the massive "database" of context which we humans have for resolving ambiguities.
How do you translate "plane"? It could be "plane" as in mathematics, or as in flying...
That's just one simple type of ambiguity. When you have a fluid grammar like English -- for which a BNF grammar cannot be made, regardless of how many tokens of lookahead you have -- the lack of context makes translation all but futile.
Assembling such a database is not a theoretical impossibility. It is however a *practical* impossibility for the present and foreseeable future.
I could have *sworn* that this story showed up on Slashdot not too long ago! In fact, the link showed up as having been visited and I remember having visited the site...
This isn't the first time I've had this Deja-Vu experience on Slashdot... It's happened several times recently. Am I just nuts, or is Slashdot reposting old stories??
-JF
10,000 job listings, news and info for web application developers:
A common attitude I've seen is "it's free, what do you expect?"
The reality is that Hotmail is not free. You view banner ads, you give up demographics information, and you put up with having numerous partner services pitched at you.
I work at a company that also does web based e-mail -- cobranded to your site's e-mail domain and look&feel... This service is free for end users, and free for web sites.
Our attitude is that it is unacceptable for even 1 e-mail to be lost. Downtime is unacceptable -- although admittedly we've had our fair share.
We strive for excellence in reliability, and availability. Why? Because our users (several million), are entrusting us with the most important means of communication on the Internet.
It is my perspective that downtimes like this are unacceptable: you *are* paying us -- with information, in many ways a more valuable commodity than money.
Demand more for your demographics and your time. You deserve it.
I agree with you on this point. Sheeple that will accept whatever crap a business peddles make far better customers than those who aren't willing to be fucked around and will demand the quality that they deserve. Just ask Micros~1.
Customers do not "accept whatever crap a business peddles." If a site is hard to use, does not provide sufficient content, or otherwise does not meet the consumer's needs they *will* and *do* go elsewhere. Calling the vast majority of users "sheeple" is at best, pompous. I have used more browsers than I can count, and because it is faster, more stable, and complies better with standards than other browsers I choose to use IE -- as does the majority of web users -- am I one of these "sheeple"?
Is someone among these "sheeple" if they don't *care* about the browser? Why *should* they have to care about the browser? It is just a tool. The only important factor is how well it does its job.
The fact which you have refused to address repeatedly is that things like images, CSS and JavaScript are VERY powerful tools to improve usability, readability, and performance of web based applications and information.
Simple features like color can be powerful tools for making information easier to analyze and absorb. Witness SourceForge's bug database which uses the background color of a table row to denote the severity of a bug. A quick glance gives you a pretty good idea of the shape that the project is in: A lot of red indicates that the code is riddled with severe bugs... Layout is even more important.
And of course, branding is imporant to any company that wishes to survive. Customers (and that means companies as well as individuals) wont use a service if they forget it exists. This apparently matters even among techno-savvy users -- witness the success of RedHat versus other distributions.
IME customers go both ways - perhaps yours want whizz-bang graphics that explode off the page at them.
You have repeatedly tried to set up the abuse of capabilities as a straw man to distract from the real argument. I reject this argument. That's like saying "drunk drivers kill lots of people, so cars should not be used!"
The real argument here is about standards and progress. You apparently do not see new and evolving standards as being progress. Therefore your opinion is that web developers should not use them. You might as well complain that you can't access all these web sites using Gopher.
I see new and evolving standards as a means to deliver a better service. If I develop a web based application, things like JavaScript provide me with a way to deliver a user interface to the application that does not go against 20+ years of usability research and information theory. I can provide information in a cleaner, simpler visual layout and put more functionality on the page with a simpler appearance. Not only that, I can make the performance of the application FASTER for my users: Why should search results be sorted on the server? Why not have the client-side sort the results of a search instead of having to open a connection to the server, make a request, have the server sort the results, and then send the entire page back for the browser to re-render.
When I was teaching a course on browsing the web with Netscape, most of the newbie-students I was teaching were overwhelmed by how loud many of the pages were. ("It's so busy" were one's exact words.)
That is an example of poor usability. The abuse of a tool does not invalidate the tool.
As for hardware, running Netscape 4.0 on a P120/16MB is a painful experience.
Buy a better computer. A $400 eMachine has a 500Mhz CPU, 32MB of RAM, and 4.3GB HD. It also comes with Windows, and thus IE which as I pointed out before, is more compliant with standards than Netscape 4.x -- not to mention that IE runs very well on such a computer. You can get an equally good machine used for much less.
Netscape 6 is miserable. Opera is bearable but costs money. None of them are open source, and if it was my decision my Win95 install would be on the losing end of a HD reformat. I am far happier with lynx and w3m.
Since when is Netscape 6 not Open Source? And yes, performance sucks right now -- it's in *beta* and has all sorts of debugging code in it. By the time it's released it will not only comply with standards better than any browser out, it will be vastly faster than almost any other browser.
If you are happy with Lynx, then fine. Use it. But don't complain about web developers using *industry accepted* standards that you have consciously chosen to ignore.
My point was that it doesn't require maintaining two separate versions of a page, unless your entire site is flash or some such crap.
Not true. Using a significant subset of the HTML, CSS, DOM, and ECMAscript standards one can write a very functional, standards compliant web page that works perfectly under IE, and Opera (4.0) but fails miserably under Netscape.
Supporting Netscape alone requires additional effort due partly to its exceedingly poor standards support, and partly because of bugs. Nonetheless, it at least provides most of the relevent capabilities in one form or another whereas Lynx does not.
Using Javascript for all of your nav functions just seems plain ridiculous when there are these perfectly functional things called *hyperlinks*
Hyperlinks are not the end-all, be-all of navigation. They can be entirely inadequate, or result in a slower, clunkier browsing experience. Using, for example, drop-down menus can save the user one or more page views at several seconds per page view. It also makes finding what you are looking for easier. Yes, like anything, ECMAscript can be abused. I, however, am not going to avoid using it where it will legitimately help make my site more usable just because you hide behind such excuses.
Usability matters. Tech-savvy individuals who ignore standards do not.
Lynx and other browsers that don't use scripting or plugins just ignore them.
So basically, your complaint is "my browser doesn't support accepted industry standards, and I can't use sites that rely on those standards, so nobody should use them!"
If you need to create two totally separate versions, then IMHO, you're doing it wrong.
Spoken like someone who has never had a customer base of normal (non-tech-savvy) individuals. Customers will not conform to your whims. They will go *elsewhere* if they are unhappy. Therefore, if one wishes to be successful, one must conform to *them*.
As for doing things wrong... If you *don't* have to create two seperate versions of a page -- one with and one without JavaScript then your JavaScript code is probably just eye-candy (useful in branding but generally not useful in aiding navigation). Most uses of JavaScript on sites of any significance these days are *not* just eye candy.
One example would be expandable/collapsable tree views, and tabbed sections. Yes, these can be trivially implemented on the server but that creates more load for your server, and involves more page reloads for the end user -- a very frustrating experience. A little ECMAscript and DOM make for a much more usable site. But for those using browsers that choose to not support ECMAscript, the only alternative is to code *both* versions and send the appropriate HTML depending on who is visiting your site.
1. Why lump in old browsers with ones that aren't standards compliant?
Because standards progress. The end result -- whether you use an old browser, or a non-compliant browser -- is that I, as a developer, cannot use those standards.
Historically, Netscape and IE have been the worst for desecrating the HTML standard.
Define "desecrate." If you mean they added stuff to the standard, then sure, they've "desecrated" it. If you mean failing to implement a substantial amount of the relevent defined standards, then Lynx has a far worse record here. Netscape isn't much of a prize in that regard either. Mozilla and IE are the only browsers on the market that correctly implement a very large subset of the most recent DOM, CSS, and ECMAscript standards.
Lynx adheres to the standards strictly enough that it uses special parsing modes to emulate the most common Netscape- and Microsoft-introduced screw ups necessary to make many pages useable.
Yet Lynx chooses to ignore the progress made in standards. XML, CSS, ECMAscript, DOM -- these are all *industry standards* that Lynx chooses not to implement.
2. Some people are stubborn (like me) and refuse to use K00lBrowser6.66, but others don't have a choice. (old hardware, shell account...)
First off, it's not *my* fault that Lynx refuses to implement standards. Nor is it the fault of the majority of users using (nearly) standards-compliant browsers. I refuse to punish the 86% or so of my users that are using standards compliant browsers because of the actions of *your* browser vendor. As part of the development of Opera for Linux, they developed a text based version which had basically all the same support for HTML, CSS, and ECMAscript that the graphical version of Opera does. If you are forced to use a shell account, then you should be demanding that the Lynx crew keep up with standards. (Translation: Complain to the lazy slobs that made your browser.)
As for old hardware -- a $500 eMachines box is *more* than adequate for running a decent browser. That's new. Used computers that are capable of running at least as well can be had for a couple hundred if you shop around.
If you can't afford that, then don't you have more important things to be spending money on than internet access -- such as food perhaps? Or maybe rent?
3. Lynx is up to date - my build here is 2.8.3rel.1 (23 Apr 2000).
You misunderstand me. I did not mean to say it was not being maintained. I said it was not up to date with standards. It has not been updated to support recent standards.
or do us "luddites" not count as real "users"? =)
No, actually, you do not -- from a business standpoint. You are far more technologically savvy than the vast majority of users who visit most web sites. (Slashdot and other niche sites being an exception because of their tech-oriented nature) You are someone who is aware of standards, their significance, the various browsers and such. You choose to ignore progress in standards. From the standpoint of a business you are a poor potential customer choice. You would cost a lot of money to support, and you are less likely to spend money on my product/service than someone who is at least willing to download a *free*, nearly standards compliant web browser.
Not being on the lynx-dev list, I can't say.
It was a rhetorical question. The answer does not matter. The point is that JavaScript (aka ECMAscript) is not supported. This standard, which is important to improving the end-user experience of the web, is not supported. Period.
Maybe because it would add what is perceived as too much bulk to the program
Lynx 2.8.3 in bz2 form is 1.6MB. Opera 4.0 for Linux (tech. preview 4) in bz2 form is 900KB. Remember, Opera supports HTML 4.0, ECMAscript 1.1, CSS 1, and a large subset of CSS 2. To be fair, printing is unimplemented as of yet...
Remember, CPU/memory/ROM constrained devices like cell phones have (limited) ECMAscript support. That's on hardware that's only a step above XT-class machines.
It seems to me that Lynx is already pretty bloated. Perhaps then, this is a valid concern: Perhaps the developers are not capable of producing a standards compliant browser that can run on the limited machines where Lynx is ostensibly preferred?
maybe because no one cares to implement it.
If you choose to use a browser whose developers are too lazy/self-absorbed to care about implementing standards, why should I -- as a developer -- care about you? Why should I care about someone who is going to blame me for someone else's problem (that would be the developers of Lynx, in case it wasn't obvious)?
I know I couldn't be arsed to put full java applet support in
I never said anything about Java. Java is not an industry standard. ECMAscript (aka JavaScript -- no relation WHATSOEVER to Java except that they both have a "C-like" syntax) is an industry standard and is implemented by nearly every browser to a greater or lesser degree.
If you look around, you'll notice that most sites don't use Java for much any more. Why? It's slow, it's unreliable, and it doesn't usually improve the end-user experience substantially more than comparable ECMAscript.
Even WAP-enabled *cell phones* support a subset of ECMAscript.
Say you're putting up a building. Only 0.1% of the users of your building are in wheelchairs, using crutches, or don't fit into the "able-bodied" typecast in some other way. By your argument, it certainly doesn't make economical sense to put in elevators or wheelchair ramps, does it?
The difference here is that there is nothing stopping you from getting a standards compliant browser. A wheelchair-bound individual does not have the option of getting out of the wheelchair.
Are you honestly going to compare you *conscious choice* to use a crippled browser with the hurdles faced by people who *have no choice* about their situation? That is the single most arrogant argument I've heard yet...
Also keep in mind that wheelchair access is required by law. Why? Precisely because it does not make financial sense to provide it so the government intervened. Faced with the expense of providing wheelchair access versus the expense of having your business shut down... Wheelchair access *does* make financial sense.
Your argument about shell accounts misses the point: Browsers do not have to be graphical to support the present standards. Your argument about costly hardware is equally specious: Hardware is cheap enough that you'd almost have to be on food stamps to not be able to afford a computer that can run, say, Opera. Or Internet Explorer (it requires less memory than Netscape). Also, Lynx requires a 386 and several MB of RAM -- if old, cheap hardware is its target, why don't they support DOS on a 286 with 1MB of RAM?
If you don't like it, then either complain to the Lynx developers, or upgrade your browser. Don't whine to me about the situation you have chosen to put yourself in.
Why do webmasters assume people are using Windows, and the "latest" web browsers? Because they are.
Except for niche sites like Slashdot and other open source/free software community sites the vast majority of users that hit a site will be using IE on Windows (mostly 4.x+), followed by NS on Windows (mostly 4.x+), followed by IE on the Mac (mostly 4.5+), and followed distantly by NS on the Mac. (mostly 4.x+)
My site is usable under Lynx and such -- no JavaScript/Flash/Java/whatever to get in the way of things, and no frames for example.
A quick breakdown of my site reveals 51% using IE, 31% using Netscape, 0.4% using Lynx, and about 0.8% using Opera. 13% is attributable to AvantGo -- but that's almost entirely because I have a personal sub-site which I access from my Pilot. Most of the rest are bots.
A breakdown by OS: 86% use some form of Windows, 9% use Linux, and MacOS is around 0.9%. FreeBSD is just under MacOS.
Broken down by browser version, the number of users accessing my site with IE/NS 4.0 is less than 1% *total*.
The Linux/MacOS numbers are skewed in favor of Linux vs. the "normal" breakdown for big sites because most of the users that come to my site come from Slashdot.
I'll get to the significance shortly.
Companies are rightly concerned with presentation. Presentation does matter to the general public. It is time consuming to make a version of a site that for older browsers when you value detailed control over presentation.
What does poor presentation mean for a company? Poor brand recognition. Poor customer first impression. Lower sales/usage. Lower customer retention.
It is only *economically sensible* to support a browser if the cost of doing so is lower than the increase in sales/banner impressions/whatever gained by doing so.
Supporting Lynx makes no sense for a site that is banner-revenue based: Lynx isn't going to display the banners. So Lynx support only makes sense if you have a pay service. (and, as above, if the income from Lynx users outweighs the cost of making a Lynx-compatible version)
Every major site supports both Netscape and IE. Almost every web application developer grumbles at the difficulty of doing so -- primarily because Netscape (excluding Mozilla) has very poor standards support and a ton of bugs. It is a *major effort* to support a site of any significant complexity on just the two major browsers.
Eventually, if and when Mozilla becomes more widely used then NS 4.x -- and it's still widely used enough that it is statistically significant -- then we'll be at a point where web developers may be able to just make pages to the standards. HTML 4.0, CSS1/2, DOM1, and ECMAscript 1.3...
When I have time to work on my site, I'd rather work on improving the functionality for the 82.8% of my users who use a recent browser than make the existing functionality work better for the 17.2% of my "users" who either refuse to use a decent, up to date, standards compliant browser or are robots. It's just a more effective use of my time and energy.
One more thing: The WAP protocol (which is largely a subset of HTTP, HTML, and other such standards) includes a subset of ECMAscript. That means that text-based cell phones can run some JavaScript code. Why doesn't Lynx even support JavaScript yet?
Cross platform toolkits sound like a good idea. You can support more platforms with minimal effort. Good thing, right?
Well, the *goal* is a good thing. The methodology is a VERY VERY bad thing. I've only seen one toolkit with the potential to avoid the problems I'm about to describe, and it's not being used to do so.
Every GUI established conventions. These range from the trivial (CTRL-INS is copy, SHIFT-INS is paste) to the non-trivial (buttons on confirmation/warning/etc dialogs are right-aligned) to the very high-level. (actions that can be performed should be described using the present progressive tense)
Simple toolkits can only manage the simplest of these conventions (such as keystroke bindings) and even then can do so only partially... Anything where you have to explicitly state the, say, keyboard binding is beyond the control of the toolkit.
More abstract toolkits such as JFC, and Qt (probably GTK also, although I don't have any real experience with it so I can't be sure...) -- ones that use geometry managers -- can handle some of the higher-level stuff such as button alignments.
A very rich toolkit can provide even higher level stuff -- such as file open/save dialogs -- in a sufficiently generic manner.
But things such as linguistic conventions, i18n support, and broader conventions of UI layout are beyond the control of any toolkit to provide.
The end result is that an application you port winds up not feeling or acting like a native application. This throws users off and makes things harder for them. Unless they happen to be very sohpisticated users familiar with multiple GUIs of course.
The only toolkit I know of which has the *potential* for getting around this is Mozilla's XPToolkit -- and it isn't *just* the toolkit that's needed. Basically, the entire UI is written as a bunch of XML and JavaScript.
You could have platform-specific XML/JavaScript front-ends with the exact same back-end code.
But that's a hybrid solution (it has drawbacks such as having to support a fair amount of platform-specific code), requires careful design of the appliction, and is generally not feasible.
The Mozilla group certainly isn't taking advantage of it -- they just have their AOL/Netscape UI on all platforms and it is up to the user to create/find a platform-specific UI.
<> The only perspective that matters is that of whoever holds the purse strings -- the investors.
<<Even many people who start up companies are more interested in making a culture of innovation (no, I do not mean Microsoft), and money is a resource to that end. >>
I worked at such a company. It no longer exists. Mistakes were made -- we let concerns other than the bottom line drive us and we paid for it.
<<Concepts do not exist in a vaccuum, they do not have an independent reality from those who consider them.>>
Yes, so? An employee is essentially a very powerful tool. Just as a compiler provides an important function, so does an employee -- coming up with ideas, concepts, whatever.
I'm not saying that employees are just substitutes for machines -- far from it. Employees are the most important tool a company has. But they are still a tool. They are a means of accomplishing a goal.
Survival -- and that means making more money than you spend -- is the first goal of any long-lived company.
I'm merely being realistic. Sure, they aren't in danger of running out fo money *right now*, but they will be if they don't make the right business decisions.
How much good does it do any of the employees if the company goes bankrupt? I've actually had that happen to me. It's not fun when you've put your heart and soul into something only to have the CEO tell you "well, the funding fell through and we're out of angel capital..."
I don't neccesarily think this is a particular great way for economics to work, but that's how they do. You waste enough money, you go out of business. If an employee is not raising the bottom line at least as much as they are lowering it, then the employee is a drain on resources.
They aren't in danger of running out of money, but they are in danger of not becoming profitable in an acceptable time frame.
Just because you have enough money to keep all your employees does not mean it is financially sound to do so.
If they are spending $10,000,000 per *year* just on people -- and the figure is likely to be higher when you consider facilities, managerial/HR overhead, equipment, etc -- try to think of how much they have to make per year to be profitable.
Assuming that they only lost a quarter of their gross income to taxes, and they had 200 employees to start out with (I don't know how many employees they had, I'm just using your example) they'd need over $13M in gross revenues annually just to break even. Again, not counting anything but salaries.
Assuming a couple million for manufacturing/distribution, as much for marketing/sales operations (people wont buy what they don't know about) and say, a couple million for everything else I mentioned above, that's $16M per year in costs or more than $21M in gross revenues...
Now, cut $5M off the top if they cut half their staff... Now they only need about $14.7M in gross revenues... At $50 per sale, that would mean they have to *sell* 293,000 or so copies of TurboLinux EVERY YEAR.
These numbers are wildly off, I'm sure. But the same principle applies regardless of the numbers. Yes, cutting staff reduces their ability to do things like develop cool clustering and such. But if that cool clustering stuff isn't resulting in increased sales that meet or exceed the cost of the overhead of doing the development... Well, you do the math.
You need to remember something: Companies do not exist to give you, the employee a paycheck. Companies exist to make money. Employees are a resource used to that end. It's the simple realities of economics.
The legalese is almost assuredly unnecesary. It's illegal to break into your box and you don't have to explicilty reserve your rights in that regard.
Now, not to advocate "security through obscurity", but posting information about the system that is potentially useful to crackers is a Very Bad Idea. Sure, they may very well be able to get it through other means, but the way you make a system unattractive to hackers is to make it harder and more tedious to break into your system than the next system...
Make them fight for every inch.
But this is all somewhat beside the point. There are far more important, fundamental security measures than what your/etc/issue says. Like disabling external telnet access for one. Set up SSH instead so passwords aren't sent in the clear. Disable unused services. Keep up to date with patches. If you run a web server and do any kind of CGI, be mindful of your code: If you use Perl, then use "-w -T" and "use strict;" all over the place. Again in Perl, use the multi-parameter version of "system" if you must use it at all -- "system('ls', '-l', '/home/foo')" instead of "system('ls -l/home/foo')".
Slashdot Mirror
We were *not* supposed to hate Magneto. It's not supposed to be as simple as "X-Men good. Magneto bad. Humanity innocent victims."
The lines are not so well defined. Sometimes humanity isn't worth saving. Sometimes Prof. X's quest seems rather quixotic. Sometimes Magneto has the right idea -- fighting for the survival of his species. But that's why X-Men is so great.
-JF
<>
Hotmail's choice of OS is irrelvent to my point. I was making a comment about their *business model* being such that forcing them to give up their source code would entirely eliminate Open Source/Free Software as an option for them. The same would apply if they were using Hurd, or NT.
Slashdot can afford to give away the Slash engine source -- their business model doesn't center around the functionality of the site, but rather the content.
-JF
<>
.com's goodbye as they move to another platform.
If I allow you to run my application via an X server, it is MY CPU time being used, MY memory, MY storage space, etc.
You don't have a copy of the software. You're not even running it on your system. Why should I be forced to turn over my source code to you when it's not even running on your machine?
But if you really want to do this, go right ahead. It will force many companies now using Open Source software to abandon it entirely. Not all business models have software as an "incidental" -- like Slashdot. Most Internet business models would be incompatible with such a license.
Kiss IBM's support of Linux and use of/contribution to Apache goodbye. Kiss most of the
Let us say that eProject.com used Linux, Apache, Perl, and some CPAN modules. If you changed the license as everyone is advocating, how would their business model work? What business model could you find that would be even close to viable -- and still use Free software?
-JF
<>
While some people see this "loophole" as a flaw(CmdrTaco included) I see it as being a *neccesary* "loophole" if you want the commercial Internet industry to adopt open source/Free software.
Why would I use Free software for my web based application if I had to redistribute my code?
If my only means of competing right now are features, performance, database (I.E. the breadth and depth of data -- content, etc...), and marketing then this would eliminate features and performance as a competitive advantage. Not all web based companies are content-based like Slashdot: Some, like Hotmail, are based on functionality.
It just doesn't make business sense to have to redistribute your code unless your code doesn't give you a significant competitive advantage. So for sites like Slashdot it's not a problem. For sites like Hotmail, eProject.com, or wherver -- it's a problem.
My employer uses Perl, Apache, Linux, MySQL, and other such systems right now. If the licenses were changed such that we'd have to redistribute our code, we'd be forced to either not upgrade to a version under the new license, or to rewrite everything in a system that doesn't have such draconian licensing.
The ideals of the Free software movement are all well and good, but even RMS hasn't shown a viable (read: profitable) business model that fully adopts them -- and even if he could, one business model doesn't cover every idea.
-JF
<>
That's a different issue. Lewinsky's purchase history was based on *financial* records. Financial records MUST MUST MUST be kept to help eliminate errors, and correct them when they do arise. Not to mention for tax purposes...
-JF
<>
:) Yes, it can be annoying, but certainly not a critical failing...
I'll look into it, but I doubt I'll get the go ahead for such a thing...
<<Depending on the nature of the application, you could consider using something like a server program with either memory-resident data or fixed-format data files (perhaps even using MySQL for this limited application), to act as a buffer between the web server and the database.>>
Actually, our Oracle-experienced engineer says that this is what he had to do for (I think) AT&T because of Oracle's abysmal write performance.
However, this depends on a couple things...
First, that your system traffic is cyclical in nature, having a period of time where the traffic on the system is lower than the write performance of the database (the catch-up period) that is proportional to the period of time where write-performance is exceeded.
Second, that you don't immediately need the data, or that you be willing to institute a failover lookup mechanism that allows you to check the buffer for pending data.
For us, our performance cycle is narrowing as we start handling more and more international clients. And for our application, delaying commitment of data for a few hours is just unacceptable.
The solution we're considering would best be described as "perpendicular" to this line of thought, although I can't really go into much more detail.
<<For example, as a large schema evolves, views can be used to support legacy code with the table structure they expect, when the underlying tables may have changed or been split into multiple tables.>>
Eek. In a perfect world one would not be re-normalizing schema periodically *after* you go to production... But it does happen. One would think however that to do so, it would be wise to review dependent code to eliminate "bit-rot" anyway.
<<They can also be very useful during development as a way of reusing queries, i.e. a particular multi-way join that gets used repeatedly can be implemented as a view and then used in other queries.>>
I'll concede this one... Although most of the situations I've encountered involved either fairly simple queries, or complex queries that were put together very dynamically. (picture a natural join that can have between 3-10 tables and *lots* of context-dependent conditions...)
<<Finally, views can support standard ways of browsing and querying the data using client tools, by users or support personnel who would find the highly normalized underlying schema difficult to deal with. >>
Only if they are using a generalized table-browser -- yech! A web-based front-end application is usually pretty trivial to put together, and generally far more intuitive to use. Although again, I can see instances where this makes sense...
<<The feature I suspect I would find most difficult to live without, using MySQL, is enforcement of referential integrity.>>
It's one of those sacrifice-features-for-performance type of deals. If you have transactions, it shouldn't be neccesary. If you don't have transactions then you'd better be darn careful.
<<Also, what about stored procedures? I have the impression it doesn't support them? In more complex systems, more work is done in stored procedures that feed the results of one query into subsequent queries, than is done by stand-alone queries, so doing without stored procedures would be a crippling problem. But I admit I'm now talking about far more complex applications than the target audience for MySQL.>>
Never used them myself... But yeah, having them would be nice...
-JF
<>
Unfortunately the big commercial databases (read: Oracle and DB2) have some critical limitations of their own.
I work at a company that has dozens of tables, some of which have tens of millions of rows. We're a web based company and we serve millions of dynamically generated page views per day. We use MySQL, and are debating our options for the future right now.
In the past we looked at DB2 (ported our flagship product to it for testing), and we've spoken with people who've used Oracle -- the conclusion we've come to is that for certain classes of problems, performance is just unacceptably bad for Oracle and DB2.
Specifically, write performance is a problem. Now, MySQL isn't uniformly better: Table level locking is a SERIOUS problem, but at least there is a window of load where write performance is acceptable, and some tuning of your application can usually alleviate related problems quite well.
In our test of DB2, versus MySQL, using a C-based client in a fairly "real world" (read: Access patterns similar to our product) Db2 was only able to get 9 inserts per second into a crucial table. If we turned transaction logging off (which the DB2 guys said was a Very Bad Thing -- and did in fact cause massive problems) we got that up to 31 inserts per second. We tweaked and tuned things with help from IBMs engineers.
MySQL consistently got over 1,000 inserts/sec on the same hardware, with the same schema, and the same access patterns.
Also, the time it takes to establish/break down a connection to the database can be an issue. Connection pooling helps, but if you've got a situation where you have more clients than possible connections, and not all of the clients will always need a connection then you can get into a situation where clients that *do* need a connection have to wait because clients that *dont* need one still have the connection in their pool. In such a case, if you are using MySQL, one can get better performance by turning connection pooling *off*. That's not a *common* occurence, but certain classes of web applications can experience it.
Also, some features of MySQL can obviate the need for some of the "advanced" features of the commercial databases. Consider "views". As I understand it, there are two basic reasons to use a view:
1) To provide finer-grained security than is otherwise attainable with table-level security. (essentially, per-column security) MySQl already supports per-column access priviledges, so this use of views is unnecesary.
2) To allow/simplify some complex joins. I'm told by an engineer here with Oracle experience that left joins with multiple unprotected tables and one protected table aren't *directly* possible with Oracle -- the solution is to use views. You want to join A, B, C, and D with only A being protected. Make a view called A1 of A and B, make a view called C1 of A1 and C, and then left join C1 and D. MySQL supports left joins with multiple unprotected tables very easily -- so no need for views here.
Obviously these features aren't applicable in 100% of cases, but in a great many situations, the "limitations" of MySQL really aren't as bad as they sound.
And just for the record,as is briefly noted in the article, transaction support and page level locking is supported in the 3.23.x development series using Berkeley DB as the table handler. You have a per-table choice of which handler you want -- ISAM/MyISAM is the "normal" type (fast, disk-based, no transactions, table level locking), Heap (very fast, memory based, no transactions, table level locking), and BDB. (somewhat slower, full transactions, page level locking)
-JF
<>
That's because PacBell charges them so much for the line. Remember that to get IDSL, you have to have an ISDN line. It was a losing deal for them. It probably still is.
PacBell charges less for a "normal" grade phone line used for ADSL/SDSL...
<<I'm shopping around for another DSL provider as I type. >>
I doubt you'll find a better situation. Everyone has to go through PacBell. (or whoever your regional baby bell is...)
<<If you can foot the bill Megapath is nice.. but it's creeping up towards business class DSL pricing that others offer.>>
Didn't they *lower* prices for ADSL/SDSL at the same time that they raised IDSL prices?
-JF
MegaPath has a distinction between personal and commercial accounts, however personal accounts can be used to run servers. You cannot use the server for commercial purposes however. That means no banner ads, e-commerce, etc...
Even when I had a personal account they were quite friendly helping me set up my domain name and the like...
-JF
There is a publication called "Books in Print" -- published annually IIRC in both print (takes several shelves of a bookcase) and CD-ROM formats.
It is intended to be a comprehensize reference of all books published, including ISBN. I'm unsure of the license fee...
Looking at http://www.bowker.com/ it seems there is also a "Books out of Print" too...
These are likely to be pricey, but probably exactly what you need/want.
We think of Linux and Open Source projects as being "secure." They are safe from most attacks in general... Once a problem arises, it is quickly fixed by the community -- and it is very likely to be found quickly.
The problem is that "trusted" within the infosec community means that you can reliably assume in a beyond-mission-critical environment that the system is totally secure from attack.
This means a careful, meticulous design, and very rigid, formal implementation and testing. The aspects involved are far more comprehensive and cohesive than Open Source generally considers...
We look at Open Source software in terms of the safety of a package. Sendmail is not secure, or QMail is secure, and imapd is not secure or... You get the idea... Building a trusted system means looking at the big picture -- as low level as how kernel data structures are defined and manipulated, to as high level as individual file permissions and pretty much everything in between...
IIRC, "trusted" Solaris tends to lag a couple versions behind the general release of Solaris and takes a bit of a performance hit. Why? Because it takes a lot of time to evaluate, and fix an OS to make it "trusted."
A simpler way of looking at the difference is this: A "trusted" system goes to great lengths to meticulously ensure that no edge cases exist. A "secure" Open Source system takes the shotgun approach: With enough monkeys pounding on enough keyboards for a long enough time you'll get the works of Shakespeare... Translation: Open Source counts on enough talented, skilled developers working on a project to cover all the cases without anyone specifically telling them to do so.
In the end, Open Source may or may not come out with a product whose security matches that of a "trusted" system -- but you wouldn't be able to recognize it if it did come out. You couldn't *verify* it.
-JF
NSI changed their polices so they own your domain name no matter what. Now if they get your contact info wrong for some reason or you change email addresses, its next to impossible to change said information.
That is an entirely seperate issue.
So, yes, everyone using NSI is at risk of being affected by this, not just deadbeats.
How? If the bill is paid on time the domain does not go up for auction. Period. I fail to see how the issue of screwed up contact info relates to this. They don't have to have your contact info right for your to pay your bill on time.
-JF
I own three domains myself, and I am not particularly happy about this.
This only affects you if you have not paid for your domains. If you have not paid for them, they are not yours.
If you aren't "happy" about this then either you haven't paid your bills as you contractually agreed to do, or you aren't affected.
-JF
Using user submitted data is a double-edged sword. On the one hand it gives you a more realistic way to gather the neccesary information but then you have quality control issues. Bad data will necesarily lead to bad translations and just because you speak a language fluently or natively does not mean that you can accurately relate the rules of the language or describe contextual/circumstantial disambiguating information.
Such an engine would *not* be as good as current systems at the start because current systems are designed with their own weaknesses in mind. To get translation comparable to what current systems can do you'd either have to *use* a current system until enough data was provided, or you would have to start with a VERY large dataset.
But then there is an insurmountable theoretical problem: The smaller the corpus being translated, the less accuracy you will be able to get no matter how large your database. A single ambiguous sentence by itself can often not be disambiguated by even a human. If it is in the context of a paragraph or a page then more context is provided.
But the extraction and interpretation of contextual information is a task which by itself remains almost wholly unaddressed.
But let us for a moment assume that you have a system that using a large enough database (I'd guess we're talking TBs here, but that's pure speculation...) and was able to gather contextual information and disambiguate sentences. So now, you have a data structure that represents all the ideas you wish to convey in your text in a language-neutral fashion.
Then you have the problem of going the other direction. Now, you need a similar database for your target language, and your databases both must contain information about language-specific idioms and customs.
As my Japanese professor said "you do not *translate* English to Japanese (or vice versa), you *restate* your idea."
Even if your program could understand cultural context and understand the weight certain grammatical constructs/words/phrases are given in different contexts, how does the software "restate" your idea in a culturally meaningful manner?
Consider the Japanese phrase: "Nodo ga kawakimashita." Accurately translated it is "My throat has become dry." But a translation is clumsy at best here. A better way of stating it is "I am thirsty."
So you would need for each language, a HUGE, extremeley detailed database of grammatical, lexical, contextual, idiomatic, and cultural information for a given language that is interrelated at a higher level than just words or sentences. It would have to have culturally-significant weighting of concepts, ideas, grammatical structures, and words. On top of that you would need a very complex, detailed mapping between the database of each language.
Just as it is theoretically possible to move three tons of sand from New York to California using only a unicycle and a pair of tweezers, such a project is possible. However, the complexity and resource constraints make it all but impossible even for thousands go-get-em open source coding wizards and hundreds of thousands of community members.
-JF
The problem with translation systems is grammatical ambiguity. Computers lack the massive "database" of context which we humans have for resolving ambiguities.
How do you translate "plane"? It could be "plane" as in mathematics, or as in flying...
That's just one simple type of ambiguity. When you have a fluid grammar like English -- for which a BNF grammar cannot be made, regardless of how many tokens of lookahead you have -- the lack of context makes translation all but futile.
Assembling such a database is not a theoretical impossibility. It is however a *practical* impossibility for the present and foreseeable future.
-JF
I could have *sworn* that this story showed up on Slashdot not too long ago! In fact, the link showed up as having been visited and I remember having visited the site...
This isn't the first time I've had this Deja-Vu experience on Slashdot... It's happened several times recently. Am I just nuts, or is Slashdot reposting old stories??
-JF
10,000 job listings, news and info for web application developers:
A common attitude I've seen is "it's free, what do you expect?"
The reality is that Hotmail is not free. You view banner ads, you give up demographics information, and you put up with having numerous partner services pitched at you.
I work at a company that also does web based e-mail -- cobranded to your site's e-mail domain and look&feel... This service is free for end users, and free for web sites.
Our attitude is that it is unacceptable for even 1 e-mail to be lost. Downtime is unacceptable -- although admittedly we've had our fair share.
We strive for excellence in reliability, and availability. Why? Because our users (several million), are entrusting us with the most important means of communication on the Internet.
It is my perspective that downtimes like this are unacceptable: you *are* paying us -- with information, in many ways a more valuable commodity than money.
Demand more for your demographics and your time. You deserve it.
-JF
I agree with you on this point. Sheeple that will accept whatever crap a business peddles make far better customers than those who aren't willing to be fucked around and will demand the quality that they deserve. Just ask Micros~1.
Customers do not "accept whatever crap a business peddles." If a site is hard to use, does not provide sufficient content, or otherwise does not meet the consumer's needs they *will* and *do* go elsewhere. Calling the vast majority of users "sheeple" is at best, pompous. I have used more browsers than I can count, and because it is faster, more stable, and complies better with standards than other browsers I choose to use IE -- as does the majority of web users -- am I one of these "sheeple"?
Is someone among these "sheeple" if they don't *care* about the browser? Why *should* they have to care about the browser? It is just a tool. The only important factor is how well it does its job.
The fact which you have refused to address repeatedly is that things like images, CSS and JavaScript are VERY powerful tools to improve usability, readability, and performance of web based applications and information.
Simple features like color can be powerful tools for making information easier to analyze and absorb. Witness SourceForge's bug database which uses the background color of a table row to denote the severity of a bug. A quick glance gives you a pretty good idea of the shape that the project is in: A lot of red indicates that the code is riddled with severe bugs... Layout is even more important.
And of course, branding is imporant to any company that wishes to survive. Customers (and that means companies as well as individuals) wont use a service if they forget it exists. This apparently matters even among techno-savvy users -- witness the success of RedHat versus other distributions.
IME customers go both ways - perhaps yours want whizz-bang graphics that explode off the page at them.
You have repeatedly tried to set up the abuse of capabilities as a straw man to distract from the real argument. I reject this argument. That's like saying "drunk drivers kill lots of people, so cars should not be used!"
The real argument here is about standards and progress. You apparently do not see new and evolving standards as being progress. Therefore your opinion is that web developers should not use them. You might as well complain that you can't access all these web sites using Gopher.
I see new and evolving standards as a means to deliver a better service. If I develop a web based application, things like JavaScript provide me with a way to deliver a user interface to the application that does not go against 20+ years of usability research and information theory. I can provide information in a cleaner, simpler visual layout and put more functionality on the page with a simpler appearance. Not only that, I can make the performance of the application FASTER for my users: Why should search results be sorted on the server? Why not have the client-side sort the results of a search instead of having to open a connection to the server, make a request, have the server sort the results, and then send the entire page back for the browser to re-render.
When I was teaching a course on browsing the web with Netscape, most of the newbie-students I was teaching were overwhelmed by how loud many of the pages were. ("It's so busy" were one's exact words.)
That is an example of poor usability. The abuse of a tool does not invalidate the tool.
As for hardware, running Netscape 4.0 on a P120/16MB is a painful experience.
Buy a better computer. A $400 eMachine has a 500Mhz CPU, 32MB of RAM, and 4.3GB HD. It also comes with Windows, and thus IE which as I pointed out before, is more compliant with standards than Netscape 4.x -- not to mention that IE runs very well on such a computer. You can get an equally good machine used for much less.
Netscape 6 is miserable. Opera is bearable but costs money. None of them are open source, and if it was my decision my Win95 install would be on the losing end of a HD reformat. I am far happier with lynx and w3m.
Since when is Netscape 6 not Open Source? And yes, performance sucks right now -- it's in *beta* and has all sorts of debugging code in it. By the time it's released it will not only comply with standards better than any browser out, it will be vastly faster than almost any other browser.
If you are happy with Lynx, then fine. Use it. But don't complain about web developers using *industry accepted* standards that you have consciously chosen to ignore.
-JF
My point was that it doesn't require maintaining two separate versions of a page, unless your entire site is flash or some such crap.
Not true. Using a significant subset of the HTML, CSS, DOM, and ECMAscript standards one can write a very functional, standards compliant web page that works perfectly under IE, and Opera (4.0) but fails miserably under Netscape.
Supporting Netscape alone requires additional effort due partly to its exceedingly poor standards support, and partly because of bugs. Nonetheless, it at least provides most of the relevent capabilities in one form or another whereas Lynx does not.
Using Javascript for all of your nav functions just seems plain ridiculous when there are these perfectly functional things called *hyperlinks*
Hyperlinks are not the end-all, be-all of navigation. They can be entirely inadequate, or result in a slower, clunkier browsing experience. Using, for example, drop-down menus can save the user one or more page views at several seconds per page view. It also makes finding what you are looking for easier. Yes, like anything, ECMAscript can be abused. I, however, am not going to avoid using it where it will legitimately help make my site more usable just because you hide behind such excuses.
Usability matters. Tech-savvy individuals who ignore standards do not.
Lynx and other browsers that don't use scripting or plugins just ignore them.
So basically, your complaint is "my browser doesn't support accepted industry standards, and I can't use sites that rely on those standards, so nobody should use them!"
If you need to create two totally separate versions, then IMHO, you're doing it wrong.
Spoken like someone who has never had a customer base of normal (non-tech-savvy) individuals. Customers will not conform to your whims. They will go *elsewhere* if they are unhappy. Therefore, if one wishes to be successful, one must conform to *them*.
As for doing things wrong... If you *don't* have to create two seperate versions of a page -- one with and one without JavaScript then your JavaScript code is probably just eye-candy (useful in branding but generally not useful in aiding navigation). Most uses of JavaScript on sites of any significance these days are *not* just eye candy.
One example would be expandable/collapsable tree views, and tabbed sections. Yes, these can be trivially implemented on the server but that creates more load for your server, and involves more page reloads for the end user -- a very frustrating experience. A little ECMAscript and DOM make for a much more usable site. But for those using browsers that choose to not support ECMAscript, the only alternative is to code *both* versions and send the appropriate HTML depending on who is visiting your site.
1. Why lump in old browsers with ones that aren't standards compliant?
Because standards progress. The end result -- whether you use an old browser, or a non-compliant browser -- is that I, as a developer, cannot use those standards.
Historically, Netscape and IE have been the worst for desecrating the HTML standard.
Define "desecrate." If you mean they added stuff to the standard, then sure, they've "desecrated" it. If you mean failing to implement a substantial amount of the relevent defined standards, then Lynx has a far worse record here. Netscape isn't much of a prize in that regard either. Mozilla and IE are the only browsers on the market that correctly implement a very large subset of the most recent DOM, CSS, and ECMAscript standards.
Lynx adheres to the standards strictly enough that it uses special parsing modes to emulate the most common Netscape- and Microsoft-introduced screw ups necessary to make many pages useable.
Yet Lynx chooses to ignore the progress made in standards. XML, CSS, ECMAscript, DOM -- these are all *industry standards* that Lynx chooses not to implement.
2. Some people are stubborn (like me) and refuse to use K00lBrowser6.66, but others don't have a choice. (old hardware, shell account...)
First off, it's not *my* fault that Lynx refuses to implement standards. Nor is it the fault of the majority of users using (nearly) standards-compliant browsers. I refuse to punish the 86% or so of my users that are using standards compliant browsers because of the actions of *your* browser vendor. As part of the development of Opera for Linux, they developed a text based version which had basically all the same support for HTML, CSS, and ECMAscript that the graphical version of Opera does. If you are forced to use a shell account, then you should be demanding that the Lynx crew keep up with standards. (Translation: Complain to the lazy slobs that made your browser.)
As for old hardware -- a $500 eMachines box is *more* than adequate for running a decent browser. That's new. Used computers that are capable of running at least as well can be had for a couple hundred if you shop around.
If you can't afford that, then don't you have more important things to be spending money on than internet access -- such as food perhaps? Or maybe rent?
3. Lynx is up to date - my build here is 2.8.3rel.1 (23 Apr 2000).
You misunderstand me. I did not mean to say it was not being maintained. I said it was not up to date with standards. It has not been updated to support recent standards.
or do us "luddites" not count as real "users"? =)
No, actually, you do not -- from a business standpoint. You are far more technologically savvy than the vast majority of users who visit most web sites. (Slashdot and other niche sites being an exception because of their tech-oriented nature) You are someone who is aware of standards, their significance, the various browsers and such. You choose to ignore progress in standards. From the standpoint of a business you are a poor potential customer choice. You would cost a lot of money to support, and you are less likely to spend money on my product/service than someone who is at least willing to download a *free*, nearly standards compliant web browser.
Not being on the lynx-dev list, I can't say.
It was a rhetorical question. The answer does not matter. The point is that JavaScript (aka ECMAscript) is not supported. This standard, which is important to improving the end-user experience of the web, is not supported. Period.
Maybe because it would add what is perceived as too much bulk to the program
Lynx 2.8.3 in bz2 form is 1.6MB. Opera 4.0 for Linux (tech. preview 4) in bz2 form is 900KB. Remember, Opera supports HTML 4.0, ECMAscript 1.1, CSS 1, and a large subset of CSS 2. To be fair, printing is unimplemented as of yet...
Remember, CPU/memory/ROM constrained devices like cell phones have (limited) ECMAscript support. That's on hardware that's only a step above XT-class machines.
It seems to me that Lynx is already pretty bloated. Perhaps then, this is a valid concern: Perhaps the developers are not capable of producing a standards compliant browser that can run on the limited machines where Lynx is ostensibly preferred?
maybe because no one cares to implement it.
If you choose to use a browser whose developers are too lazy/self-absorbed to care about implementing standards, why should I -- as a developer -- care about you? Why should I care about someone who is going to blame me for someone else's problem (that would be the developers of Lynx, in case it wasn't obvious)?
I know I couldn't be arsed to put full java applet support in
I never said anything about Java. Java is not an industry standard. ECMAscript (aka JavaScript -- no relation WHATSOEVER to Java except that they both have a "C-like" syntax) is an industry standard and is implemented by nearly every browser to a greater or lesser degree.
If you look around, you'll notice that most sites don't use Java for much any more. Why? It's slow, it's unreliable, and it doesn't usually improve the end-user experience substantially more than comparable ECMAscript.
Even WAP-enabled *cell phones* support a subset of ECMAscript.
Say you're putting up a building. Only 0.1% of the users of your building are in wheelchairs, using crutches, or don't fit into the "able-bodied" typecast in some other way. By your argument, it certainly doesn't make economical sense to put in elevators or wheelchair ramps, does it?
The difference here is that there is nothing stopping you from getting a standards compliant browser. A wheelchair-bound individual does not have the option of getting out of the wheelchair.
Are you honestly going to compare you *conscious choice* to use a crippled browser with the hurdles faced by people who *have no choice* about their situation? That is the single most arrogant argument I've heard yet...
Also keep in mind that wheelchair access is required by law. Why? Precisely because it does not make financial sense to provide it so the government intervened. Faced with the expense of providing wheelchair access versus the expense of having your business shut down... Wheelchair access *does* make financial sense.
Your argument about shell accounts misses the point: Browsers do not have to be graphical to support the present standards. Your argument about costly hardware is equally specious: Hardware is cheap enough that you'd almost have to be on food stamps to not be able to afford a computer that can run, say, Opera. Or Internet Explorer (it requires less memory than Netscape). Also, Lynx requires a 386 and several MB of RAM -- if old, cheap hardware is its target, why don't they support DOS on a 286 with 1MB of RAM?
If you don't like it, then either complain to the Lynx developers, or upgrade your browser. Don't whine to me about the situation you have chosen to put yourself in.
-JF
Why do webmasters assume people are using Windows, and the "latest" web browsers? Because they are.
Except for niche sites like Slashdot and other open source/free software community sites the vast majority of users that hit a site will be using IE on Windows (mostly 4.x+), followed by NS on Windows (mostly 4.x+), followed by IE on the Mac (mostly 4.5+), and followed distantly by NS on the Mac. (mostly 4.x+)
My site is usable under Lynx and such -- no JavaScript/Flash/Java/whatever to get in the way of things, and no frames for example.
A quick breakdown of my site reveals 51% using IE, 31% using Netscape, 0.4% using Lynx, and about 0.8% using Opera. 13% is attributable to AvantGo -- but that's almost entirely because I have a personal sub-site which I access from my Pilot. Most of the rest are bots.
A breakdown by OS: 86% use some form of Windows, 9% use Linux, and MacOS is around 0.9%. FreeBSD is just under MacOS.
Broken down by browser version, the number of users accessing my site with IE/NS 4.0 is less than 1% *total*.
The Linux/MacOS numbers are skewed in favor of Linux vs. the "normal" breakdown for big sites because most of the users that come to my site come from Slashdot.
I'll get to the significance shortly.
Companies are rightly concerned with presentation. Presentation does matter to the general public. It is time consuming to make a version of a site that for older browsers when you value detailed control over presentation.
What does poor presentation mean for a company? Poor brand recognition. Poor customer first impression. Lower sales/usage. Lower customer retention.
It is only *economically sensible* to support a browser if the cost of doing so is lower than the increase in sales/banner impressions/whatever gained by doing so.
Supporting Lynx makes no sense for a site that is banner-revenue based: Lynx isn't going to display the banners. So Lynx support only makes sense if you have a pay service. (and, as above, if the income from Lynx users outweighs the cost of making a Lynx-compatible version)
Every major site supports both Netscape and IE. Almost every web application developer grumbles at the difficulty of doing so -- primarily because Netscape (excluding Mozilla) has very poor standards support and a ton of bugs. It is a *major effort* to support a site of any significant complexity on just the two major browsers.
Eventually, if and when Mozilla becomes more widely used then NS 4.x -- and it's still widely used enough that it is statistically significant -- then we'll be at a point where web developers may be able to just make pages to the standards. HTML 4.0, CSS1/2, DOM1, and ECMAscript 1.3...
When I have time to work on my site, I'd rather work on improving the functionality for the 82.8% of my users who use a recent browser than make the existing functionality work better for the 17.2% of my "users" who either refuse to use a decent, up to date, standards compliant browser or are robots. It's just a more effective use of my time and energy.
One more thing: The WAP protocol (which is largely a subset of HTTP, HTML, and other such standards) includes a subset of ECMAscript. That means that text-based cell phones can run some JavaScript code. Why doesn't Lynx even support JavaScript yet?
-JF
Cross platform toolkits sound like a good idea. You can support more platforms with minimal effort. Good thing, right?
Well, the *goal* is a good thing. The methodology is a VERY VERY bad thing. I've only seen one toolkit with the potential to avoid the problems I'm about to describe, and it's not being used to do so.
Every GUI established conventions. These range from the trivial (CTRL-INS is copy, SHIFT-INS is paste) to the non-trivial (buttons on confirmation/warning/etc dialogs are right-aligned) to the very high-level. (actions that can be performed should be described using the present progressive tense)
Simple toolkits can only manage the simplest of these conventions (such as keystroke bindings) and even then can do so only partially... Anything where you have to explicitly state the, say, keyboard binding is beyond the control of the toolkit.
More abstract toolkits such as JFC, and Qt (probably GTK also, although I don't have any real experience with it so I can't be sure...) -- ones that use geometry managers -- can handle some of the higher-level stuff such as button alignments.
A very rich toolkit can provide even higher level stuff -- such as file open/save dialogs -- in a sufficiently generic manner.
But things such as linguistic conventions, i18n support, and broader conventions of UI layout are beyond the control of any toolkit to provide.
The end result is that an application you port winds up not feeling or acting like a native application. This throws users off and makes things harder for them. Unless they happen to be very sohpisticated users familiar with multiple GUIs of course.
The only toolkit I know of which has the *potential* for getting around this is Mozilla's XPToolkit -- and it isn't *just* the toolkit that's needed. Basically, the entire UI is written as a bunch of XML and JavaScript.
You could have platform-specific XML/JavaScript front-ends with the exact same back-end code.
But that's a hybrid solution (it has drawbacks such as having to support a fair amount of platform-specific code), requires careful design of the appliction, and is generally not feasible.
The Mozilla group certainly isn't taking advantage of it -- they just have their AOL/Netscape UI on all platforms and it is up to the user to create/find a platform-specific UI.
-JF
<>
The only perspective that matters is that of whoever holds the purse strings -- the investors.
<<Even many people who start up companies are more interested in making a culture of innovation (no, I do not mean Microsoft), and money is a resource to that end. >>
I worked at such a company. It no longer exists. Mistakes were made -- we let concerns other than the bottom line drive us and we paid for it.
<<Concepts do not exist in a vaccuum, they do not have an independent reality from those who consider them.>>
Yes, so? An employee is essentially a very powerful tool. Just as a compiler provides an important function, so does an employee -- coming up with ideas, concepts, whatever.
I'm not saying that employees are just substitutes for machines -- far from it. Employees are the most important tool a company has. But they are still a tool. They are a means of accomplishing a goal.
Survival -- and that means making more money than you spend -- is the first goal of any long-lived company.
-JF
<>
I'm merely being realistic. Sure, they aren't in danger of running out fo money *right now*, but they will be if they don't make the right business decisions.
How much good does it do any of the employees if the company goes bankrupt? I've actually had that happen to me. It's not fun when you've put your heart and soul into something only to have the CEO tell you "well, the funding fell through and we're out of angel capital..."
I don't neccesarily think this is a particular great way for economics to work, but that's how they do. You waste enough money, you go out of business. If an employee is not raising the bottom line at least as much as they are lowering it, then the employee is a drain on resources.
-JF
You're not reading what the guy said.
They aren't in danger of running out of money, but they are in danger of not becoming profitable in an acceptable time frame.
Just because you have enough money to keep all your employees does not mean it is financially sound to do so.
If they are spending $10,000,000 per *year* just on people -- and the figure is likely to be higher when you consider facilities, managerial/HR overhead, equipment, etc -- try to think of how much they have to make per year to be profitable.
Assuming that they only lost a quarter of their gross income to taxes, and they had 200 employees to start out with (I don't know how many employees they had, I'm just using your example) they'd need over $13M in gross revenues annually just to break even. Again, not counting anything but salaries.
Assuming a couple million for manufacturing/distribution, as much for marketing/sales operations (people wont buy what they don't know about) and say, a couple million for everything else I mentioned above, that's $16M per year in costs or more than $21M in gross revenues...
Now, cut $5M off the top if they cut half their staff... Now they only need about $14.7M in gross revenues... At $50 per sale, that would mean they have to *sell* 293,000 or so copies of TurboLinux EVERY YEAR.
These numbers are wildly off, I'm sure. But the same principle applies regardless of the numbers. Yes, cutting staff reduces their ability to do things like develop cool clustering and such. But if that cool clustering stuff isn't resulting in increased sales that meet or exceed the cost of the overhead of doing the development... Well, you do the math.
You need to remember something: Companies do not exist to give you, the employee a paycheck. Companies exist to make money. Employees are a resource used to that end. It's the simple realities of economics.
-JF
The legalese is almost assuredly unnecesary. It's illegal to break into your box and you don't have to explicilty reserve your rights in that regard.
/etc/issue says. Like disabling external telnet access for one. Set up SSH instead so passwords aren't sent in the clear. Disable unused services. Keep up to date with patches. If you run a web server and do any kind of CGI, be mindful of your code: If you use Perl, then use "-w -T" and "use strict;" all over the place. Again in Perl, use the multi-parameter version of "system" if you must use it at all -- "system('ls', '-l', '/home/foo')" instead of "system('ls -l /home/foo')".
Now, not to advocate "security through obscurity", but posting information about the system that is potentially useful to crackers is a Very Bad Idea. Sure, they may very well be able to get it through other means, but the way you make a system unattractive to hackers is to make it harder and more tedious to break into your system than the next system...
Make them fight for every inch.
But this is all somewhat beside the point. There are far more important, fundamental security measures than what your
-JF