I see this question as a special case of, how should I constrain data supplied by a user?
Other good examples are telephone numbers (not all countries use ten digits, and sometimes you need to add a note like ask for extension 36914 or ask the receptionist to page me, I don't have a direct line), gender (it may surprise you to know that not everyone identifies as male or female, and not everyone is happy with saying which label they want to apply, so make it optional) and even country (is Taiwan a country? It depends who you ask).
You need always to be aware that when a computer model of the external physical world disagrees with the external physical world, it's the model that's inaccurate or wrong, not the external physical world. This sounds pretty obvious, but look at the replies to this article and you'll see suggestions that might make me unable to give me my address.
I've had Web forms ask for my Canadian postal code (by the way, spaces are significant in UK postal codes, and are not in Canadian ones), and then tell me (because they re-used some JacaScript) that a postal code must be five digits. When I tried 00000, the server-side software tried matching that to the billing address of my credit card. As a result I was unable to buy an airline ticket!
In that case I used the 'phone. It took an hour on hold on an 800 number to place the order, because they had to process my credit card by hand, since their computer system didn't allow Canadian customers to fly from US destinations; I wonder how many millions of dollars they had lost before someone took the time to fight this? In the end I got a letter from support saying I should have used the Canadian and not the US Web page, and when I wrote back saying that's what I had done in fact, and please forward this to the programmers, I got a reply saying the bug was fixed.
It's still pretty common to find Web sites whose programmers don't have the concept Some people live outside the US. let alone Some people live in the US but have foreign credit cards, as they are temporary residents.
So when you use the billing address as a "checksum" against the credit card, and find they are different, the right thing to do is to ask the customer for confirmation and then believe the customer.
Keep a record of the information, so that if they complain later you can work out where they asked things to be shipped, and maybe recover. Obviously, your goal is to deliver the package, so you want clear text that is written to be easily understood, not a legal disclaimer in all-caps that's there so you can slither out of the clutches of a disgruntled customer!
The principles are
early quality
It's cheaper and more effective to get good data early on than to correct data later. Using input fields like house number, street name, postal region, county and so forth can help, as can parsing what they type, identifying the various parts, and asking the uer if they are correct.
allow the user to insist
If the user says their postal code is BEWARE OF THE DOG, the Post Office might not agree, but maybe it's the only way they can work out how to get an extra line of text onto the address label. It's probably better to let them do this than to lose them as a customer.
Don't over-model
If you are not going to need the individual address fields later, why are you making the customer type them in a form? Identify the mininum you know you'll need and ask yourself if it's really enough. Large forms aer intimidating, and people may be discouraged or complete them incorrectly because they are overwhelemed. Your database may only have twenty customers today, but when it has half a million addresses, consider the cost of storing an extra dozen fields per customer when you don't need them.
The Real World is Right
I was referring to Don, yes, amongst others. I'm not going to take the time to argue over the DBAzine article, though. There are things I don't like about SQL too, and things I don't like about XML, even though I had a part in XML's creation.
XML Query is not defined on the string/text representation of XML, but over instances of a data model, which can be (for example) created by projections of relational data.
Time will tell how much XQuery will catch on, but I think at this point we're not contributing very much to the original question about Tamino:-)
I think there's a big divide here. Imagine that you had 100,000 documents with multiple schemas, and that the schemas change over time, and that you're not in control of the schemas. Example: Airport Transport Association specification for documentation (I was involved in a $40m document management project in that area once. A single repair manual is tens and sometimes hundreds of thousands of pages, and the average technician needs to consult nine of them for each repair, in a sequence mandated by FAA regulations).
Your use of SQL here will probably (I didn't check the details) work fine, as long as you mine the information correctly out of the XML/SGML documents, and reassemble the document correctly when they need to be edited. I've used such a system in fact. It worked, but it was slow (e.g. 45 minutes to copy a document on a high-end SPARC system at the time) because of all the joins needed to reassemble all the parts of the document.
Saying "just use normalised data" doesn't really cut it -- how do you noralise an HTML paragraph? What do you do when you need to look into phrase level markup ("<step>Take one <part><pn>1984</pn><desc>size twelve wiper bush</desc></part> and...") when you don't control the form of the XML data you receive? Yes, split it up into (step, "Take one",....) etc.list, and store that in the database, but the queries then start to get much more complex than the ones you've outline.
Well, I don't think I'm going to convince you:-) so I'll stop here.
On changing column types, although most RDMS systems let you do it, and in many cases do so without requiring you to delete and recreate the table, a conflicting type can be a problem. But I am not trying to attack relational databases-- I use them too:-) Rather, I'm trying to illustrate some differences in approach.
The people working on XML Query are not ignoring the history of relational databases. Heck, the language is edited by the co0inventor of SQL itself, the the Working Group chairs have been involved with (and edited) the ISO SQL spec, SQL/MM, SQLX, the JDBC and others.
We also have people who have been involved with document management systems, with XML and SGML documents and with markup theory, in some cases for more than 20 years (before SGML was formallypublished).
You're right that if part numbers were fished out of the documents and stored in their own column you could query them quickly, and this is what I meant by suggesting extracting metadata from the documents and storing it in relational databases,for example using the Perl DBI or a Java SAX filter with JDBC.
The neat thing about XML Query is that you don't have to do the extracting in the same way. You can get native RDBMS performace for XPath expressions, and also do a whole bunch of stuff like cross-database joins between relational and non-relational data sources that are generally the province of "middleware" products.
It's not for everyone, but I think it's not entirely useless.
Best,
Liam
And you're right that XML is not a data retrieval technology and SQL not a markup tool.
If I expand the example to find all occurrences of part 1976 (ignoring dates, of course).... it becomes clearer, sorry if I was too terse.
As for data that fits well into the relational model and data that doesn't, consider trying to do precise queries on mixed content data, in which text and markup is interleaved. The most common approaches in the past to this were either to store the entire mixed content (e.g. a paragraph) as a single blob or long text column or to split it up into separate items.
If you store a paragraph in a blob you're stuck, and have to retrieve the whole thing and do the query client-side.
Stored procedures can help, of course, and that's where built-in XPath and XQuery engines start to shine.
If you "shred" the paragraph into separate items... since it's a tuple of unpredictable length (a list) you end up using a column, with lots of yummy joins to put it all back together, but then you can ask questions like, "to which versions of the motherboard do these three words apply, the domestic version or the military ruggedized version?" for example.
If it all sounds like full text stuff, that might be because documents have been sufficiently intractible for relational databases in the past that people have had to rely on doing vague searches based on which words appear in them.
Even though I was the author of a text retrieval package a long time ago, it's clear that these systems don't meet people's real needs, just as CSV files don't remove the need for relational databases.
At most businesses the majority of information that isused on a day-to-day basis is in memos, reports, electronic mail, letters to and from customers, quotes and other documents, as well as product documentation and specifications.
Managing more of this data can be very productive, if done with care.
The XQuery Working Group is indeed still working on text retrieval (and also on update facilities so that you can change the data).
Full text was split off so that the work didn't add any more delays to the main specifications. There are implementations of drafts, but they should be considered very early.
There are open source XML Query implementations too, of course.
There seem to be a lot of confused comments on this, but hey, it's slashdot:-)
If you mostly deal with the sort of data for which relational databases are generally optimised, you'll probably not be very interested in XML solutions, as they are solving problems you don't have.
If you routinely get questions like "how often is part 1976 mentioned in the same repair procedure as part 2001?" or "which of our 150,000 documents have chapters containing five or more subsections any of which does not yet have a summary?" then the XML approach becomes more interesting.
In my book on XML databases (1999 so I don't recommend going out and getting a copy today) I talked about using a hybrid system, with metadata picked out of XML whenever a changed version is stored (e.g. you might use a CVS commit script) and stored in a relational database.
With a relational database you have a lot of flexibility to change your queries but the data representation has to be static. Even changing the type of a column can be difficult in an RDBMS.
Queries may be a little harder with the XML system, but the data storage is more flexible and you have native knowledge of sequence and hierarchy that are traditionally absent using SQL.
More recent versions of SQL have added some XML support, understanding the different sorts of queries that people typically run against such very different sors of data. There has been a lot of research over the past 30 or 40 years (hierarchical databases predate the relational model) on hierarchy, sequence and thesort of irregularity that RDBMS people call semistructured data and the rest of us call XML:-)
XML Query is a query language designed to run over both relational and XML-native data sources (and others, for that matter) and to be optimized very efficiently, so that people like IBM (makers of DB2), Oracle, BEA, Software AG and othes can have efficient implementations. There's also standards work on how to embed XML Query expressions in SQL.
The public XML Query Web page is at www.w3.org/XML/Query and lists quite a large number of implementations. Software AG have participated in the XML Query development.
You might like to look at the XML Query use case document and see how close the examples map to your own situation.
Disclaimer: I work for the W3C, participate in the XML Query WOrking Group, and maintain the XML Query Web page. But it sounded like it's the sort of information you were looking for.
I can't comment on the quality of Tamino, as I have not used it, but I will also note that if you stick to openly-defined standard query languages wherever you can, there's a good chance you could move to a different implementation if you needed to with relatively little cost. This is similar to SQL, of course.
There was lots of hype around XML, but that doesn't mean it's all false, nor that it was all true. XML is a good way to interchange structured, hierarchical imformation, but it probably won't cure acne:-)
Their scans are low resolution -- I don't just mean the thumbnails, but the actual scans they took, which are at up to 400dpi. This may be a good compromise for them, but isn't really archival quality: a lot of detail gets lost from engravings even at 800dpi. These days I generally scan at 1200di before down-sampling for the Web.
You can also see evidence that they laid the books on a flat-bed scanner. Well, I usually do the same, but the best results are obtained using a wooden frame to hold the book open at 90 degrees (so as not to strain the spine, and so the pages lie flat) and using a large format film camera. I imagine the Canon EOS-1 (16MPixels) would be useful, but at 1200dpi an image that's eight inches by ten inches would be over 100 megapixels (109.86 in fact). Texture in engravings is made by lots of very fine lines close together, and when you combine that with ink spread, the high resolution is needed to stop the gaps between the lines from dissolving into a grey mush.
You can see (and download) some of the images I've scanned (mostly public domain for people to use) at my Pictures From Old Books Web site.
I don't have resources to scan hundreds of entire books as they're doing, but on the other hand I don't sell the images either.
It just feels good to share the contents of these old books with people instead of keeping them locked up on the shelves! And that's what I want to see libraries doing, too, so despite any problems I see with their first attempt, I still think it's neat!
A Wiki or a Web site where people can review presentations, link to them, and say how useful they were, might be better for the community.
I can offer a place for such a site (i.e. bandwidth and hosting) if people are interested (although maybe EFF or FSF would be better places? Or maybe there's one already I don't know about?) but I don't have the cycles to set it up and run it.
For what it's worth, W3C is spending a lot of energy on Web services -- we have a whole Activity devoted to it -- and much of the Semantic Web research is funded separately.
No, our funding is not being yanked -- I'd be (mildly) interested in knowing where you read that. W3C is funded partly by Member organizations, partly by grants and partly by host offices (ERCIM in France, Keio in Japan, MIT in the US). It's true that after the "dot com bubble burst" we had fewer Members and hence less income, but that's not the same as having funding "yanked" away from us.
As an employee of W3C I'll note that there's actually not that much beaurocracy internally. It's true that we have tried to raise the bar on specs that are produced, mainly by putting more emphasis on public involvement and on interoperable implementations.
As for "bullshit" -- the alternative to the semantic Web is to be doomed to a future of screen-scraping. In other words, the goal of that Activity is to find useful ways for people to share machine-readable information. If you feel there are better ways than RDF, and can demonstrate why, I'd encourage you to get involved.
You should take what I say with a grain of salt since I work for W3C -- I'm the XML Activity Lead and not directly part of either the Web Services or the Semantic Web Activities.
Thanks:-) lq-text is rather old now, so maybe a beagle-style rewrite is a better approach. I think probably it was about two or three person-years of effort back then, though, much of it in profiling and performance tuning, plus perhaps a year or so of maintenance. I don't have much time to write software these days:-( but would be happy to see others do so.
There are two main reasons to use a search engine rather than grep or other similar brute-force tools, even under the Unix operating system.
it's often orders of magnitude faster
it finds things that tools like grep can't find.
It's faster because searching an index generally means reading fewer disk blocks than scanning the data.
You could think of a text retrieval system as a cache that's pre-loade with every possible search. Of course, the biggest problem then becomes cache management. One often forgotten issue is security: can you find out what words are in files belonging to other users? This is sometimes called the "dead sea scrolls attack" because the scholars working on the DSSs refused to publish the texts, but did publish a concordance, and from this someone else deduced the actual text.
Security issues apart, try to search the works of Shakespeare for to be or not to be and you'll find no exact matches. First, there's a comma in the original (at least in the most common editions). Second, the first word should be capitalised. And in some electronic editions there may be a newline in the phrase. Any of these changes will defeat grep, although you can use case insensitive matching and change every space to a [^a-zA-Z0-9]+ to improve things.
A good modern text retrieval system will also support query expansion - e.g. sugegsting alternatives for misspelt words, and in some cases using a thesaurus to find words with similar meanings. Google also does query narrowing whereby possible meanings of words are eliminated based on other words in the query. For instance, if you look for Mass Ave you're unlikely to be interested in the weight of the Virgin Mary, and quite likely to be looking for Massecheussets Avenue in Boston. Many other features, such as preferring matches with the words in the right order but not discounting matches with a transposition, and of course the order in which the results are presented, all add up to whether a text retrieval system is useful or not.
Perhaps I should be honest here and admit that my own system didn't support a thesaurus, mostly because in 1989 it was hard to get a redistributable machine-readable one in a useful format!
Another reason to want a text retrieval system is that tools like grep don't handle non-textual file formats such as PDF, Microsoft Word, or even tar or zip archives containing text files. Grep can also give false matches by accidentally searching image files and program binaries.
I have no idea how good Yahoo's software will be, if and when it's released, nor how the current offerings under open source or Free desktops such as Gnome (Beagle) and KDE compare right now. But let's not dismiss it just because a less useful "solution" exists elsewhere:-)
Don't confuse art with graphic design which uses artistic techniques to solve problems.
If you need to make icons, yes, you need some creativity, but you also need to understand some basic things about icons: the way people recognise shapes means you shouldn't make them all square, for example.
If you are trying to express your inner angst, or to speak about the indescribable horrors being wrought upon poor innocent $VICTIMS in $COUNTRY, or you wish to share the calm serenity of the spirit (I'm not actually mocking), and you do so in pictures, in words, in sculpture, in music, you're making art.
If you're designing a dialogue box, a window, a page of text, you're using techniques like composition, alignment, framing, proximity, similarity, contrast and you're doing graphic design.
Of course, an accomplished artist also uses these techniques, so graphic design is really just a subcategory of fine art, but with a stronger focus on purpose - often a purpose imposed from outside.
There are lots of good books on technique, and if you use them you can produce solid, workable designs, just as studying how to write will help you to produce workable essays or documentation without making you into a poet.
I'm not going to try and reply in detail, but since I participate in the W3C XML Query Working Group and am also the w3C XML Activity Lead, a few comments may be useful.
The article seems to says "I don't like SQL and I don't like XML and I think XML Query is about mergin them although I don't understand it very well, so the people working on XML Query must be stupid, and in any case it's easier to attack people than understand a specification".
Perhaps that's unfair, but it's clear to me that the writer is a little fuzzy on the design goals of XML and also on the focus of SQL development over the past 10 or 15 years.
In both cases the story is about interoperability.
If you look at the XML Query Home Page you'll see approximately two dozen implementations of the XML Query draft, including a number of open source ones. If you look at the public mailing list for comments, you'll see we received over 1100 detailed technical comments at the last public review. So there's a lot of interest in this work.
Why is that? One reason is that, like Web services and SOAP, XML Query is able to replace a lot of proprietary and hard-to-maitain middleware. Another reason is that for the first time we'll have a standard way to search over multiple kinds of data source.
Don is the primary editor of the XQuery language, but the technical decisions reflected in the specification are a result of collaboration, and are agreed on by aconsensus process by a much larger number of particpants. The goal is to make a language that people agree to implement and to use. With support announced by Microsoft, Oracle, IBM, BEA and others (see Web page mentioned above) and judging by the public interest, I think it's fair to say that's going to happen.
It's pretty rare to see a large complex system that everyone is happy with. It's actually pretty rare to see a small system that everyone is happy with. There are people who are unhappy with some features in the Unix cat program, but it's better to have cat in every Unix system than to have millions of shell scripts break on systems where it's missing! The trick, then, is often to include features that will lead to massively wider adoption, even if some people would rather be without them.
Then we have (as part of W3C Process) a public call for implementations so that we can test to see how confident we are that all the major features can be implemented compatibly (i.e. interoperably) in multiple independent implementations.
Features that were not implemented get removed before the specifications are final.
Is XML Query a waste of time? Is XML evil? Is SQL evil? A lot of people think otherwise, and some of them are pretty smart, so if you are concerned, take the time to read the specs and decide for yourself.:-)
I came to Canada 15 years ago (from the UK) as a computer consultant, loved it, and stayed here in Toronto ever since, except for a few months working in the Boston area of the US. And for what it's worth, I'm married to an American ex-attorney:-)
An unpleasant job is unpleasant anywhere. I can't comment on the insurance industry, I don't know about it.
When you're comparing countries, remember that Canada is geographically larger than the US, and has a lot of variation, as of course does the US. A factory worker assembling cars in suburban Detroit might be amazed that the houses in Ontario are not all the same shape:-) and someone from San Francisco might miss the hills. A visitor from the South gaped in awe at the mixed-race couples everywhere here in Toronto.
The highest tax rate is indeed 51% but get an accountant: you'll find there are more deductibles that reduce your taxes here, and a rate of around 30% is more common, assuming you are earning more than Cad$60,000/year.
Yes, you'll quite likely be paid less here. But the cost of living is lower. Make sure you get at least the same dollar amount and it shouldn't be too bad.
The healthcare is in fact better than someone commented: my partner has had a lot of health problems, and for some things Canada is much better than the US, for some it's not. In some cases, the Canadian health programme will send you to the US for treatment and cover the cost too, although it's rare. You are much less likely to have doctors trying to sell you on expensive drugs or treatments here, and more likely to find doctors who want to help you.
In much of Canada, at least in the more rural parts, there's much better public transport than you might be used to, depending on which part of the US you're from. It's a symptom of a greater emphasis on community, on the need for everyone to live together and get along, and to respect each other's differences, celebrating diversity. This comes at a cost of a lower emphasis on the individual, especially on the rights of the individual where they might adversely affect the community. Hate speech, for example, is a crime.
It took my husband (yes, we are a gay couple, and yes, we have same-sex marriage here) about 18 months before he stopped saying "Canada is so far behind the US" and started to realise that in fact we're going in a different direction. After a few more years he came to appreciate that direction, and decided to immigrate. I've heard similar stories from others: it can take two or three years to get used to a different way of thinking and to stop judging what you see based on experiences gained in another country.
Canada is far from perfect, but we don't have George Bush, and many of the Americans who move here are dissatisfied with the US in some way, and often relatively left-wing. But you should come and see for yourself.
The Immigration Canada Web site is useful - http://www.cic.gc.ca/ - and will help you get a visa. You can get a NAFTA work permit I think, but you'll need a certified job offer to do that. if you decide to immigrate and then find a job, there's about a year's waiting list and a non-refundable fee.
You could also start reading online papers such as the Glbe and Mail, and depending on where you are planning to go, daily papers like the Globe and Mail.
Oh, and on climate - yes, it gets as cold as Minnisota in the winter at times:-) and today it's over 80 degrees with a dry warm breeze. It depends where you live; Toronto is pretty far south, further than most people realise, and we get weather not that much different from new York City. But you could live within the Arctic Circle if you really wanted to:-)
I hope this helps.
Oh, one more thing (I know this is already long).. I travel a lot... and always notice when I come home how different the people are in the service industry here. Go and get a meal at a food court in Det
I'm tempted to offer to host them, if he needs somewhere, as part of the moral obligation we all have to document the effects of our actions, including war.
I don't have resources to scan large numbers of slides, unfortunately. But I can provide Web space.
On the whole I'd say Marc Rochkind is actually a better writer - it's a lot harder to write a thin book on a topic and still have it be this useful.
If you're working in C (or C++ I suppose, Oh you youngsters!) on and form of Unix, you probably already have the first edition, or at least have read it. If not, go and get it (or this second edition). Along with The Unix Programming Environment, it's one of the classic texts that's not too large to read, but too useful to skip.
I've had an Acer laptop for 3 years, just bought one for my partner, and would not hesitate in buying more. I had a free 2-year warranty with mine, and that involved a guarantee that they'd fix it or replace it, within 2 business days. I had two problems (both related) and they made good on the promise.
You can get a 2-hour support (or is it 4 hour??) in the Greater Toronto Area.
Several Acer dealers have warned me that the very low end Acer laptops have a lot of problems. But they all also say that the higher end ones are first rate.
Frankly, I expect (based on published statistics as well as anecdotal evidence) that laptops are likely to go wrong in the first 2 years, especially if, like me, you travel a lot. So the warranty is really important to me.
Ask around in your area. Check the warranty, and ask the dealer before you buy. But for me, the Acer laptop I got (a Travelmate 602TER, 650MHz, 384M RAM (upgraded from 128), CD-RW drive, Mandrake Linux + Win98) was pretty good value at the time, and everything I needed worked in Linux, too.
I don't think I'd go so far as to say that Mandrake Linux is "built off" Red Hat Linux -- it was originally Red Hat with both Gnome and KDE and more up-to-date, but then,I suppose you could say Red Hat was built off slackware:-)
For my part, I use Mandrake Linux for several reasons: [1] I evangelize a lot, and want to run the same software that I am telling others to try. [2] I have very little time available for systems administration. I've been using Unix since 1981 (yes, over 22 years now) but that doesn't mean I *want* to edit config files inlots of different formats. [3] I want a distribution that attracts both experienced developers and beginners, and keeps them - that means it has to have a good and very welcoming community, free of "learn this complex stuff because then you can be elite" for example [4] I need automatic dependency tracking, and I want PGP-signed packages. If I say, urpmi foo and foo depends on bar, then both had better be donwloaded, checked and installed. Whilst rpmfind is a great resource, I'm pleased to say I've used it maybe twice in the past 18 months or so, and one of those occasions was to help someone running another Linux distribution.
There's a lot of strength in diversity, and I'm not going to say everyone should use Mandrake Linux by any means, but let's try and choose based on understanding.
Let's also hope Fedora is a success and helps at building up community - it's an area where Debian and Mandrake have done better than RH in the past, and I know that the people at RH are aware of that.
As an author I've had between 10% and 17% of publisher net sales as a royalty. That means that if the *publisher* gets $20 from the wholesaler, I might get $2 or $3 in royalties. Author royalties may be lower for foreign sales, depending ont he publisher and contract.
I got an advance - a cheque paid when I started writing the book, and another one when I submitted the final book - that was a total of between $10K and $16K (US$), again depending on the publisher.
Royalties count against the advance. In other words, if I got $10,000 up front, the book has to earn $10,000 in royalties before I start seeing any extra payments.
As a result, once the book is published, it's very unlikely the pubilsher will need to pay the author any more money.
The only time the author is really affected a lot by UK/US price differences is likely to be if the book did well enough to generate royalty cheques, and the wholesaler in the UK is paying the publisher much less than the one in the US.
Of course, if you buy cheap copies of books in India, chances are the author gets no royalties at all, with the possible end result that you don't get new textbooks from experienced writers, as they've gone off and got other jobs.
For me, the royalty advance was useful when I really needed the money, but the 6 months or more of work afterwards used up far more than the advance. I didn't write tet books to get rich, though, but mainly to help people, and also of course to boost my reputation as a consultant.
Note that for embedded systems the main interest is how long it takes for the kernel to load, not how long it is before a multi-user server or workstation has a prompt that says "login" on a pretty X display.
So, this is a good improvement it seems, but shaves away 4.5 seconds or so out of maybe 30 sconds or over a minute for many people. Combined with the parallel init scripts work mentioned a few days ago,though, I'm guessing that Linux systems will be booting a lot faster with the major releases in 6 months to a year.
If you get dependency problems when running Mandrake Linux, you're probably not doing it right:-)
Seriously, the urpmi command will download an RPM for you, together with everything it needs that you don't already have, and install everything. Automatically.
See plf and the main urpmi web page for more info; Mandrake comes with urpmi, and it's also used by the GUI package manager (rpmdrake).
The trick to keeping Mandrake Linux running heppily is to avoid rpmfind. Always start by looking for packages in Mandrake's main and contrib (you can add them as sources for urpmi, and then it's automatic, just, urpmi package).
If you can't find a package, try searching with rpmdrake (you can search based on filenames too), or use urpmq -y some-substring such as, urpmq -y apache to see all packages that provide things containing that string.
if you use urpmi for package management, you should find that dependency and version problems becomre very rare. I won't say they'll go away (any more than they go away entirely with apt-get) but they will become very rare.
If you do get problems with urpmi, look in/var/cache/urpmi/rpms for the downloaded RPM files.
SVG itself is a W3C Recommendation, not an IETF RFC.
You may be surprised, if you look around... SVG is already pretty widely used. Examples: it's used for theming in the metacity window manager and in nautilus; for support in graphics editors, if dia and sodipodi don't ring a bell maybe you've come across Adobe Illustrator, or Microsoft Office 11's Visio.
I do agree that Mozilla has a long way to go. But it's worth it. SVG can be manipulated with XSLT and XML Query, can be generated with open source tools, stored in XML databases, is often massively smaller than Flash files, and can be made accessible. Depending on how much you script, it could also be indexed by google and other search engines.
You can see the W3C SVG page for more information.
Disclaimer: I work for the W3C, although I am not directly involved in SVG.
Slashdot Mirror
I see this question as a special case of, how should I constrain data supplied by a user?
Other good examples are telephone numbers (not all countries use ten digits, and sometimes you need to add a note like ask for extension 36914 or ask the receptionist to page me, I don't have a direct line), gender (it may surprise you to know that not everyone identifies as male or female, and not everyone is happy with saying which label they want to apply, so make it optional) and even country (is Taiwan a country? It depends who you ask).
You need always to be aware that when a computer model of the external physical world disagrees with the external physical world, it's the model that's inaccurate or wrong, not the external physical world. This sounds pretty obvious, but look at the replies to this article and you'll see suggestions that might make me unable to give me my address.
I've had Web forms ask for my Canadian postal code (by the way, spaces are significant in UK postal codes, and are not in Canadian ones), and then tell me (because they re-used some JacaScript) that a postal code must be five digits. When I tried 00000, the server-side software tried matching that to the billing address of my credit card. As a result I was unable to buy an airline ticket!
In that case I used the 'phone. It took an hour on hold on an 800 number to place the order, because they had to process my credit card by hand, since their computer system didn't allow Canadian customers to fly from US destinations; I wonder how many millions of dollars they had lost before someone took the time to fight this? In the end I got a letter from support saying I should have used the Canadian and not the US Web page, and when I wrote back saying that's what I had done in fact, and please forward this to the programmers, I got a reply saying the bug was fixed.
It's still pretty common to find Web sites whose programmers don't have the concept Some people live outside the US. let alone Some people live in the US but have foreign credit cards, as they are temporary residents.
So when you use the billing address as a "checksum" against the credit card, and find they are different, the right thing to do is to ask the customer for confirmation and then believe the customer.
Keep a record of the information, so that if they complain later you can work out where they asked things to be shipped, and maybe recover. Obviously, your goal is to deliver the package, so you want clear text that is written to be easily understood, not a legal disclaimer in all-caps that's there so you can slither out of the clutches of a disgruntled customer!
The principles are early quality It's cheaper and more effective to get good data early on than to correct data later. Using input fields like house number, street name, postal region, county and so forth can help, as can parsing what they type, identifying the various parts, and asking the uer if they are correct. allow the user to insist If the user says their postal code is BEWARE OF THE DOG, the Post Office might not agree, but maybe it's the only way they can work out how to get an extra line of text onto the address label. It's probably better to let them do this than to lose them as a customer. Don't over-model If you are not going to need the individual address fields later, why are you making the customer type them in a form? Identify the mininum you know you'll need and ask yourself if it's really enough. Large forms aer intimidating, and people may be discouraged or complete them incorrectly because they are overwhelemed. Your database may only have twenty customers today, but when it has half a million addresses, consider the cost of storing an extra dozen fields per customer when you don't need them. The Real World is Right
I was referring to Don, yes, amongst others. I'm not going to take the time to argue over the DBAzine article, though. There are things I don't like about SQL too, and things I don't like about XML, even though I had a part in XML's creation.
:-)
XML Query is not defined on the string/text representation of XML, but over instances of a data model, which can be (for example) created by projections of relational data.
Time will tell how much XQuery will catch on, but I think at this point we're not contributing very much to the original question about Tamino
Best,
Liam
I think there's a big divide here. Imagine that you had 100,000 documents with multiple schemas, and that the schemas change over time, and that you're not in control of the schemas. Example: Airport Transport Association specification for documentation (I was involved in a $40m document management project in that area once. A single repair manual is tens and sometimes hundreds of thousands of pages, and the average technician needs to consult nine of them for each repair, in a sequence mandated by FAA regulations).
....) etc.list, and store that in the database, but the queries then start to get much more complex than the ones you've outline.
:-) so I'll stop here.
Your use of SQL here will probably (I didn't check the details) work fine, as long as you mine the information correctly out of the XML/SGML documents, and reassemble the document correctly when they need to be edited. I've used such a system in fact. It worked, but it was slow (e.g. 45 minutes to copy a document on a high-end SPARC system at the time) because of all the joins needed to reassemble all the parts of the document.
Saying "just use normalised data" doesn't really cut it -- how do you noralise an HTML paragraph? What do you do when you need to look into phrase level markup ("<step>Take one <part><pn>1984</pn><desc>size twelve wiper bush</desc></part> and...") when you don't control the form of the XML data you receive? Yes, split it up into (step, "Take one",
Well, I don't think I'm going to convince you
On changing column types, although most RDMS systems let you do it, and in many cases do so without requiring you to delete and recreate the table, a conflicting type can be a problem. But I am not trying to attack relational databases-- I use them too :-) Rather, I'm trying to illustrate some differences in approach.
The people working on XML Query are not ignoring the history of relational databases. Heck, the language is edited by the co0inventor of SQL itself, the the Working Group chairs have been involved with (and edited) the ISO SQL spec, SQL/MM, SQLX, the JDBC and others.
We also have people who have been involved with document management systems, with XML and SGML documents and with markup theory, in some cases for more than 20 years (before SGML was formallypublished).
You're right that if part numbers were fished out of the documents and stored in their own column you could query them quickly, and this is what I meant by suggesting extracting metadata from the documents and storing it in relational databases,for example using the Perl DBI or a Java SAX filter with JDBC.
The neat thing about XML Query is that you don't have to do the extracting in the same way. You can get native RDBMS performace for XPath expressions, and also do a whole bunch of stuff like cross-database joins between relational and non-relational data sources that are generally the province of "middleware" products.
It's not for everyone, but I think it's not entirely useless.
Best,
Liam
And you're right that XML is not a data retrieval technology and SQL not a markup tool.
If I expand the example to find all occurrences of part 1976 (ignoring dates, of course).... it becomes clearer, sorry if I was too terse.
As for data that fits well into the relational model and data that doesn't, consider trying to do precise queries on mixed content data, in which text and markup is interleaved. The most common approaches in the past to this were either to store the entire mixed content (e.g. a paragraph) as a single blob or long text column or to split it up into separate items.
If you store a paragraph in a blob you're stuck, and have to retrieve the whole thing and do the query client-side.
Stored procedures can help, of course, and that's where built-in XPath and XQuery engines start to shine.
If you "shred" the paragraph into separate items... since it's a tuple of unpredictable length (a list) you end up using a column, with lots of yummy joins to put it all back together, but then you can ask questions like, "to which versions of the motherboard do these three words apply, the domestic version or the military ruggedized version?" for example.
If it all sounds like full text stuff, that might be because documents have been sufficiently intractible for relational databases in the past that people have had to rely on doing vague searches based on which words appear in them.
Even though I was the author of a text retrieval package a long time ago, it's clear that these systems don't meet people's real needs, just as CSV files don't remove the need for relational databases.
At most businesses the majority of information that isused on a day-to-day basis is in memos, reports, electronic mail, letters to and from customers, quotes and other documents, as well as product documentation and specifications.
Managing more of this data can be very productive, if done with care.
Best,
Liam
The XQuery Working Group is indeed still working on text retrieval (and also on update facilities so that you can change the data).
Full text was split off so that the work didn't add any more delays to the main specifications. There are implementations of drafts, but they should be considered very early.
There are open source XML Query implementations too, of course.
Liam
There seem to be a lot of confused comments on this, but hey, it's slashdot :-)
:-)
:-)
If you mostly deal with the sort of data for which relational databases are generally optimised, you'll probably not be very interested in XML solutions, as they are solving problems you don't have.
If you routinely get questions like "how often is part 1976 mentioned in the same repair procedure as part 2001?" or "which of our 150,000 documents have chapters containing five or more subsections any of which does not yet have a summary?" then the XML approach becomes more interesting.
In my book on XML databases (1999 so I don't recommend going out and getting a copy today) I talked about using a hybrid system, with metadata picked out of XML whenever a changed version is stored (e.g. you might use a CVS commit script) and stored in a relational database.
With a relational database you have a lot of flexibility to change your queries but the data representation has to be static. Even changing the type of a column can be difficult in an RDBMS.
Queries may be a little harder with the XML system, but the data storage is more flexible and you have native knowledge of sequence and hierarchy that are traditionally absent using SQL.
More recent versions of SQL have added some XML support, understanding the different sorts of queries that people typically run against such very different sors of data. There has been a lot of research over the past 30 or 40 years (hierarchical databases predate the relational model) on hierarchy, sequence and thesort of irregularity that RDBMS people call semistructured data and the rest of us call XML
XML Query is a query language designed to run over both relational and XML-native data sources (and others, for that matter) and to be optimized very efficiently, so that people like IBM (makers of DB2), Oracle, BEA, Software AG and othes can have efficient implementations. There's also standards work on how to embed XML Query expressions in SQL.
The public XML Query Web page is at www.w3.org/XML/Query and lists quite a large number of implementations. Software AG have participated in the XML Query development.
You might like to look at the XML Query use case document and see how close the examples map to your own situation.
Disclaimer: I work for the W3C, participate in the XML Query WOrking Group, and maintain the XML Query Web page. But it sounded like it's the sort of information you were looking for.
I can't comment on the quality of Tamino, as I have not used it, but I will also note that if you stick to openly-defined standard query languages wherever you can, there's a good chance you could move to a different implementation if you needed to with relatively little cost. This is similar to SQL, of course.
There was lots of hype around XML, but that doesn't mean it's all false, nor that it was all true. XML is a good way to interchange structured, hierarchical imformation, but it probably won't cure acne
Liam
[slashdot::Ankh -- Liam Quin, W3CXML Activity Lead]
It's good to ask questions.
I wonder if Republicans are more likely to come from wealthy backgrounds, and more likely to have private planes than Democrats?
Liam
I'm glad to see a library doing this.
Their scans are low resolution -- I don't just mean the thumbnails, but the actual scans they took, which are at up to 400dpi. This may be a good compromise for them, but isn't really archival quality: a lot of detail gets lost from engravings even at 800dpi. These days I generally scan at 1200di before down-sampling for the Web.
You can also see evidence that they laid the books on a flat-bed scanner. Well, I usually do the same, but the best results are obtained using a wooden frame to hold the book open at 90 degrees (so as not to strain the spine, and so the pages lie flat) and using a large format film camera. I imagine the Canon EOS-1 (16MPixels) would be useful, but at 1200dpi an image that's eight inches by ten inches would be over 100 megapixels (109.86 in fact). Texture in engravings is made by lots of very fine lines close together, and when you combine that with ink spread, the high resolution is needed to stop the gaps between the lines from dissolving into a grey mush.
You can see (and download) some of the images I've scanned (mostly public domain for people to use) at my Pictures From Old Books Web site.
I don't have resources to scan hundreds of entire books as they're doing, but on the other hand I don't sell the images either.
It just feels good to share the contents of these old books with people instead of keeping them locked up on the shelves! And that's what I want to see libraries doing, too, so despite any problems I see with their first attempt, I still think it's neat!
Liam
A Wiki or a Web site where people can review presentations, link to them, and say how useful they were, might be better for the community.
I can offer a place for such a site (i.e. bandwidth and hosting) if people are interested (although maybe EFF or FSF would be better places? Or maybe there's one already I don't know about?) but I don't have the cycles to set it up and run it.
Liam
For what it's worth, W3C is spending a lot of energy on Web services -- we have a whole Activity devoted to it -- and much of the Semantic Web research is funded separately.
No, our funding is not being yanked -- I'd be (mildly) interested in knowing where you read that. W3C is funded partly by Member organizations, partly by grants and partly by host offices (ERCIM in France, Keio in Japan, MIT in the US). It's true that after the "dot com bubble burst" we had fewer Members and hence less income, but that's not the same as having funding "yanked" away from us.
As an employee of W3C I'll note that there's actually not that much beaurocracy internally. It's true that we have tried to raise the bar on specs that are produced, mainly by putting more emphasis on public involvement and on interoperable implementations.
As for "bullshit" -- the alternative to the semantic Web is to be doomed to a future of screen-scraping. In other words, the goal of that Activity is to find useful ways for people to share machine-readable information. If you feel there are better ways than RDF, and can demonstrate why, I'd encourage you to get involved.
You should take what I say with a grain of salt since I work for W3C -- I'm the XML Activity Lead and not directly part of either the Web Services or the Semantic Web Activities.
Liam
Thanks :-) lq-text is rather old now, so maybe a beagle-style rewrite is a better approach. I think probably it was about two or three person-years of effort back then, though, much of it in profiling and performance tuning, plus perhaps a year or so of maintenance. I don't have much time to write software these days :-( but would be happy to see others do so.
There are two main reasons to use a search engine rather than grep or other similar brute-force tools, even under the Unix operating system.
It's faster because searching an index generally means reading fewer disk blocks than scanning the data.
You could think of a text retrieval system as a cache that's pre-loade with every possible search. Of course, the biggest problem then becomes cache management. One often forgotten issue is security: can you find out what words are in files belonging to other users? This is sometimes called the "dead sea scrolls attack" because the scholars working on the DSSs refused to publish the texts, but did publish a concordance, and from this someone else deduced the actual text.
Security issues apart, try to search the works of Shakespeare for to be or not to be and you'll find no exact matches. First, there's a comma in the original (at least in the most common editions). Second, the first word should be capitalised. And in some electronic editions there may be a newline in the phrase. Any of these changes will defeat grep, although you can use case insensitive matching and change every space to a [^a-zA-Z0-9]+ to improve things.
A good modern text retrieval system will also support query expansion - e.g. sugegsting alternatives for misspelt words, and in some cases using a thesaurus to find words with similar meanings. Google also does query narrowing whereby possible meanings of words are eliminated based on other words in the query. For instance, if you look for Mass Ave you're unlikely to be interested in the weight of the Virgin Mary, and quite likely to be looking for Massecheussets Avenue in Boston. Many other features, such as preferring matches with the words in the right order but not discounting matches with a transposition, and of course the order in which the results are presented, all add up to whether a text retrieval system is useful or not.
Perhaps I should be honest here and admit that my own system didn't support a thesaurus, mostly because in 1989 it was hard to get a redistributable machine-readable one in a useful format!
Another reason to want a text retrieval system is that tools like grep don't handle non-textual file formats such as PDF, Microsoft Word, or even tar or zip archives containing text files. Grep can also give false matches by accidentally searching image files and program binaries.
I have no idea how good Yahoo's software will be, if and when it's released, nor how the current offerings under open source or Free desktops such as Gnome (Beagle) and KDE compare right now. But let's not dismiss it just because a less useful "solution" exists elsewhere
Liam
Don't confuse art with graphic design which uses artistic techniques to solve problems.
If you need to make icons, yes, you need some creativity, but you also need to understand some basic things about icons: the way people recognise shapes means you shouldn't make them all square, for example.
If you are trying to express your inner angst, or to speak about the indescribable horrors being wrought upon poor innocent $VICTIMS in $COUNTRY, or you wish to share the calm serenity of the spirit (I'm not actually mocking), and you do so in pictures, in words, in sculpture, in music, you're making art.
If you're designing a dialogue box, a window, a page of text, you're using techniques like composition, alignment, framing, proximity, similarity, contrast and you're doing graphic design.
Of course, an accomplished artist also uses these techniques, so graphic design is really just a subcategory of fine art, but with a stronger focus on purpose - often a purpose imposed from outside.
There are lots of good books on technique, and if you use them you can produce solid, workable designs, just as studying how to write will help you to produce workable essays or documentation without making you into a poet.
I have a short reading list (uses Amazon referrer links) that may help.
The slashdot pragraph referres to him as Lian Kemp, but it's actually Liam Kemp.
As someone whose name is Liam, I find this is a frequent error in Norh America.
Liam
I'm not going to try and reply in detail, but since I participate in the W3C XML Query Working Group and am also the w3C XML Activity Lead, a few comments may be useful.
:-)
The article seems to says "I don't like SQL and I don't like XML and I think XML Query is about mergin them although I don't understand it very well, so the people working on XML Query must be stupid, and in any case it's easier to attack people than understand a specification".
Perhaps that's unfair, but it's clear to me that the writer is a little fuzzy on the design goals of XML and also on the focus of SQL development over the past 10 or 15 years.
In both cases the story is about interoperability.
If you look at the XML Query Home Page you'll see approximately two dozen implementations of the XML Query draft, including a number of open source ones. If you look at the public mailing list for comments, you'll see we received over 1100 detailed technical comments at the last public review. So there's a lot of interest in this work.
Why is that? One reason is that, like Web services and SOAP, XML Query is able to replace a lot of proprietary and hard-to-maitain middleware. Another reason is that for the first time we'll have a standard way to search over multiple kinds of data source.
Don is the primary editor of the XQuery language, but the technical decisions reflected in the specification are a result of collaboration, and are agreed on by aconsensus process by a much larger number of particpants. The goal is to make a language that people agree to implement and to use. With support announced by Microsoft, Oracle, IBM, BEA and others (see Web page mentioned above) and judging by the public interest, I think it's fair to say that's going to happen.
It's pretty rare to see a large complex system that everyone is happy with. It's actually pretty rare to see a small system that everyone is happy with. There are people who are unhappy with some features in the Unix cat program, but it's better to have cat in every Unix system than to have millions of shell scripts break on systems where it's missing! The trick, then, is often to include features that will lead to massively wider adoption, even if some people would rather be without them.
Then we have (as part of W3C Process) a public call for implementations so that we can test to see how confident we are that all the major features can be implemented compatibly (i.e. interoperably) in multiple independent implementations.
Features that were not implemented get removed before the specifications are final.
Is XML Query a waste of time? Is XML evil? Is SQL evil? A lot of people think otherwise, and some of them are pretty smart, so if you are concerned, take the time to read the specs and decide for yourself.
I came to Canada 15 years ago (from the UK) as a computer consultant, loved it, and stayed here in Toronto ever since, except for a few months working in the Boston area of the US. And for what it's worth, I'm married to an American ex-attorney :-)
:-) and someone from San Francisco might miss the hills. A visitor from the South gaped in awe at the mixed-race couples everywhere here in Toronto.
:-) and today it's over 80 degrees with a dry warm breeze. It depends where you live; Toronto is pretty far south, further than most people realise, and we get weather not that much different from new York City. But you could live within the Arctic Circle if you really wanted to :-)
An unpleasant job is unpleasant anywhere. I can't comment on the insurance industry, I don't know about it.
When you're comparing countries, remember that Canada is geographically larger than the US, and has a lot of variation, as of course does the US. A factory worker assembling cars in suburban Detroit might be amazed that the houses in Ontario are not all the same shape
The highest tax rate is indeed 51% but get an accountant: you'll find there are more deductibles that reduce your taxes here, and a rate of around 30% is more common, assuming you are earning more than Cad$60,000/year.
Yes, you'll quite likely be paid less here. But the cost of living is lower. Make sure you get at least the same dollar amount and it shouldn't be too bad.
The healthcare is in fact better than someone commented: my partner has had a lot of health problems, and for some things Canada is much better than the US, for some it's not. In some cases, the Canadian health programme will send you to the US for treatment and cover the cost too, although it's rare. You are much less likely to have doctors trying to sell you on expensive drugs or treatments here, and more likely to find doctors who want to help you.
In much of Canada, at least in the more rural parts, there's much better public transport than you might be used to, depending on which part of the US you're from. It's a symptom of a greater emphasis on community, on the need for everyone to live together and get along, and to respect each other's differences, celebrating diversity. This comes at a cost of a lower emphasis on the individual, especially on the rights of the individual where they might adversely affect the community. Hate speech, for example, is a crime.
It took my husband (yes, we are a gay couple, and yes, we have same-sex marriage here) about 18 months before he stopped saying "Canada is so far behind the US" and started to realise that in fact we're going in a different direction. After a few more years he came to appreciate that direction, and decided to immigrate. I've heard similar stories from others: it can take two or three years to get used to a different way of thinking and to stop judging what you see based on experiences gained in another country.
Canada is far from perfect, but we don't have George Bush, and many of the Americans who move here are dissatisfied with the US in some way, and often relatively left-wing. But you should come and see for yourself.
The Immigration Canada Web site is useful - http://www.cic.gc.ca/ - and will help you get a visa. You can get a NAFTA work permit I think, but you'll need a certified job offer to do that. if you decide to immigrate and then find a job, there's about a year's waiting list and a non-refundable fee.
You could also start reading online papers such as the Glbe and Mail, and depending on where you are planning to go, daily papers like the Globe and Mail.
Oh, and on climate - yes, it gets as cold as Minnisota in the winter at times
I hope this helps.
Oh, one more thing (I know this is already long).. I travel a lot... and always notice when I come home how different the people are in the service industry here. Go and get a meal at a food court in Det
I'm tempted to offer to host them, if he needs somewhere, as part of the moral obligation we all have to document the effects of our actions, including war.
I don't have resources to scan large numbers of slides, unfortunately. But I can provide Web space.
Liam
On the whole I'd say Marc Rochkind is actually a better writer - it's a lot harder to write a thin book on a topic and still have it be this useful.
If you're working in C (or C++ I suppose, Oh you youngsters!) on and form of Unix, you probably already have the first edition, or at least have read it. If not, go and get it (or this second edition). Along with The Unix Programming Environment, it's one of the classic texts that's not too large to read, but too useful to skip.
Liam
I've had an Acer laptop for 3 years, just bought one for my partner, and would not hesitate in buying more. I had a free 2-year warranty with mine, and that involved a guarantee that they'd fix it or replace it, within 2 business days. I had two problems (both related) and they made good on the promise.
You can get a 2-hour support (or is it 4 hour??) in the Greater Toronto Area.
Several Acer dealers have warned me that the very low end Acer laptops have a lot of problems. But they all also say that the higher end ones are first rate.
Frankly, I expect (based on published statistics as well as anecdotal evidence) that laptops are likely to go wrong in the first 2 years, especially if, like me, you travel a lot. So the warranty is really important to me.
Ask around in your area. Check the warranty, and ask the dealer before you buy. But for me, the Acer laptop I got (a Travelmate 602TER, 650MHz, 384M RAM (upgraded from 128), CD-RW drive, Mandrake Linux + Win98) was pretty good value at the time, and everything I needed worked in Linux, too.
I don't think I'd go so far as to say that Mandrake Linux is "built off" Red Hat Linux -- it was originally Red Hat with both Gnome and KDE and more up-to-date, but then,I suppose you could say Red Hat was built off slackware :-)
For my part, I use Mandrake Linux for several reasons:
[1] I evangelize a lot, and want to run the same software that I am telling others to try.
[2] I have very little time available for systems administration. I've been using Unix since 1981 (yes, over 22 years now) but that doesn't mean I *want* to edit config files inlots of different formats.
[3] I want a distribution that attracts both experienced developers and beginners, and keeps them - that means it has to have a good and very welcoming community, free of "learn this complex stuff because then you can be elite" for example
[4] I need automatic dependency tracking, and I want PGP-signed packages. If I say, urpmi foo and foo depends on bar, then both had better be donwloaded, checked and installed. Whilst rpmfind is a great resource, I'm pleased to say I've used it maybe twice in the past 18 months or so, and one of those occasions was to help someone running another Linux distribution.
There's a lot of strength in diversity, and I'm not going to say everyone should use Mandrake Linux by any means, but let's try and choose based on understanding.
Let's also hope Fedora is a success and helps at building up community - it's an area where Debian and Mandrake have done better than RH in the past, and I know that the people at RH are aware of that.
As an author I've had between 10% and 17% of publisher net sales as a royalty. That means that if the *publisher* gets $20 from the wholesaler, I might get $2 or $3 in royalties. Author royalties may be lower for foreign sales, depending ont he publisher and contract.
I got an advance - a cheque paid when I started writing the book, and another one when I submitted the final book - that was a total of between $10K and $16K (US$), again depending on the publisher.
Royalties count against the advance. In other words, if I got $10,000 up front, the book has to earn $10,000 in royalties before I start seeing any extra payments.
As a result, once the book is published, it's very unlikely the pubilsher will need to pay the author any more money.
The only time the author is really affected a lot by UK/US price differences is likely to be if the book did well enough to generate royalty cheques, and the wholesaler in the UK is paying the publisher much less than the one in the US.
Of course, if you buy cheap copies of books in India, chances are the author gets no royalties at all, with the possible end result that you don't get new textbooks from experienced writers, as they've gone off and got other jobs.
For me, the royalty advance was useful when I really needed the money, but the 6 months or more of work afterwards used up far more than the advance. I didn't write tet books to get rich, though, but mainly to help people, and also of course to boost my reputation as a consultant.
Note that for embedded systems the main interest is how long it takes for the kernel to load, not how long it is before a multi-user server or workstation has a prompt that says "login" on a pretty X display.
So, this is a good improvement it seems, but shaves away 4.5 seconds or so out of maybe 30 sconds or over a minute for many people. Combined with the parallel init scripts work mentioned a few days ago,though, I'm guessing that Linux systems will be booting a lot faster with the major releases in 6 months to a year.
If you get dependency problems when running Mandrake Linux, you're probably not doing it right :-)
/var/cache/urpmi/rpms for the downloaded RPM files.
Seriously, the urpmi command will download an RPM for you, together with everything it needs that you don't already have, and install everything. Automatically.
See plf and the main urpmi web page for more info; Mandrake comes with urpmi, and it's also used by the GUI package manager (rpmdrake).
The trick to keeping Mandrake Linux running heppily is to avoid rpmfind. Always start by looking for packages in Mandrake's main and contrib (you can add them as sources for urpmi, and then it's automatic, just, urpmi package).
If you can't find a package, try searching with rpmdrake (you can search based on filenames too), or use urpmq -y some-substring such as, urpmq -y apache to see all packages that provide things containing that string.
if you use urpmi for package management, you should find that dependency and version problems becomre very rare. I won't say they'll go away (any more than they go away entirely with apt-get) but they will become very rare.
If you do get problems with urpmi, look in
SVG itself is a W3C Recommendation, not an IETF RFC.
You may be surprised, if you look around... SVG is already pretty widely used. Examples: it's used for theming in the metacity window manager and in nautilus; for support in graphics editors, if dia and sodipodi don't ring a bell maybe you've come across Adobe Illustrator, or Microsoft Office 11's Visio.
I do agree that Mozilla has a long way to go. But it's worth it. SVG can be manipulated with XSLT and XML Query, can be generated with open source tools, stored in XML databases, is often massively smaller than Flash files, and can be made accessible. Depending on how much you script, it could also be indexed by google and other search engines.
You can see the W3C SVG page for more information.
Disclaimer: I work for the W3C, although I am not directly involved in SVG.