XHTML 2 is being canceled not because it failed, but because the only advantage over XHTML 1 was being more modular, which nobody really cared about.
You don't mean XHTML 1.1 do you? That was just a modular version of XHTML 1.0 and as you say didn't offer much to make it worthwhile.
XHTML 2 was quite a radical change and in an ideal world would've been much better I reckon. The trouble was that the real world of legacy browsers and content was never going to manage the transition as it was too different (plus a big chicken and egg problem). So we've ended up with HTML 5, which although not as good as XHTML 2 (IMO) at least degrades gracefully in older browsers and manages the transition much more smoothly. Thus it actually has a good chance of being eventually adopted.
You write your document in XSL:FO markup, and then one of any number of processors like XEP to convert it into PDF or what have you.
Ouch:)
Hand writing XSL:FO is extremely painful - very fiddly and the embedded layout/styling gets tedious quickly. It's kinda like writing a very very long webpage using HTML 3.2 with all the nasty old embedded presentation tags (but worse).
One of the original purposes of it was so that you could use XSLTs to transform the same XML data into both XHTML or XSL:FO for publishing.
I have a feeling that is a bit backwards. The original standard was XSL and it was going to include everything related to transforms and publishing, but it got too large and complex so they split it into XSLT for the transforms and XSL:FO for the page description language. Much better that way, as XSLT has wider uses than publishing.
I think XSL:FO was always intended to be generated via XSLT rather than hand written, and I don't think that has changed at all. That way if you only need to a styling change, rather than making a zillion edits throughout the document you change the transform. It is analogous to how CSS make styling changes much easier with HTML.
Personally I'd rather use some other semantic format (eg Docbook, DITA etc) that can be transformed into XSL:FO via XSLT when required (eg on the way to PDF generation). That way you already get some handy XSLT starting points to work with. Making the occasional small tweak to XSLT isn't too bad, but writing a large complex set of transforms from scratch isn't something I'd want to do:)
That is already the case. CSS isn't just designed for HTML - it is designed to be able to be applied to any XML language also. Although XHTML is really the only common XML language where the user agents have implemented CSS rendering engines (they are very complex).
Do any web browsers handle applying CSS to arbitrary (but valid) XML files that aren't HTML?
Other layout options have been in the works for a long time, and it will still be a long time before browser support is ubiquitous.
CSS 3 has support for newspaper style text columns, and CSS 2.x allowed for laying out arbitrary elements using the same rules as various table elements - CSS 2 was released over 10 yrs ago, but IE only recently supported this part in IE 8.
CSS 3 has languished while everyone waited for widespread CSS 2.x support to actually happen. It seems like we'll just need legacy IE versions to die out before anyone bothers with progressing CSS 3 further. Hopefully it doesn't die on the vine the same way XHTML 1.1 or 2.0 did.
While popular music on the whole really really sucked during the 80's due to the marketing stranglehold of large record labels, it still produced a lot of great stuff that was less well known. Music diversified quite a lot during the 80s, but it wasn't until the 90s or later that the newer genres grew enough to be noticed by the mainstream. Unfortunately by then, much of it had lost some (or a lot) of its original creativity or got ruined by attempts by others to cash in on trends.
And as an aside New Order and The Stone Roses were still huge sellers (maybe not in the US though), and it's probably a stretch to say Nirvana was a Pixies ripoff rather than just being an influence.
Seriously though, my brother did actually walk into Myanmar while he was backpacking with friends in Thailand. Just walked across some river on the border - they didn't hang around long though.
He didn't try swimming across a lake to rescue a princess... now that would be far fetched:)
Dogs are adapt at running all day? Bet you never owned a dog.
Well the first domesticated dogs were wolves, and wolves are well known for their endurance. Maybe the the first dogs didn't resemble your Bichon Frise.
A few of the dogs I've known could still run all day too. One of ours would spend hours at a time sprinting at full speed up and down beaches chasing seagulls - I'm sure if he paced himself he could run all day quite easily.
And if that is the reason dogs do so well with human beings, please explain everyother domesticated animal to me. From cats to cattle.
One explanation: dogs were domesticated early on by hunter gatherers, and other animals came along later as settlements formed. Seems plausible to me.
OpenBSD does ship with services turned on though - eg OpenSSH and a few other mostly minor ones. But it is more than just exposed services - how many remotely exploitable kernel vulnerabilities have other systems patched over the last 10 yrs?
I'm no OpenBSD zealot (I'm mainly a Linux user), but OpenBSDs security track record and attention to detail is impressive. Quite often exploits in 3rd party code are mitigated or ineffective on OpenBSD due to measures they have taken.
It's not all roses though - keeping 3rd party apps patched on OpenBSD is harder than say Debian. They just don't have the resources to manage vast repositories like Linux distros do. Which is the big reason I will normally use Debian instead of OpenBSD.
I have to say, despite the goofy approach and crazy graphics in the Head First series, they are an effective learning tool and a more enjoyable read than a "standard" technical book for beginners.
I hear that a lot and they've done a lot of research into their methods, so I'm probably atypical and possibly just weird...
I've spent some time with the Design Patterns one and I struggle with it (I really want to like it). Sure it did OK with higher level stuff like "why" you want to use them (and "why not" too, which is important), and getting a vague idea of what each example did.
But whenever I try to grok the nitty gritty bits I keep getting too distracted to concentrate on any of the details. It seems like the print version of a web page filled with flashing and blinking ads where you have to piece together bits from all over the place. Sifting through all the preliminary "not-quite-correct" examples also gets in the way of understanding the "correct" one later on. I seem to expend too much energy evaluating the value of the distractions instead of learning.
I get a mild but tiring sense of disorientation with "Head First" books that I don't get elsewhere. I suspect I'm quite different to the average reader:)
In my experience at this job, it is far, far easier to find solutions for the problems we've faced for our open-source software on Google than it is to find solutions for the problems we've faced on our proprietary systems. With open source software, chances are someone with enough coding skills to troubleshoot the software has already encountered the problem and has posted a fix.
Another factor is that with closed support, the visibility of the problem is hidden from Google even if it has been solved already. It all takes place over phone and email. So that combined with the typically less specific error messages you get with MS products means that troubleshooting them on Google is harder than it should be.
No, I'm not claiming Java isn't better than PHP, just that Java isn't more dynamic than PHP (as was claimed).
Although its probably true overall, I wasn't even claiming that Java devs are better overall than PHP devs, just that they tend focus more effort on architecture. Even to the point of going too far and over complicating things sometimes.
I'd even hazard a guess that being in a less dynamic environment requires them to put more effort into architecture. Compared to PHP it is much harder to "just make it up as you go along" in Java.
Flexible modular apps are possible in PHP if the developers design them like that though. Likewise a Java app that isn't designed to be flexible and modular won't be flexible and modular.
In addition, Java has a much better system for componentization. PHP apps are often deployed as large sets of files. This has its advantages, but it also means that plugins are often achieved by modifying PHP code. The Java platform is a more dynamic platform that allows for components to easily be plugged in. With Java, adding new features to your blog or forums can be as easy as clicking the "install" button in the admin console.
Nonsense.
What you are seeing that typically Java developers are more likely to be "architecture astronauts" and architect their apps towards componentisation etc sometimes at the expense of simplicity and clarity.
And typically PHP developers under-architect their apps and write them as kludgy non modular spaghetti code.
There is nothing more dynamic than PHP about Java itself - if anything it is the opposite. A lot of the common design patterns in Java are to get around the non dynamic nature of it, and I suspect it is this that makes Java devs far more conscious of architecture than PHP developers.
eg Drupal (PHP) has a very modular architecture and has thousands of plugin modules and has a culture that strongly discourages changing the core codebase. And whaddya know, a lot of the core devs are or have been Java developers and the founder even did a Phd in it.
Either way, if you want to use a pluggable component based architecture for your app you have to design it that way - the language won't do it for you.
I guess you could just refuse to back up those keytabs on the client machines. In a disaster recovery, couldn't you just re-export the keys from the KDC? It looks easy enough.
Yep, that could work and you could even automate it to a degree.
But (for disaster recovery purposes) you've still got to be able to back up the KDC securely, so if you can do that you may as well just back up the webserver securely too:)
Although I suppose you could strip the passwords from the KDC backups, and recreate them all after a recovery too. For a site with mostly service principals (gah - I keep typoing that as "principles") it could be ok to automate, but lots of user principals would be a pain.
IMO there is a bit of a blind spot amongst typical Windows admins about how Kerberos works (I'm still somewhat hazy about it) because they are so shielded from it. Getting a *nix machine working with your AD via Kerberos is a very useful exercise as the internal workings are more exposed.
Between Windows Active Directory (Windows Integrated Security) and Kerberos? For the sake of my argument, there is none, because AD IS a Kerberos server. You can even authenticate Linux machines against it.
No, the question is what's difference in security between a text file only readable by the webserver account and a Kerberos keytab file only readable by the webserver account.
Not if its in a clearly readable backup file on another running machine, Chief. That's how they got compromised, remember? The backup crapped up their security model. If your text config file has no password in it, due to you using "trusted connections", the attacker can't read it, no matter where you store it on the network.
Wouldn't the same backup have the Kerberos keytab file in it? If the attacker gets the keytab, they can impersonate the webservers service principal (and any others stored in the same keytab) all they like.
Best practice is to have a separate machine (physical or virtual) that does nothing but authentication (Kerberos) and authorization (LDAP) of principals (logon accounts) for the network. No Apache, no db server, no DNS, nothing goofy, just handles security requests.
Your separate security server would only be SSH or console accessible, using Kerberos authentication only, so the attacker couldn't brute-force his way in through SSH. Even then only the Network Admin(s) would even have logon rights to that one machine.
Yeah, that's the security for the passwords stored in the KDC handled. But the attacker doesn't need to crack the KDC and get the password for the webservers service principal - they already have the keytab file containing the tickets for the service principal because it was in the backup.
That's why I don't (yet at least) see the difference between a DB user account password stored in a text file on the webserver, and storing a Kerberos ticket for a service principle in a keytab file on the webserver. Both methods rely on neither the webserver nor its backups getting compromised.
I know Active Directory doesn't use keytab files for the service accounts the same way Unix does, but the same kind of info contained in a keytab has to get registered and stored on the webserver somehow. It's part of becoming a domain member, and registering service accounts with services after entering the password of the service account when you configure the service.
Now for a secure option with Windows servers (I remember trying this out on NT4 back in the day so I presume it still can be done on later versions), there is/was a utility to encrypt enough about the servers SAM in such a way that the server needed a passphrase entered on the console or read from a floppy to decrypt them before it could carry on booting. That should solve the pilfered backup problem, but of course it is such a huge hassle when managing remote servers and applying services packs etc that I can't imagine it really being used much.
I don't believe that Microsoft has given Apple a free pass, and crushed every other competitors under the ruthless weight of their monopolistic behavior. If they could crush Apple, I'm sure they would,
MS practically saved Apple from bankruptcy in the 90s by investing hundred of millions in them, and wrote a Mac version of Office and the default Mac browser for a while. Doesn't sound like they have wanted to crush Apple much at all.
MS realises that without Apple around, they are far more vulnerable to anti-trust problems. I'm sure MS are completely happy that Apples OS only officially works on exclusive hardware from Apple itself, that Apple keeps its nose out of the enterprise market, and MS can even make some money from Apple users. Apple is happy sticking to that market, and they don't pose much danger to MS unless they drastically change their business plan which is very unlikely.
Linux and FOSS on the other hand has the potential (however slight) to upset or disrupt the whole apple cart (no pun intended). MS isn't threatened by more expensive niche competition, but will fight anything that could undercut them or shift relevancy away from their platform (eg Netscape).
Either way, the web server's service process logs onto the database with the credentials of its own user account (a Kerberos ticket), providing no password. The attacker cannot log in to the database server unless they manage to get logged in AS the web server's user account. This is much harder to do than just snagging the db logon info out of some plain-text script or configuration file.
Please excuse my ignorance, but what is the difference?
If the plain text file is only readable by the webserver account (and root), then the attacker still needs to obtain the webservers privileges (or root). Same as with Kerberos.
As far as I can tell, all you've done is put the credentials in a slightly more obfuscated format (a keytab file). Any security comes from restricting access to the credentials themselves.
OK it has some advantage in potentially confusing the stupider script kiddies, so it might not be totally pointless after all.
That's about 2 pages of config files! NO. Just NO. It's not even slightly correct. I have nothing against config files as such, but "hard coding" parameters that MUST be looked up dynamically is WRONG. You can't state "compatible with Active Directory" when it is clearly NOT COMPATIBLE.
Your complaint should be with whoever wrote that doc (just a random user reciting what worked for them) not with the software capabilities.
I have joined Ubuntu machines to AD domains without hardcoding much of that stuff at all.
eg krb5 can look up everything it needs (KDCs, realm names etc) in the DNS without needing a config file. The only reason to hardcode a realm in there is if you want a default one so you don't need to specify it in your login name.
In smb.conf, most of those hardcoded bits aren't required. I think realm is (not sure) but workgroup, netbios name, and password server aren't.
Nothing in pam or nss was hardcoded in that exmaple anyway.
Putting the domain name in the home directory path is optional.
The kinit step is also unnecessary.
So your three questions on Windows correlate nicely with the 3 things you need to tell samba.
1) realm name in smb.conf 2) user name to join with (in the net ads join command) 3) password (also part of the net ads join command)
Slashdot Mirror
On the plus side though, Ubuntu's package manager isn't too bad.
You don't mean XHTML 1.1 do you? That was just a modular version of XHTML 1.0 and as you say didn't offer much to make it worthwhile.
XHTML 2 was quite a radical change and in an ideal world would've been much better I reckon. The trouble was that the real world of legacy browsers and content was never going to manage the transition as it was too different (plus a big chicken and egg problem). So we've ended up with HTML 5, which although not as good as XHTML 2 (IMO) at least degrades gracefully in older browsers and manages the transition much more smoothly. Thus it actually has a good chance of being eventually adopted.
Ouch :)
Hand writing XSL:FO is extremely painful - very fiddly and the embedded layout/styling gets tedious quickly. It's kinda like writing a very very long webpage using HTML 3.2 with all the nasty old embedded presentation tags (but worse).
I have a feeling that is a bit backwards. The original standard was XSL and it was going to include everything related to transforms and publishing, but it got too large and complex so they split it into XSLT for the transforms and XSL:FO for the page description language. Much better that way, as XSLT has wider uses than publishing.
I think XSL:FO was always intended to be generated via XSLT rather than hand written, and I don't think that has changed at all. That way if you only need to a styling change, rather than making a zillion edits throughout the document you change the transform. It is analogous to how CSS make styling changes much easier with HTML.
Personally I'd rather use some other semantic format (eg Docbook, DITA etc) that can be transformed into XSL:FO via XSLT when required (eg on the way to PDF generation). That way you already get some handy XSLT starting points to work with. Making the occasional small tweak to XSLT isn't too bad, but writing a large complex set of transforms from scratch isn't something I'd want to do :)
That is already the case. CSS isn't just designed for HTML - it is designed to be able to be applied to any XML language also. Although XHTML is really the only common XML language where the user agents have implemented CSS rendering engines (they are very complex).
Do any web browsers handle applying CSS to arbitrary (but valid) XML files that aren't HTML?
Other layout options have been in the works for a long time, and it will still be a long time before browser support is ubiquitous.
CSS 3 has support for newspaper style text columns, and CSS 2.x allowed for laying out arbitrary elements using the same rules as various table elements - CSS 2 was released over 10 yrs ago, but IE only recently supported this part in IE 8.
CSS 3 has languished while everyone waited for widespread CSS 2.x support to actually happen. It seems like we'll just need legacy IE versions to die out before anyone bothers with progressing CSS 3 further. Hopefully it doesn't die on the vine the same way XHTML 1.1 or 2.0 did.
While popular music on the whole really really sucked during the 80's due to the marketing stranglehold of large record labels, it still produced a lot of great stuff that was less well known. Music diversified quite a lot during the 80s, but it wasn't until the 90s or later that the newer genres grew enough to be noticed by the mainstream. Unfortunately by then, much of it had lost some (or a lot) of its original creativity or got ruined by attempts by others to cash in on trends.
And as an aside New Order and The Stone Roses were still huge sellers (maybe not in the US though), and it's probably a stretch to say Nirvana was a Pixies ripoff rather than just being an influence.
Yep, I know and I wasn't really disagreeing with you :)
I was just messing around with the difference between what was "possible" and what was "practical".
It was still possible back then - in 83 turbocharged Formula One engines were limited to 1.5L :)
Most software isn't actually games. Shocking, I know.
And who really cares if a game crashes anyway?
Heh nice reference.
Seriously though, my brother did actually walk into Myanmar while he was backpacking with friends in Thailand. Just walked across some river on the border - they didn't hang around long though.
He didn't try swimming across a lake to rescue a princess... now that would be far fetched :)
Well the first domesticated dogs were wolves, and wolves are well known for their endurance. Maybe the the first dogs didn't resemble your Bichon Frise.
A few of the dogs I've known could still run all day too. One of ours would spend hours at a time sprinting at full speed up and down beaches chasing seagulls - I'm sure if he paced himself he could run all day quite easily.
One explanation: dogs were domesticated early on by hunter gatherers, and other animals came along later as settlements formed. Seems plausible to me.
OpenBSD does ship with services turned on though - eg OpenSSH and a few other mostly minor ones. But it is more than just exposed services - how many remotely exploitable kernel vulnerabilities have other systems patched over the last 10 yrs?
I'm no OpenBSD zealot (I'm mainly a Linux user), but OpenBSDs security track record and attention to detail is impressive. Quite often exploits in 3rd party code are mitigated or ineffective on OpenBSD due to measures they have taken.
It's not all roses though - keeping 3rd party apps patched on OpenBSD is harder than say Debian. They just don't have the resources to manage vast repositories like Linux distros do. Which is the big reason I will normally use Debian instead of OpenBSD.
I hear that a lot and they've done a lot of research into their methods, so I'm probably atypical and possibly just weird...
I've spent some time with the Design Patterns one and I struggle with it (I really want to like it). Sure it did OK with higher level stuff like "why" you want to use them (and "why not" too, which is important), and getting a vague idea of what each example did.
But whenever I try to grok the nitty gritty bits I keep getting too distracted to concentrate on any of the details. It seems like the print version of a web page filled with flashing and blinking ads where you have to piece together bits from all over the place. Sifting through all the preliminary "not-quite-correct" examples also gets in the way of understanding the "correct" one later on. I seem to expend too much energy evaluating the value of the distractions instead of learning.
I get a mild but tiring sense of disorientation with "Head First" books that I don't get elsewhere. I suspect I'm quite different to the average reader :)
Another factor is that with closed support, the visibility of the problem is hidden from Google even if it has been solved already. It all takes place over phone and email. So that combined with the typically less specific error messages you get with MS products means that troubleshooting them on Google is harder than it should be.
Yeah that's why I prefer to use a rock solid OS like OpenBSD... oh wait...
No, I'm not claiming Java isn't better than PHP, just that Java isn't more dynamic than PHP (as was claimed).
Although its probably true overall, I wasn't even claiming that Java devs are better overall than PHP devs, just that they tend focus more effort on architecture. Even to the point of going too far and over complicating things sometimes.
I'd even hazard a guess that being in a less dynamic environment requires them to put more effort into architecture. Compared to PHP it is much harder to "just make it up as you go along" in Java.
Flexible modular apps are possible in PHP if the developers design them like that though. Likewise a Java app that isn't designed to be flexible and modular won't be flexible and modular.
Nonsense.
What you are seeing that typically Java developers are more likely to be "architecture astronauts" and architect their apps towards componentisation etc sometimes at the expense of simplicity and clarity.
And typically PHP developers under-architect their apps and write them as kludgy non modular spaghetti code.
There is nothing more dynamic than PHP about Java itself - if anything it is the opposite. A lot of the common design patterns in Java are to get around the non dynamic nature of it, and I suspect it is this that makes Java devs far more conscious of architecture than PHP developers.
eg Drupal (PHP) has a very modular architecture and has thousands of plugin modules and has a culture that strongly discourages changing the core codebase. And whaddya know, a lot of the core devs are or have been Java developers and the founder even did a Phd in it.
Either way, if you want to use a pluggable component based architecture for your app you have to design it that way - the language won't do it for you.
Hehe you were going for Funny but I reckon the Insightful mod wasn't far off.
I would love it if I could patch my OpenBSD machines (incl 3rd party apps) with the same ease I patch my Debian machines.
He's talking about the RPM monopoly :)
Yep, that could work and you could even automate it to a degree.
But (for disaster recovery purposes) you've still got to be able to back up the KDC securely, so if you can do that you may as well just back up the webserver securely too :)
Although I suppose you could strip the passwords from the KDC backups, and recreate them all after a recovery too. For a site with mostly service principals (gah - I keep typoing that as "principles") it could be ok to automate, but lots of user principals would be a pain.
IMO there is a bit of a blind spot amongst typical Windows admins about how Kerberos works (I'm still somewhat hazy about it) because they are so shielded from it. Getting a *nix machine working with your AD via Kerberos is a very useful exercise as the internal workings are more exposed.
No, the question is what's difference in security between a text file only readable by the webserver account and a Kerberos keytab file only readable by the webserver account.
Wouldn't the same backup have the Kerberos keytab file in it? If the attacker gets the keytab, they can impersonate the webservers service principal (and any others stored in the same keytab) all they like.
Yeah, that's the security for the passwords stored in the KDC handled. But the attacker doesn't need to crack the KDC and get the password for the webservers service principal - they already have the keytab file containing the tickets for the service principal because it was in the backup.
That's why I don't (yet at least) see the difference between a DB user account password stored in a text file on the webserver, and storing a Kerberos ticket for a service principle in a keytab file on the webserver. Both methods rely on neither the webserver nor its backups getting compromised.
I know Active Directory doesn't use keytab files for the service accounts the same way Unix does, but the same kind of info contained in a keytab has to get registered and stored on the webserver somehow. It's part of becoming a domain member, and registering service accounts with services after entering the password of the service account when you configure the service.
Now for a secure option with Windows servers (I remember trying this out on NT4 back in the day so I presume it still can be done on later versions), there is/was a utility to encrypt enough about the servers SAM in such a way that the server needed a passphrase entered on the console or read from a floppy to decrypt them before it could carry on booting. That should solve the pilfered backup problem, but of course it is such a huge hassle when managing remote servers and applying services packs etc that I can't imagine it really being used much.
MS practically saved Apple from bankruptcy in the 90s by investing hundred of millions in them, and wrote a Mac version of Office and the default Mac browser for a while. Doesn't sound like they have wanted to crush Apple much at all.
MS realises that without Apple around, they are far more vulnerable to anti-trust problems. I'm sure MS are completely happy that Apples OS only officially works on exclusive hardware from Apple itself, that Apple keeps its nose out of the enterprise market, and MS can even make some money from Apple users. Apple is happy sticking to that market, and they don't pose much danger to MS unless they drastically change their business plan which is very unlikely.
Linux and FOSS on the other hand has the potential (however slight) to upset or disrupt the whole apple cart (no pun intended). MS isn't threatened by more expensive niche competition, but will fight anything that could undercut them or shift relevancy away from their platform (eg Netscape).
Please excuse my ignorance, but what is the difference?
If the plain text file is only readable by the webserver account (and root), then the attacker still needs to obtain the webservers privileges (or root). Same as with Kerberos.
As far as I can tell, all you've done is put the credentials in a slightly more obfuscated format (a keytab file). Any security comes from restricting access to the credentials themselves.
OK it has some advantage in potentially confusing the stupider script kiddies, so it might not be totally pointless after all.
Keep dreaming :)
Anyway for a $16,000 PC that is supposed to be for high performance I'd at least expect some SAS drives. 16 cores, 32GB RAM and SATA drives? Sheesh!
Your complaint should be with whoever wrote that doc (just a random user reciting what worked for them) not with the software capabilities.
I have joined Ubuntu machines to AD domains without hardcoding much of that stuff at all.
eg krb5 can look up everything it needs (KDCs, realm names etc) in the DNS without needing a config file. The only reason to hardcode a realm in there is if you want a default one so you don't need to specify it in your login name.
In smb.conf, most of those hardcoded bits aren't required. I think realm is (not sure) but workgroup, netbios name, and password server aren't.
Nothing in pam or nss was hardcoded in that exmaple anyway.
Putting the domain name in the home directory path is optional.
The kinit step is also unnecessary.
So your three questions on Windows correlate nicely with the 3 things you need to tell samba.
1) realm name in smb.conf
2) user name to join with (in the net ads join command)
3) password (also part of the net ads join command)