Sometimes a tap isn't a "tap". The type of kit that Shomiti sells is for use when the network admin knows about the tap, and "transparent" just means that it won't break the comms link, not that it's undetectable.
Simple TDR (time domain reflectometry) will discover one of these.
My deepest and most sincere apologies to the whole family if this bears no relation to their own tragedy but:
Friend of mine committed suicide a few years ago. Young guy, bright, over-achiever and successful in everything. -- except when he finally met something he couldn't deal with, to his previous standards of success. It wasn't any big deal; it was the sort of thing I screw up twice a year and don't think twice about, but for him it was something new, big and scary. So he shot himself.
Now in my friend's case, an awful lot of both why he'd been such an over-achiever, and why he'd found it impossible to deal with this one crisis, was pressure from his parents. Not much, not "Give me 20 or it's off to Military College with you" pressure, but just the pressure that was so concerned with "doing well" it had never taught him to cope with doing badly.
I'm just waiting for the first "it's all them damn H1B's taking all our jobs rant rant rant"
I work for HP in the UK. We hear the "it's those damn H1B's" rant in reference to the Brits who have been pushed back across the Pond and are now looking for jobs back in the UK.
I know what you mean about cheap HP printers not working under Linux -- but that's the same for all cheap printers, not just HP. Low-end printers are so impossibly cheap that half of the smarts aren't in there, they're leeching off your main CPU for processing. Nasty Windows drivers for these WinPrinters might sound like a good idea when they give you a I use Windows - but if I buy a printer, I get one that supports Linux, just to make sure it's not one of these accursed WinPrinter abominations.
First of all, what's the difference between Open Source and the W3C ? I have complete faith that many Slashdoterati will be able to explain exactly where they diverge 8-), but this is likely to involve Stallmannesque hair-splitting.
What can this chimerical "Open Source" movement offer that will suddenly fix all of the W3C's ills ? Who are these masked coders ? In what way do they differ from the people who already write the specs at the W3C ? The W3C isn't the Bilderberg Group ! It's not some shadowy neo-Illuminati cabal with arcane membership rituals and a split devotion to the forces of satan and global capitalism (that's ICANN).
People seem to think that "self-describing data" is going to save the world in the same way that XML was supposed to eliminate the need for parsing and interpretation of information by a computer program.
Self describing data is going to "save the world" (for small value of "save") - but XML never did that, and XML Schema barely begins to either. If you're going to communicate, then you don't just need self describing data, you need a shared vocabulary of description -- and this is a problem for DAML+OIL et al., not just XML Schema.
XML has removed the need to parse, or at least the need to write new parsers. XML Schema allows structural comprehension (which isn't the same as an ontological understanding) and validation to be similarly automated once and for all by a common toolset with a single API.
you still have to write programs to interpret the contents of the XML information in pretty much the same way as with data exchanged in any format.
You still need to "interpret", but you no longer need to parse. If your documents fit into the RSS 1.0 model, then interpretation becomes trivial for all documents expressible in RSS 1.0, because RSS 1.0 has a shared ontology behind it that's implicit in the use of the protocol. If you use RDF in conjunction with something like DAML+OIL, then you gain the same advantages, but over a much woder range of application than that of a "newsfeed"
XML alone can't remove the interpretation burden for you, but it can remove the parsing burden (which isn't trivial) and some of the protocols on top of XML, such as RDF, remove further horizontal slices of this "interpretation" workload for you.
most functioning protocols out there are able to exchange information without the need for a formal validation model
All protocols that work have a validation model -- but sometimes it's implicit and informal. You either do this (you "trust" the information provider) or you formalise it. Formalising it has two advantages; it removes some of the "trustworthiness" issues about unknown providers, but it also allows the "allocation of trust" to be deferred to individual documents. Rather than pre-agreeing with a known and trustworthy provider that they'll send you documents, they'll be valid documents, and you know the format for which they'll be valid, then you can do this for each document as it arrives. This is great, because it now means you can receive docuemnt formats you've never seen before, and you can still build a useful level of trust upon them. Implicit trust is great, but it limits you to providers you know about, and to formats that you know about.
Not that you would really want to use one [a validation schema] on either the generation or consumption side of a real system, since it just slows things down.
It doesn't slow things down, it speeds them up.
Think of network protocols and the layer stack model. The lower level you can perform an operation at, then the dumber that operation becomes and the less work it is to do it.
Ignoring the trivial "I don't care if this goes wrong" applications, then all applications need to validate data that they receive from external systems. If I can validate an invoice as being structurally valid by expressing useful constraints in a low-level schema (like XML Schema, but more likely DAML), then that's a lot quicker to work on than interpreting the document to be a data structure or object state for an invoice (which may have been so broken so as to raise an exception when I unserialized it) and then validating that object's internal state. Someone needs to do this validation, and it's quicker to do it low-down and dumb (and it's no less valid or reliable to do it that way).
Another thing that bugs me is the fiercely defended text-only approach used in XML.
Text only is good. It's fundamental to XML (XML Schema cannot change this) and there are many good arguments presented from back in the SGML days onwards as to why this is the right way to do it.
First, there's no way to directly include binary data
Don't need it. Encode it instead. Yes, there's an overhead (both in processing, and in volume) but that's minor, the advantages outweigh it, and DUMB ENCODING IS WHAT COMPUTERS ARE FOR !.
There's an argument that a DOM should be binary-aware, but no reason at all that the serialized XML document should be.
This is pretty strangely limited given that XML data is generally exchanged over an 8-bit clean pipe (i.e., the Web).
The web is not 8 bit clean, and the usage of character sets mean that anything in the top bit is already exposed to mis-interpretation errors. I guess you're American, because developers in most other countries hit this problem on a regular basis.
Also, XML is 16 bit clean (sic, in some views), because it's perfectly OK to Unicode that CDATA. I really do NOT want a binary route through XML that makes my application worry about whether the XML document had passed through an 8 bit, UTF-16 or even EBCDIC (!) transport on its travels.
<xml:binary size=10>kjiu õéçäá</xml:binary>
would be quite reasonable, with "size" octets placed directly between the closing '>' of the opening tag and the opening '' of the close tag.
First of all, your XML fragment sucks; xml as a namespace local identifier already has implicit connotations - i.e. xml:lang, and you ought to be quoting attributes properly if you're trying to lecture on syntactic changes.
Secondly, what's an "octet" ? There are no octets in XML - An octet is a well understood term in low-level comms meaning, "We have no idea what a word length is on this crate, or if a char is 7, 8 or 5 bit clean, but an octet is going to have exactly 8 bits in it". In XML, you just don't know this. It's hidden from you, and it's done deliberately so that your apps don't need to worry about it. If you change this, and make it visible, then that breaks a whole lot of i18n text-processing code.
They should have included a mechanism in XML Schema to declare this.
They can't. Even if it was a good idea, that level of change would have to be in XML itself, not XML Schema.
What is needed is a simple, widely acceptable binary encoding of exactly the information included in XML text, which uses lookup tables to optimize handling tag names.
We already have this. It's Huffmann coding, and any network protocol will already be doing it for you, low-down in the stack.
The third problem with exchanging raw text XML encoded data is that it explodes the information you want to ship
See above. Bloat is bad, but it's dealt with low-down.
The Semantic Web doesn't need XML Schema, I've never heard TBL say that it does, and XML Schema is certainly not a sufficient condition for the SW !
TBL seems to have an obsession with XML namespaces as a solution to everything (look at the big SVG "roadmap" in his WWW10 conference slides) and lately he seems to be taking an "Agents with Everything" line.
They're expressed in their own syntax, which no-one understands. XML Schema is expressed in XML.
Because XML Schema is in XML, it's machine-processable by a whole bunch of simple tools. It's trivial to write a database data-model -> XML Schema export tool.
DTDs are poor on complex structures.
DTDs don't do data-typing
DTDs are very poor when complexity meets data typing. XML Schema can support structured types in a manner that's akin to a struct.
XML Schema is quite a good TR for datatyping within XML, but it's still very limited at expressing large-scale structure (this is an XML limitation, not an XML Schema one) and does nothing for semantics or ontologies.
We still need RDF, and RDF still needs schema expression languages that are smarter than XML Schema. Current practice seems to be that RDF Schema is dead, DAML is the way forward and DAML gets its low-level data-typing from from XML Schema. Incidentally, this is a very good example of why XML Schemas structured types are dead handy, and usefully different from the normal XML structure expression.
There's a couple of interesting papers by
Jane Hunter and Carl Lagoze on XML, RDF and various schemas that describe some of the issues involved in different schema requirements, different expression languages, and how to compare them.
Microsoft have done what they usually do with XML: Build an excellent implementation before the W3C got there, get flamed to hell by the Slashdot weenies, then bring it quickly back into line once there's a standard worth using. We all like to beat on Bill, but for a few things (and XML is a big one) Microsoft deserve a lot of credit for some really good work.
I didn't buy a Panasonic, I bought a Dell. My contract is with Dell, and if anyone has redress against Panasonic, then it's Dell, not me.
It's Dell's responsibility to sell me a usable product. This may also involve them in a duty of care to validate their suppliers, so as to maintain this product's quality. As overheating Li-ion batteries have been a well-known problem since they first appeared, it's clearly incumbent upon Dell to ensure that their laptops are safe against it, their battery supplier can supply batteries that don't overheat, and their PSU (which is probably outsourced too) isn't likely to cause overheating (mis-charge any Li-ion battery and it will overheat).
When Jon Katz is famed for wittering on at great length about almost any subject, why is this review so short as to be worthless ?
We can work out what the book is about from its title. We all know plenty of people (sic) who manifest each and every form of net.addiction. So is the damn book any good ? What's in it ? Is it a study of addicted spods, or is it a self-help guide to curing them ? Does it think virtual addictions are great, and just recommend the lowest bandwidth charges to finance them ?
Unions WERE a necessity back during the first half of the 1900's, but the battles were won
I agree with your sentiment, but not your literal statement.
Read Marx - he's still as accurate as ever, if you can apply the appropriate contextual changes. His model of "industrial production" described the situation where a few individually expensive machines were assembled into factories, and the work was carried out by large numbers of unskilled or semi-skilled workers. This situation hasn't gone away; it has just shrunken or moved overseas. Nike's child sweatshop workers in Vietnam need a union today as much as Victorian miners or millworkers ever did.
Even in the "high tech" world, unions still have a place. Look at call centres; they're classic instances of industrialisation on the Marxist model. How many bank or mail-order service operators can leave tomorrow and work for themselves, without the owners of the call-centre operation behind them ? Even back in the affluent west, there are still plenty of workers who need unionisation and would benefit from them.
This simplistic view of industry doesn't cover skilled geeks, and those who work in similar areas, because the capitalist owner has no means of controlling my means of production. A PC and a mobile are cheap - I can start work tomorrow as an independent consultant, and make a good living without my large corporate employer. This is my current defence against exploitation, and (in the context of similar workers) it works better than joining a Union would.
There's also a US / UK issue here. The UK has had inept, greedy and self-destructive unions (BECTA !), but we were spared the widespread corruption and graft that blighted the US union system.
What is really of interest here is keeping the "server farm" working. This is the point where little Unix boxes and Big Blue iron start to look completely different.
In a BSD / Linux shop, you don't worry too much if one box gets hosed. You unplug it, load balance onto a bunch of other identical boxes, and plug in a new one fresh from CheapClones 'R Us. Later on, you either wipe and rebuild the hosed OS, or you throw away the smoking hardware and order some more, depending on whether you suffered H4XX0Rs or lightning. The big issue is keeping the network of lots of boxes secure and functioning.
In Big Blue's world, there's just the one server. There's only ever one server, because no matter how many city blocks it spreads over, the thing still feels like a single box. The power of their mainframe approach and OS is that it can feel like a single box, and it can feel like that to a whole load of people simultaneously. In this case "the network isn't the computer", but the computer is the computer. This changes the rules - networking becomes simpler, because there just isn't so much of it (that looks like it's "between independent boxes" anyway). OTOH, a server intrusion is far, far worse than it would ever be in the Unix world -- which is why the mainframe security guys are even more cautious than the rest of us.
Hummers only run on diesel, and anything else that can pretend to be diesel. Kerosene works, but it doesn't lubricate well and it increases wear on the injection system. It's also full of grit, if you use heating-grade kerosene, and this is enough to clog filters and stop your engine, unless you're careful.
The only "non-diesel" fuel a mil vehicle is ever likely to meet these days is jet (or jet turbine) fuel. Guess what - this is just kerosene with an aviation industry pricetag - works fine.
You can't use petrol (gasoline) in a Hummer, because of the fire hazard (and some _really_ crappy design mistakes, especially around the radio fitment). If you have to use it, SOP is to dilute it with diesel or kerosene. OTOH, it's a bit safer than the British Landrover design with the tanks under the seats and the leaky fillers - roll one of those and your ass was barbecued immediately - four cadets were killed in a single year, due to rollover accidents.
Marine diesel fuel (big ships) looks like treacle. You won't even get it into the tank, unless you warm it up.
The real purpose of military multi-fuellers isn't to run on alternative fuels, but to run on very poor qualities of the standard fuels. If you want to see how this should really work, look at the Leyland L60 engine in the Chieftain tank (a '50s design that served into the '80s) - that really would run on anything. Even marine bunker fuel worked, if you could only pump it in there.
PhilG can't be any worse of a Git than I am. Nearly all of the best geeks I've ever worked with have been prone to varying flavours of Gittishness. As another poster said, "his good understanding of what happened results in his inability to prevent his description from looking very one-sided: maybe he's not jumping to conclusions, just getting there very fast!". Smart geeks have always found it hard work to deal with people who can't think that fast (and we're supposed to apologise for thinking too fast ?)
One of my smartest cow-orkers is Mr Pedantic. I thought I was Mr Pedantic Git, but this guy is streets ahead of where I'll ever be. As he's also chair of a W3 group, then it's a damned good job he's so pedantic, or we'd get a crap spec at the end. I also know that if I can convince him that something is right, then it's damn right. Fortunately we're both in an industry where this sort of skill is vital and (occasionally) appreciated.
I work where I work because it's the only place I've been where people don't want to kill me after a week (about 3 months - thanks for asking 8-) ) -- and I haven't had to quietly bury a dullard in a suit for ages now.
A while ago I was in a design review at MIT. A bloke I'd never before met sat quietly at the table until MySQL was mentioned, then went off on one. A big one. Said his piece, got up, left. That was MySQL dealt with, and off the agenda. I was impressed - I agreed with everything he'd said, but never had same eloquence. It was a knee-jerk reaction, but then so was Bruce Lee - and it takes a similar degree of training to have reactions so quick, accurate and powerful.
BTW - It turned out to be Hal Abelson !
We're geeks. We're gits. It goes with the territory - if you're lucky. If a bunch of VCs can't deal with this, then just because they're playing with someone else's pension fund doesn't mean that we suddenly have to start talking down to their level. Smart is good. Loud, Confident and Right is good.
If you can't think at this level, get back to Wall St. where a simple diff equation is still regarded as some scary juju. The geeks shall inherit the Earth, and watch you don't spill burger grease on your nice suit when you're serving me.
[...] Then he could start over again, probably hiring a number of his old engineers, and if he played it right, maybe even steal some old clients back. [...]
I'm just out of a seminar on online communities, where I bewailed the fact that Slashdot's previously useful AC feature was now just a source of F1r5tTr0ll!!! posts. Thanks for reminding me that a few ACs still have useful points to make.
Does anyone know why aD took the poisoned chalice anyway ? Did they really need the money, want to expand hugely, or just get greedy ?
P&A isn't a technical how-to (Oracle and Tcl ? - not my idea of fun), but it describes an attitude to web design that's very important and rather different to many other views -- such as the accursed "Creating Killer Web Sites".
You don't have to re-read it or refer to it, but everyone should have read it once.
I work in The Smartest Place In The Universe (HP's research labs) because if there was anywhere else smarter, I'd be hammering on the door to be let in. If you cruise people's bookshelves round here, there's the usual smattering of O'Reillys, and MythicalMMs but nearly everyone also has their own personal copy of Phil & Alex. That's just about the best recommendation I can think of.
Without PhilG, ArsDigita are just another M$oft wannabee, and there's plenty of those already. I don't doubt the comments by some of his past cow-orkers that he's not the code-god he's sometimes worshipped as, and he's probably useless at managing a large staff of average geeks, but without their previous attitude, ArsDigita have lost everything that distinguished them from the rest of the herd.
I have no answers. I have a very large problem. I think it's one more and more sites are going to encounter in the next couple of years.
I'm working on the re-work of ARKive; an educational site about biodiversity and cute animals, with lots of streamed video. At present, the old site has no hits, and no real problems in funding the bandwidth. The problems start if our traffic grows at all, and the volume of available video increases as planned. The projected bandwidth charges are truly scary, and this is just a small site.
Broadband is a real threat to us, yet simultaneously our real justification for offering video. Even in sleepy old England, enough of the mass-market consumers are switching to local broadband that they can look at seriously large consumption -- our charges for server-side bandwidth haven't dropped at anything like the same rate. Potentially, if we're successful and popular, serving all this content could burn our cash reserves in a very short time.
So what's to be done ? Does it really mean that the only viable way to offer high quality video is by either drastic bandwidth throttling (first dozen people each month get to see it, then the lights go out), or by pay-per-view ?
Unlike some sites, I have throttling measures so that at least we won't receive an unexpectedly large hosting bill at month-end. There are plenty of horror stories though of people, usually the little guys, who've had a sudden content spike and found themselves whacked with a serious and unexpected bill.
So how exactly do you tell someone that their server/network/etc has security problems without opening yourself up for nasty things?
It's a big problem ! My response is to either invoice them for the work, or ignore it as it's just not my problem. If they want to know about site issues, then it's (part of) what I do for a living.
If they're not a client, then their site isn't any of my business. It's a big 'Net - at any time, most of it is broken in some way -- and I'm never going to fix it all myself. Nothing good will come of pointing out the glaring holes
If they can't afford me, then I might work for free -- but they're still a client, and there's a commercial relationship going on, even if no money changes hands. If we can't set this up right; i.e. they're going to listen to me, they're going to give me the authority to fix it properly, and they're not going to obstruct me doing it, then I can't work a proper client relationship and I'm best leaving it alone entirely.
If they don't want to hear it, don't tell them. You wouldn't have got it fixed anyway, and their arrogance isn't worth involving yourself over.
Someone else's bugs just aren't your problem. Even if this is "crashing airliner fault" territory, the current climate of legal, business, engineering and ethical practice just doesn't like whistleblowers -- messengers keep getting shot, because someone doesn't like their message.
HTML has a lot of white-space insensitivity. If you use a simple MD5 hash on the serialization, it will see many versions of the same page as "different", even though their core content isn't. Generally this isn't an issue (generation algorithms (and thus trivial space) don't change much), but it's still a design consideration.
Where this does start to make a difference, canonicalization before hashing fixes many of these problems. This is how the XML Sig hashes work. It's another reason why XHTML (or at least, authoring HTML as syntactically well-formed XML, even if it's invalid according to the DTD) is often a good idea.
To go back to HTML, really useful versioning and change spotting needs to ignore banner ads, generation timestamp comments and other superfluous crud. Semantically aware markup and a suitable stripper in the canonicalizer can make it work even better. Of course it now depends on both client and server having consistent goals; a server might not want you to ignore changes in their banner ads.
Re:Ruby CGI module's HTML generation methods
on
Programming Ruby
·
· Score: 1
There's no such thing as a programming language - what matters is the mindset, and the legacy baggage.
Ruby is new and shining, offering to solve all our problems, sleep in the wet spot and wash our socks for us afterwards. Yet already they've impaired it with this module that thinks it knows all now and future HTML DTDs.
What if I want to generate WML or cXHTML next week ? Why should I have to re-learn another module, or even have to write one from scratch ?
CGI isn't just about HTML. For the authors of a first-generation "CGI" module to have assumed it would only ever need to serve HTML is a big, big mistake.
Re:Who wants to write CGI anyway ?
on
Programming Ruby
·
· Score: 1
I saw the link for mod_ruby (but thought it was worth mentioning anyway) but what I saw on eRuby didn't reassure me. What's the process model on this thing ? By the looks of it it's a command-line app that someone thought would be K00L to pretend was a web back end. Yes, it probably works (sic), but the performance issues of loose coupling here should be obvious.
It certainly didn't strike me that Ruby was pitching itself as a serious contender in the JSP stakes.
Who wants to write CGI anyway ?
on
Programming Ruby
·
· Score: 1
Ruby sounds like fun - but all we ever write these days are web back-ends, and CGI just isn't a fun way to do those. Is there anything like mod_ruby, Rubettes, Ruby Server Pages or even (Bill be merciful) RubyScript for ASP ?
Slashdot Mirror
Sometimes a tap isn't a "tap". The type of kit that Shomiti sells is for use when the network admin knows about the tap, and "transparent" just means that it won't break the comms link, not that it's undetectable.
Simple TDR (time domain reflectometry) will discover one of these.
When was the last time _you_ wanted to climb a building?
About 2 seconds after I saw the article ?
Who needs a real use for this thing ? It's cool as anything, and I want one now ! Hell, I want one for my cat too.
I'm going to fly right off the handle here.
My deepest and most sincere apologies to the whole family if this bears no relation to their own tragedy but:
Friend of mine committed suicide a few years ago. Young guy, bright, over-achiever and successful in everything. -- except when he finally met something he couldn't deal with, to his previous standards of success. It wasn't any big deal; it was the sort of thing I screw up twice a year and don't think twice about, but for him it was something new, big and scary. So he shot himself.
Now in my friend's case, an awful lot of both why he'd been such an over-achiever, and why he'd found it impossible to deal with this one crisis, was pressure from his parents. Not much, not "Give me 20 or it's off to Military College with you" pressure, but just the pressure that was so concerned with "doing well" it had never taught him to cope with doing badly.
I'm just waiting for the first "it's all them damn H1B's taking all our jobs rant rant rant"
I work for HP in the UK. We hear the "it's those damn H1B's" rant in reference to the Brits who have been pushed back across the Pond and are now looking for jobs back in the UK.
I know what you mean about cheap HP printers not working under Linux -- but that's the same for all cheap printers, not just HP. Low-end printers are so impossibly cheap that half of the smarts aren't in there, they're leeching off your main CPU for processing. Nasty Windows drivers for these WinPrinters might sound like a good idea when they give you a I use Windows - but if I buy a printer, I get one that supports Linux, just to make sure it's not one of these accursed WinPrinter abominations.
First of all, what's the difference between Open Source and the W3C ? I have complete faith that many Slashdoterati will be able to explain exactly where they diverge 8-), but this is likely to involve Stallmannesque hair-splitting.
What can this chimerical "Open Source" movement offer that will suddenly fix all of the W3C's ills ? Who are these masked coders ? In what way do they differ from the people who already write the specs at the W3C ? The W3C isn't the Bilderberg Group ! It's not some shadowy neo-Illuminati cabal with arcane membership rituals and a split devotion to the forces of satan and global capitalism (that's ICANN).
People seem to think that "self-describing data" is going to save the world in the same way that XML was supposed to eliminate the need for parsing and interpretation of information by a computer program.
Self describing data is going to "save the world" (for small value of "save") - but XML never did that, and XML Schema barely begins to either. If you're going to communicate, then you don't just need self describing data, you need a shared vocabulary of description -- and this is a problem for DAML+OIL et al., not just XML Schema.
XML has removed the need to parse, or at least the need to write new parsers. XML Schema allows structural comprehension (which isn't the same as an ontological understanding) and validation to be similarly automated once and for all by a common toolset with a single API.
you still have to write programs to interpret the contents of the XML information in pretty much the same way as with data exchanged in any format.
You still need to "interpret", but you no longer need to parse. If your documents fit into the RSS 1.0 model, then interpretation becomes trivial for all documents expressible in RSS 1.0, because RSS 1.0 has a shared ontology behind it that's implicit in the use of the protocol. If you use RDF in conjunction with something like DAML+OIL, then you gain the same advantages, but over a much woder range of application than that of a "newsfeed"
XML alone can't remove the interpretation burden for you, but it can remove the parsing burden (which isn't trivial) and some of the protocols on top of XML, such as RDF, remove further horizontal slices of this "interpretation" workload for you.
most functioning protocols out there are able to exchange information without the need for a formal validation model
All protocols that work have a validation model -- but sometimes it's implicit and informal. You either do this (you "trust" the information provider) or you formalise it. Formalising it has two advantages; it removes some of the "trustworthiness" issues about unknown providers, but it also allows the "allocation of trust" to be deferred to individual documents. Rather than pre-agreeing with a known and trustworthy provider that they'll send you documents, they'll be valid documents, and you know the format for which they'll be valid, then you can do this for each document as it arrives. This is great, because it now means you can receive docuemnt formats you've never seen before, and you can still build a useful level of trust upon them. Implicit trust is great, but it limits you to providers you know about, and to formats that you know about.
Not that you would really want to use one [a validation schema] on either the generation or consumption side of a real system, since it just slows things down.
It doesn't slow things down, it speeds them up. Think of network protocols and the layer stack model. The lower level you can perform an operation at, then the dumber that operation becomes and the less work it is to do it.
Ignoring the trivial "I don't care if this goes wrong" applications, then all applications need to validate data that they receive from external systems. If I can validate an invoice as being structurally valid by expressing useful constraints in a low-level schema (like XML Schema, but more likely DAML), then that's a lot quicker to work on than interpreting the document to be a data structure or object state for an invoice (which may have been so broken so as to raise an exception when I unserialized it) and then validating that object's internal state. Someone needs to do this validation, and it's quicker to do it low-down and dumb (and it's no less valid or reliable to do it that way).
Another thing that bugs me is the fiercely defended text-only approach used in XML.
Text only is good. It's fundamental to XML (XML Schema cannot change this) and there are many good arguments presented from back in the SGML days onwards as to why this is the right way to do it.
First, there's no way to directly include binary data
Don't need it. Encode it instead. Yes, there's an overhead (both in processing, and in volume) but that's minor, the advantages outweigh it, and DUMB ENCODING IS WHAT COMPUTERS ARE FOR !.
There's an argument that a DOM should be binary-aware, but no reason at all that the serialized XML document should be.
This is pretty strangely limited given that XML data is generally exchanged over an 8-bit clean pipe (i.e., the Web).
The web is not 8 bit clean, and the usage of character sets mean that anything in the top bit is already exposed to mis-interpretation errors. I guess you're American, because developers in most other countries hit this problem on a regular basis.
Also, XML is 16 bit clean (sic, in some views), because it's perfectly OK to Unicode that CDATA. I really do NOT want a binary route through XML that makes my application worry about whether the XML document had passed through an 8 bit, UTF-16 or even EBCDIC (!) transport on its travels.
<xml:binary size=10>kjiu õéçäá</xml:binary>
would be quite reasonable, with "size" octets placed directly between the closing '>' of the opening tag and the opening '' of the close tag.
First of all, your XML fragment sucks; xml as a namespace local identifier already has implicit connotations - i.e. xml:lang, and you ought to be quoting attributes properly if you're trying to lecture on syntactic changes.
Secondly, what's an "octet" ? There are no octets in XML - An octet is a well understood term in low-level comms meaning, "We have no idea what a word length is on this crate, or if a char is 7, 8 or 5 bit clean, but an octet is going to have exactly 8 bits in it". In XML, you just don't know this. It's hidden from you, and it's done deliberately so that your apps don't need to worry about it. If you change this, and make it visible, then that breaks a whole lot of i18n text-processing code.
They should have included a mechanism in XML Schema to declare this.
They can't. Even if it was a good idea, that level of change would have to be in XML itself, not XML Schema.
What is needed is a simple, widely acceptable binary encoding of exactly the information included in XML text, which uses lookup tables to optimize handling tag names.
We already have this. It's Huffmann coding, and any network protocol will already be doing it for you, low-down in the stack.
The third problem with exchanging raw text XML encoded data is that it explodes the information you want to ship
See above. Bloat is bad, but it's dealt with low-down.
The MIME tags really need to be updated too
They have been. See RFC 3023.
The Semantic Web doesn't need XML Schema, I've never heard TBL say that it does, and XML Schema is certainly not a sufficient condition for the SW !
TBL seems to have an obsession with XML namespaces as a solution to everything (look at the big SVG "roadmap" in his WWW10 conference slides) and lately he seems to be taking an "Agents with Everything" line.
As to why DTDs are suck-worthy, then:
XML Schema is expressed in XML.
XML Schema is quite a good TR for datatyping within XML, but it's still very limited at expressing large-scale structure (this is an XML limitation, not an XML Schema one) and does nothing for semantics or ontologies.
We still need RDF, and RDF still needs schema expression languages that are smarter than XML Schema. Current practice seems to be that RDF Schema is dead, DAML is the way forward and DAML gets its low-level data-typing from from XML Schema. Incidentally, this is a very good example of why XML Schemas structured types are dead handy, and usefully different from the normal XML structure expression. There's a couple of interesting papers by Jane Hunter and Carl Lagoze on XML, RDF and various schemas that describe some of the issues involved in different schema requirements, different expression languages, and how to compare them.
Microsoft have done what they usually do with XML: Build an excellent implementation before the W3C got there, get flamed to hell by the Slashdot weenies, then bring it quickly back into line once there's a standard worth using. We all like to beat on Bill, but for a few things (and XML is a big one) Microsoft deserve a lot of credit for some really good work.
I didn't buy a Panasonic, I bought a Dell. My contract is with Dell, and if anyone has redress against Panasonic, then it's Dell, not me.
It's Dell's responsibility to sell me a usable product. This may also involve them in a duty of care to validate their suppliers, so as to maintain this product's quality. As overheating Li-ion batteries have been a well-known problem since they first appeared, it's clearly incumbent upon Dell to ensure that their laptops are safe against it, their battery supplier can supply batteries that don't overheat, and their PSU (which is probably outsourced too) isn't likely to cause overheating (mis-charge any Li-ion battery and it will overheat).
When Jon Katz is famed for wittering on at great length about almost any subject, why is this review so short as to be worthless ?
We can work out what the book is about from its title. We all know plenty of people (sic) who manifest each and every form of net.addiction. So is the damn book any good ? What's in it ? Is it a study of addicted spods, or is it a self-help guide to curing them ? Does it think virtual addictions are great, and just recommend the lowest bandwidth charges to finance them ?
Unions WERE a necessity back during the first half of the 1900's, but the battles were won
I agree with your sentiment, but not your literal statement.
Read Marx - he's still as accurate as ever, if you can apply the appropriate contextual changes. His model of "industrial production" described the situation where a few individually expensive machines were assembled into factories, and the work was carried out by large numbers of unskilled or semi-skilled workers. This situation hasn't gone away; it has just shrunken or moved overseas. Nike's child sweatshop workers in Vietnam need a union today as much as Victorian miners or millworkers ever did.
Even in the "high tech" world, unions still have a place. Look at call centres; they're classic instances of industrialisation on the Marxist model. How many bank or mail-order service operators can leave tomorrow and work for themselves, without the owners of the call-centre operation behind them ? Even back in the affluent west, there are still plenty of workers who need unionisation and would benefit from them.
This simplistic view of industry doesn't cover skilled geeks, and those who work in similar areas, because the capitalist owner has no means of controlling my means of production. A PC and a mobile are cheap - I can start work tomorrow as an independent consultant, and make a good living without my large corporate employer. This is my current defence against exploitation, and (in the context of similar workers) it works better than joining a Union would.
There's also a US / UK issue here. The UK has had inept, greedy and self-destructive unions (BECTA !), but we were spared the widespread corruption and graft that blighted the US union system.
What is really of interest here is keeping the "server farm" working. This is the point where little Unix boxes and Big Blue iron start to look completely different.
In a BSD / Linux shop, you don't worry too much if one box gets hosed. You unplug it, load balance onto a bunch of other identical boxes, and plug in a new one fresh from CheapClones 'R Us. Later on, you either wipe and rebuild the hosed OS, or you throw away the smoking hardware and order some more, depending on whether you suffered H4XX0Rs or lightning. The big issue is keeping the network of lots of boxes secure and functioning.
In Big Blue's world, there's just the one server. There's only ever one server, because no matter how many city blocks it spreads over, the thing still feels like a single box. The power of their mainframe approach and OS is that it can feel like a single box, and it can feel like that to a whole load of people simultaneously. In this case "the network isn't the computer", but the computer is the computer. This changes the rules - networking becomes simpler, because there just isn't so much of it (that looks like it's "between independent boxes" anyway). OTOH, a server intrusion is far, far worse than it would ever be in the Unix world -- which is why the mainframe security guys are even more cautious than the rest of us.
Hummers only run on diesel, and anything else that can pretend to be diesel. Kerosene works, but it doesn't lubricate well and it increases wear on the injection system. It's also full of grit, if you use heating-grade kerosene, and this is enough to clog filters and stop your engine, unless you're careful.
The only "non-diesel" fuel a mil vehicle is ever likely to meet these days is jet (or jet turbine) fuel. Guess what - this is just kerosene with an aviation industry pricetag - works fine.
You can't use petrol (gasoline) in a Hummer, because of the fire hazard (and some _really_ crappy design mistakes, especially around the radio fitment). If you have to use it, SOP is to dilute it with diesel or kerosene. OTOH, it's a bit safer than the British Landrover design with the tanks under the seats and the leaky fillers - roll one of those and your ass was barbecued immediately - four cadets were killed in a single year, due to rollover accidents.
Marine diesel fuel (big ships) looks like treacle. You won't even get it into the tank, unless you warm it up.
The real purpose of military multi-fuellers isn't to run on alternative fuels, but to run on very poor qualities of the standard fuels. If you want to see how this should really work, look at the Leyland L60 engine in the Chieftain tank (a '50s design that served into the '80s) - that really would run on anything. Even marine bunker fuel worked, if you could only pump it in there.
Been There, Done That. 8-)
Couldn't bear all the meetings we used to have working for Lucent. I'm still a big Carly fan though.
PhilG can't be any worse of a Git than I am. Nearly all of the best geeks I've ever worked with have been prone to varying flavours of Gittishness. As another poster said, "his good understanding of what happened results in his inability to prevent his description from looking very one-sided: maybe he's not jumping to conclusions, just getting there very fast!". Smart geeks have always found it hard work to deal with people who can't think that fast (and we're supposed to apologise for thinking too fast ?)
One of my smartest cow-orkers is Mr Pedantic. I thought I was Mr Pedantic Git, but this guy is streets ahead of where I'll ever be. As he's also chair of a W3 group, then it's a damned good job he's so pedantic, or we'd get a crap spec at the end. I also know that if I can convince him that something is right, then it's damn right. Fortunately we're both in an industry where this sort of skill is vital and (occasionally) appreciated.
I work where I work because it's the only place I've been where people don't want to kill me after a week (about 3 months - thanks for asking 8-) ) -- and I haven't had to quietly bury a dullard in a suit for ages now.
A while ago I was in a design review at MIT. A bloke I'd never before met sat quietly at the table until MySQL was mentioned, then went off on one. A big one. Said his piece, got up, left. That was MySQL dealt with, and off the agenda. I was impressed - I agreed with everything he'd said, but never had same eloquence. It was a knee-jerk reaction, but then so was Bruce Lee - and it takes a similar degree of training to have reactions so quick, accurate and powerful.
BTW - It turned out to be Hal Abelson !
We're geeks. We're gits. It goes with the territory - if you're lucky. If a bunch of VCs can't deal with this, then just because they're playing with someone else's pension fund doesn't mean that we suddenly have to start talking down to their level. Smart is good. Loud, Confident and Right is good.
If you can't think at this level, get back to Wall St. where a simple diff equation is still regarded as some scary juju. The geeks shall inherit the Earth, and watch you don't spill burger grease on your nice suit when you're serving me.
[...] Then he could start over again, probably hiring a number of his old engineers, and if he played it right, maybe even steal some old clients back. [...]
I'm just out of a seminar on online communities, where I bewailed the fact that Slashdot's previously useful AC feature was now just a source of F1r5tTr0ll!!! posts. Thanks for reminding me that a few ACs still have useful points to make.
Does anyone know why aD took the poisoned chalice anyway ? Did they really need the money, want to expand hugely, or just get greedy ?
P&A isn't a technical how-to (Oracle and Tcl ? - not my idea of fun), but it describes an attitude to web design that's very important and rather different to many other views -- such as the accursed "Creating Killer Web Sites".
You don't have to re-read it or refer to it, but everyone should have read it once.
I work in The Smartest Place In The Universe (HP's research labs) because if there was anywhere else smarter, I'd be hammering on the door to be let in. If you cruise people's bookshelves round here, there's the usual smattering of O'Reillys, and MythicalMMs but nearly everyone also has their own personal copy of Phil & Alex. That's just about the best recommendation I can think of.
Without PhilG, ArsDigita are just another M$oft wannabee, and there's plenty of those already. I don't doubt the comments by some of his past cow-orkers that he's not the code-god he's sometimes worshipped as, and he's probably useless at managing a large staff of average geeks, but without their previous attitude, ArsDigita have lost everything that distinguished them from the rest of the herd.
I have no answers. I have a very large problem. I think it's one more and more sites are going to encounter in the next couple of years.
I'm working on the re-work of ARKive; an educational site about biodiversity and cute animals, with lots of streamed video. At present, the old site has no hits, and no real problems in funding the bandwidth. The problems start if our traffic grows at all, and the volume of available video increases as planned. The projected bandwidth charges are truly scary, and this is just a small site.
Broadband is a real threat to us, yet simultaneously our real justification for offering video. Even in sleepy old England, enough of the mass-market consumers are switching to local broadband that they can look at seriously large consumption -- our charges for server-side bandwidth haven't dropped at anything like the same rate. Potentially, if we're successful and popular, serving all this content could burn our cash reserves in a very short time.
So what's to be done ? Does it really mean that the only viable way to offer high quality video is by either drastic bandwidth throttling (first dozen people each month get to see it, then the lights go out), or by pay-per-view ?
Unlike some sites, I have throttling measures so that at least we won't receive an unexpectedly large hosting bill at month-end. There are plenty of horror stories though of people, usually the little guys, who've had a sudden content spike and found themselves whacked with a serious and unexpected bill.
So how exactly do you tell someone that their server/network/etc has security problems without opening yourself up for nasty things?
It's a big problem ! My response is to either invoice them for the work, or ignore it as it's just not my problem. If they want to know about site issues, then it's (part of) what I do for a living.
If they're not a client, then their site isn't any of my business. It's a big 'Net - at any time, most of it is broken in some way -- and I'm never going to fix it all myself. Nothing good will come of pointing out the glaring holes
If they can't afford me, then I might work for free -- but they're still a client, and there's a commercial relationship going on, even if no money changes hands. If we can't set this up right; i.e. they're going to listen to me, they're going to give me the authority to fix it properly, and they're not going to obstruct me doing it, then I can't work a proper client relationship and I'm best leaving it alone entirely.
If they don't want to hear it, don't tell them.
You wouldn't have got it fixed anyway, and their arrogance isn't worth involving yourself over.
Someone else's bugs just aren't your problem. Even if this is "crashing airliner fault" territory, the current climate of legal, business, engineering and ethical practice just doesn't like whistleblowers -- messengers keep getting shot, because someone doesn't like their message.
HTML has a lot of white-space insensitivity. If you use a simple MD5 hash on the serialization, it will see many versions of the same page as "different", even though their core content isn't. Generally this isn't an issue (generation algorithms (and thus trivial space) don't change much), but it's still a design consideration.
Where this does start to make a difference, canonicalization before hashing fixes many of these problems. This is how the XML Sig hashes work. It's another reason why XHTML (or at least, authoring HTML as syntactically well-formed XML, even if it's invalid according to the DTD) is often a good idea.
To go back to HTML, really useful versioning and change spotting needs to ignore banner ads, generation timestamp comments and other superfluous crud. Semantically aware markup and a suitable stripper in the canonicalizer can make it work even better. Of course it now depends on both client and server having consistent goals; a server might not want you to ignore changes in their banner ads.
There's no such thing as a programming language - what matters is the mindset, and the legacy baggage.
Ruby is new and shining, offering to solve all our problems, sleep in the wet spot and wash our socks for us afterwards. Yet already they've impaired it with this module that thinks it knows all now and future HTML DTDs.
What if I want to generate WML or cXHTML next week ? Why should I have to re-learn another module, or even have to write one from scratch ?
CGI isn't just about HTML. For the authors of a first-generation "CGI" module to have assumed it would only ever need to serve HTML is a big, big mistake.
It certainly didn't strike me that Ruby was pitching itself as a serious contender in the JSP stakes.
Ruby sounds like fun - but all we ever write these days are web back-ends, and CGI just isn't a fun way to do those. Is there anything like mod_ruby, Rubettes, Ruby Server Pages or even (Bill be merciful) RubyScript for ASP ?
Funny thing is; the more he thinks, the luckier he gets...