"
You can validate HTML just as easily as you can validate XHTML Do you even know what validation is? Validation is the act of checking a document against a DTD. It is not the process of authoring a document that contains no errors."
Er, yes? So? You can validate an SGML document against a DTD just as easily as an XML one, and you don't have to rely on browser hacks to make it work.
"Here's an exercise for you: write random garbage into a file and run it through the W3C validator. You have now validated the file."
If you insist:
"Sorry, I am unable to validate this document because on lines 1-5 it contained one or more bytes that I cannot interpret as utf-8"
So, your point is?
"
HTML gives the browser far more opportunity to render even malformed content, which frankly is a good thing for users.
It would be if authors and authoring tools didn't take advantage. But they do, leading to more widespread, yet more subtle errors that authors find harder to detect."
Such as? I've encountered a lot of broken HTML, and surprisingly little is in any way difficult to fix. It at least *works*; whether it's correct or not is the worry of the author, whether it works or not is the worry of users. You can just as easily write broken XHTML as HTML; that's exactly what happens, in fact -- most XHTML is just served as HTML and processed by browsers as broken HTML. Switch to application/xhtml+xml and watch as most XHTML based sites cease working and break randomly because 98% of them simply lack the intrastructure to guarantee they're emmiting correct XML. Do you think most sites use XML serializers and XSLT to generate content? I wish.
You just need to look at the sorry state of RSS to see that authors are very bad at getting things right; users don't care, though, they want their feed parser to work. As with browsers, I'd rather forgo strict syntax checks and have 99% of feeds actually be usable than be anal and put up with 25% or so. Sure, I'd much prefer to use a real XML parser everywhere and have everyone produce well formed markup even from their handwritten templates and PHPnuke hackjobs, but in the real world sites are designed and maintained by people who make mistakes or just don't care.
Isn't the mantra of interoperability "Be conservative in what you send and liberal in what you receive"? Since when did the Internet cease being a fault tolerant medium to communicate and become something that should break at the first trivial error?
XHTML is of course great if you *do* use XML serializers etc; you can both send it raw to supporting clients and know they're going to validate it properly and transform it to HTML for everyone else with a few lines of XSLT. Most sites simply to not fall into this category, and even those that do often get it wrong; how often have you seen code like:
It works most of the time, but it's wrong. Plenty of smart people have made this mistake, so why should we think the average web developer has a chance of getting it right?
Whatever your opinion, the original statement that CSS is useless without XHTML is wrong. I'd love to see what sort of logic brought it about:/
Try the XHTML 1.1 spec, which is the "purer" XHTML you really shouldn't be serving as text/html. XHTML 1.0 you kinda can treat as a bastardised HTML 4.01, but frankly I think it's an awful hack that should be avoided if possible. If you can do XHTML "properly", with the correct content-type, and transformations to HTML for older clients, 1.1 is probably the one you should be using.
Of course this doesn't apply for most sites using XHTML *mutter*.
I'll see if I can find a reference.. I think the idea is that because it's now just-another-XML-doctype, you should link in stylesheets the XML way, not the HTML way; you also get to use XML DOM instead of HTML DOM and stuff like that, so it may not actually be in the XHTML spec at all. I'm sure there are references to it dotted about though. I bothered to do it, so I must have read it somewhere with a bit of clout:)
You can validate HTML just as easily as you can validate XHTML; attributes such as alt are just as required, and entities have strict rules you need to follow to validate.
The difference is if you get this stuff wrong in XHTML, the browser won't render it at all (although none of them actually validate, so you're only checking well-formedness here; missing an alt won't do much); HTML gives the browser far more opportunity to render even malformed content, which frankly is a good thing for users.
I have a PocketPC too, btw; I'd be surprised if any of the browsers on it actually bother treating XHTML any differently to HTML; MSIE6 certainly doesn't, and with good reason -- very few sites actually bother sending proper XML/XHTML content types, and XHTML is close enough to HTML that you can just process it as such anyway. Let's test this assertion:
Ok, PocketIE sends Accept: */*; trying to send it XHTML results in it trying to download as a binary. This is about on par with IE on WinXP, so...
ThunderHawk's Accept: header excitingly includes XML and XHTML, but also tries to download when it actually gets sent some with the proper content-type. Duh.
NetFront's Accept: header includes a bunch of image formats and the ever-moronic */*. Sending it XHTML results in a loss of CSS since it seems to lack support for <?xml-stylesheet ?>, reminding me of an old Opera bug. At least it works, and frankly unstyled sites look better on small displays.
HTML works fine on all three browsers; so much for your claims that XHTML actually *helps* you view sites. It might *work* when you send XHTML (incorrectly) as text/html, but only because browsers are very forgiving at parsing HTML.
Thanks for actually getting me to test this.. I feel quite disappointed now:/
there is no point using CSS without using XHTML, IMHO.
If you can come up with a single persuasive reason why anyone should use XHTML 1.0 over HTML 4.01 I'll be impressed. The standards are practically identical, except XHTML introduces concerns over stylesheet linking (you should be using <?xml-stylesheet.. ?> rather than <link>), content type (application/xhtml+xml, *not* text/html), content negotiation (client doesn't report XHTML support in Accept:? The right thing to do is to send it.. HTML 4!), breaking browsers which properly support HTML+SGML (you know <br/> means something completely different in HTML, right?), and an almost complete lack of support in IE (what's there is is mainly a hack, just like serving XHTML as text/html to more powerful browsers).
The only compelling reason I can think of is that XML's nicer to parse (might as well provide an Atom feed or so rather than encourage parsing your XHTML) and has a bunch of nasty API's and languages to manipulate it (DOM, XSLT, etc). Be honest; how many sites actually use an XSLT pipeline to generate content? Those that do can either just emit HTML (which XSLT supports anyway), or really should add the extra complication to do either; XHTML only doesn't make a lot of sense.
And yes, I got on The X-Philes, and was once the only site on there which actually linked stylesheets in properly. I can't say it was worth it beyond sheer geek appeal*
* (Which means I'll probably do it again in future sites, bah;)
Yes, you can put 4 Opterons in 1U, but 1U servers tend to be loaded with squillions of expensive and high power fans; noise isn't a major concideration when it comes to rackmount.
I still suspect you could do pretty well with low power Opterons in a small workstation case, but don't be suggesting that a quad 1U Opteron is going to be anything but LOUD; I'd be disappointed if not -- a rackmount server should be well ventilated and have plenty of redundancy, not be quiet and running anywhere near it's thermal limits.
I am a bit concerned about "proprietary form factor" though; what's wrong with the existing standards?:(
A 50% speed boost isn't *that* much; The Python JIT runtime that was on SlashDot just a few weeks ago cited significantly higher increases in performance. Fast, yes, but I'm not amazed or anything here:)
foobar2000 uses APEv2 tags on MP3's by default; the standard's just as flexible (well, as much as anyone wants anyway), but, well, you just need to compare filesizes for their handlers; an ID3v2 reader/writer I saw was ~150k of code -- the APEv2 one was 15k. They're always at the end, but obviously since fb2k is the only player I'm aware of which supports it the appeal may be limited. You can at least mix them with ID3v1, which should be good enough for portables.
And before anyone goes off on one because it's non-standard, I'll point out that MP3 has *no* provision for metadata. ID3v1 and 2's are just as arbitary addons as APEv2; they're just older (and lamer, either in big limitations or extreme overcomplication).
I believe the recommended *standard* way of attaching metadata to an MP3 now is to put it in an MP4 container, which has it's own more sensible format. Again, I'm pretty sure foobar2000 (maybe with some plugin in the Special Installer) can put them in, and I think they should play on anything which knows about MP4. Fully reversable too.
ISTR some distributed project to calculate md5 hash collisions; the idea being that once you've calculated 2^64 md5's or so, you start getting lots of them, and as they get demonstratably easier to break... uh... well, I guess then we might actually start using SHA1 in more than a handful of places;)
OpenSSL can act as an md5(1) replacement using SHA1 btw; iirc you can just symlink it to a file called sha1, and use it like a normal BSD md5:)
I have two SMP systems (not counting 5 servers, *cough*); dual PPGA Celerons (BP6 \o/). At the time they didn't cost significantly more than a uniprocessor system, and provided a big boost in responsiveness over other similarly priced systems.
Hopefully dual core will help reduce the view that SMP == server. SMP does a great job making any system smoother, and unless you really need all that power in one CPU it doesn't have to cost much more than a uniprocessor system (it might do *NOW*, it doesn't mean it has to).
As for the heat, aren't these 65nm chips? Sure, it'll be significant, but I'm sure it'll be managable. Mmmm, might be an idea to buy stocks in copper;)
Opera includes a load of user togglable CSS files which do things like setting high contrast colours, simplifying layouts and such. It also zooms images as well as text. While Firefox is good, you might like to mention a browser which includes features specifically designed for this target audience.
(Note this doesn't work properly in IE; not at all if you specify fonts in pixels, and they get the scaling factor wrong if you use em. Percents should do the right thing though)
mod_fastcgi should be thread safe, and the FastCGI PHP SAPI module is probably better tested than the Apache 2 ones. Plus, if PHP crashes it doesn't take Apache with it, and you can do fancy things like jailing the daemonized PHP's, or running multiple servers as different users.
Same here, Barton 2500+ running at 3200+; a real 3200+ would cost at least twice as much for the 20% or so performance boost you get out of it. I have no significant issues with heat, and stability is top-notch. Worth it for me:)
A binary can choose different code paths to follow based on the CPU it's running on; games do it all the time.
Did you see this latest Python JIT-alike btw? I think it was on SlashDot not long ago.. ah, Psyco. Shame I don't like Python, but it makes for a nice proof-of-concept to show that high level and dynamic doesn't have to mean slow (as if SmallTalk and friends haven't already done that).
Try using a system which doesn't kill each service one by one in a serial manner; the difference between shutdown speed in, say, Slackware or FreeBSD compared with RedHat and friends is quite significant. You'll have to learn to live without the fancy green [OK]'s though:)
It's "Linux", dude. Just as it's "Perl", only more so because it doesn't even have an after-the-fact acronym tagged on to it. Part of keeping it viable is it's users being able to type it's name correctly;)
It's going to take longer than it should; that's bad, whichever way you look at it. If people didn't care about waiting a while for things to happen they wouldn't get broadband connections, multi-GHz CPU's and 40x+ CF cards.
Having said that, CF card readers aren't exactly expensive, and I guess you can always swap the cards about; people seem to manage with CD's and minidisks, although it's not such a big deal if you lose a CD-R compared to an 80UKP CF card;)
Vorbis support is good for low bitrates anyway; you get make perfectly good -q-1 (that's quality level minus one; ~60kbps) encodes which will sound fine in the cheapo headphones you'll be using outside. The only problem is most of these "Vorbis capable" players have very limited abilities to do so; low bitrate Vorbis requires more memory to decode, and higher bitrates obviously need more processing, so they tend to only support low-midrange bitrates, and not the useful fairly high and very low ones which are what make Vorbis useful to me:/
Blegh, wake me up when I can get an 80G player which plays FLAC. In fact, don't bother; I'd rather have a palmtop computer which can just run foobar2000 or so, and be useful for other things too. If you can make it into a decent ultra compact digital camera and a mobile phone as well that would be just great;)
Note they assume 900kbps for lossless though, which is a bit pessimistic. I'm just downloading my 5th album from them though, with no complaints, aside from the lack of tags. Their download tool properly names them though, and foobar2000's masstagger takes care of the rest \o/
While I agree that security is important, I'd be dubious as to the effectiveness of your password policy. Changing every 60 days is going to mean fewer users bothering to memorize their password; they'll just write them down because, well, they'd have to remember another one in a few weeks anyway! And why the limit of 12 characters? Don't you like passphrases?
If you're really worried about passwords being cracked, you should do so yourself first; weed out the weak passwords early by running john on a spare machine or so. Once you get past the obviously weak ones, you're more likely to have problems with users writing them down or giving them to people.
The entire point of Open and Free software is you're not limited to one system; you can modify and tinker and port to your heart's content. A licensed binary-only player for Linux isn't going to help me play DVDs on FreeBSD, or even Linux itself when I go AMD64 or PPC or ARM.
Like region coding, I see CSS as an attempt to block my ability to play back something I've legitimately paid for; *THAT* should be illegal, not my attempts to work around it. It's just a shame I don't have billions of pounds to back my argument.
I see 99c per song as a complete rip-off; why would I pay 99c for a DRM restricted low bitrate AAC? If I were getting DRM free lossless files then yes, that's pretty good, but I'm not. Other services seem to do just fine selling lossless DRM free files alongside lossy DRM free files with similar if not better pricing structures, so iTunes can bite me. Plus I'm in the UK; I don't think I'm allowed to use iTunes.
Most modern optical drives have AccurateStream, which afaik nullifies this problem. What you're left with is the offset to start reading from, which you need to check with key disks who's offsets are known if you don't know the offset for your drive. Not doing this *will* result in your ripped tracks having parts truncated or prepended, whether you can tell or not. AccurateRip is a good tool to do this, since it checks checksums from your ripped data with those other users have uploaded.
Slashdot Mirror
Er, yes? So? You can validate an SGML document against a DTD just as easily as an XML one, and you don't have to rely on browser hacks to make it work.
If you insist:
"Sorry, I am unable to validate this document because on lines 1-5 it contained one or more bytes that I cannot interpret as utf-8"
So, your point is?
Such as? I've encountered a lot of broken HTML, and surprisingly little is in any way difficult to fix. It at least *works*; whether it's correct or not is the worry of the author, whether it works or not is the worry of users. You can just as easily write broken XHTML as HTML; that's exactly what happens, in fact -- most XHTML is just served as HTML and processed by browsers as broken HTML. Switch to application/xhtml+xml and watch as most XHTML based sites cease working and break randomly because 98% of them simply lack the intrastructure to guarantee they're emmiting correct XML. Do you think most sites use XML serializers and XSLT to generate content? I wish.
You just need to look at the sorry state of RSS to see that authors are very bad at getting things right; users don't care, though, they want their feed parser to work. As with browsers, I'd rather forgo strict syntax checks and have 99% of feeds actually be usable than be anal and put up with 25% or so. Sure, I'd much prefer to use a real XML parser everywhere and have everyone produce well formed markup even from their handwritten templates and PHPnuke hackjobs, but in the real world sites are designed and maintained by people who make mistakes or just don't care.
Isn't the mantra of interoperability "Be conservative in what you send and liberal in what you receive"? Since when did the Internet cease being a fault tolerant medium to communicate and become something that should break at the first trivial error?
XHTML is of course great if you *do* use XML serializers etc; you can both send it raw to supporting clients and know they're going to validate it properly and transform it to HTML for everyone else with a few lines of XSLT. Most sites simply to not fall into this category, and even those that do often get it wrong; how often have you seen code like:It works most of the time, but it's wrong. Plenty of smart people have made this mistake, so why should we think the average web developer has a chance of getting it right?
Whatever your opinion, the original statement that CSS is useless without XHTML is wrong. I'd love to see what sort of logic brought it about
Try the XHTML 1.1 spec, which is the "purer" XHTML you really shouldn't be serving as text/html. XHTML 1.0 you kinda can treat as a bastardised HTML 4.01, but frankly I think it's an awful hack that should be avoided if possible. If you can do XHTML "properly", with the correct content-type, and transformations to HTML for older clients, 1.1 is probably the one you should be using.
:)
Of course this doesn't apply for most sites using XHTML *mutter*.
I'll see if I can find a reference.. I think the idea is that because it's now just-another-XML-doctype, you should link in stylesheets the XML way, not the HTML way; you also get to use XML DOM instead of HTML DOM and stuff like that, so it may not actually be in the XHTML spec at all. I'm sure there are references to it dotted about though. I bothered to do it, so I must have read it somewhere with a bit of clout
You can validate HTML just as easily as you can validate XHTML; attributes such as alt are just as required, and entities have strict rules you need to follow to validate.
:/
The difference is if you get this stuff wrong in XHTML, the browser won't render it at all (although none of them actually validate, so you're only checking well-formedness here; missing an alt won't do much); HTML gives the browser far more opportunity to render even malformed content, which frankly is a good thing for users.
I have a PocketPC too, btw; I'd be surprised if any of the browsers on it actually bother treating XHTML any differently to HTML; MSIE6 certainly doesn't, and with good reason -- very few sites actually bother sending proper XML/XHTML content types, and XHTML is close enough to HTML that you can just process it as such anyway. Let's test this assertion:
Ok, PocketIE sends Accept: */*; trying to send it XHTML results in it trying to download as a binary. This is about on par with IE on WinXP, so...
ThunderHawk's Accept: header excitingly includes XML and XHTML, but also tries to download when it actually gets sent some with the proper content-type. Duh.
NetFront's Accept: header includes a bunch of image formats and the ever-moronic */*. Sending it XHTML results in a loss of CSS since it seems to lack support for <?xml-stylesheet ?>, reminding me of an old Opera bug. At least it works, and frankly unstyled sites look better on small displays.
HTML works fine on all three browsers; so much for your claims that XHTML actually *helps* you view sites. It might *work* when you send XHTML (incorrectly) as text/html, but only because browsers are very forgiving at parsing HTML.
Thanks for actually getting me to test this.. I feel quite disappointed now
If you can come up with a single persuasive reason why anyone should use XHTML 1.0 over HTML 4.01 I'll be impressed. The standards are practically identical, except XHTML introduces concerns over stylesheet linking (you should be using <?xml-stylesheet
The only compelling reason I can think of is that XML's nicer to parse (might as well provide an Atom feed or so rather than encourage parsing your XHTML) and has a bunch of nasty API's and languages to manipulate it (DOM, XSLT, etc). Be honest; how many sites actually use an XSLT pipeline to generate content? Those that do can either just emit HTML (which XSLT supports anyway), or really should add the extra complication to do either; XHTML only doesn't make a lot of sense.
And yes, I got on The X-Philes, and was once the only site on there which actually linked stylesheets in properly. I can't say it was worth it beyond sheer geek appeal*
* (Which means I'll probably do it again in future sites, bah
Yes, you can put 4 Opterons in 1U, but 1U servers tend to be loaded with squillions of expensive and high power fans; noise isn't a major concideration when it comes to rackmount.
:(
I still suspect you could do pretty well with low power Opterons in a small workstation case, but don't be suggesting that a quad 1U Opteron is going to be anything but LOUD; I'd be disappointed if not -- a rackmount server should be well ventilated and have plenty of redundancy, not be quiet and running anywhere near it's thermal limits.
I am a bit concerned about "proprietary form factor" though; what's wrong with the existing standards?
Thunderhawk has an expensive subscription based license as far as I can tell; it's also doesn't seem to like scrolling, at least on my iPAQ 2210.
Just had a look at Netfront; it doesn't seem to support a sideways display like Thunderhawk, which is a shame.
A 50% speed boost isn't *that* much; The Python JIT runtime that was on SlashDot just a few weeks ago cited significantly higher increases in performance. Fast, yes, but I'm not amazed or anything here :)
Yes, but those of us with BSD systems have no such tools by default. Besides, BSD md5 is nicer than the GNU one ;)
:)
(I can qualify that remark, but let's not
foobar2000 uses APEv2 tags on MP3's by default; the standard's just as flexible (well, as much as anyone wants anyway), but, well, you just need to compare filesizes for their handlers; an ID3v2 reader/writer I saw was ~150k of code -- the APEv2 one was 15k. They're always at the end, but obviously since fb2k is the only player I'm aware of which supports it the appeal may be limited. You can at least mix them with ID3v1, which should be good enough for portables.
And before anyone goes off on one because it's non-standard, I'll point out that MP3 has *no* provision for metadata. ID3v1 and 2's are just as arbitary addons as APEv2; they're just older (and lamer, either in big limitations or extreme overcomplication).
I believe the recommended *standard* way of attaching metadata to an MP3 now is to put it in an MP4 container, which has it's own more sensible format. Again, I'm pretty sure foobar2000 (maybe with some plugin in the Special Installer) can put them in, and I think they should play on anything which knows about MP4. Fully reversable too.
ISTR some distributed project to calculate md5 hash collisions; the idea being that once you've calculated 2^64 md5's or so, you start getting lots of them, and as they get demonstratably easier to break... uh... well, I guess then we might actually start using SHA1 in more than a handful of places ;)
:)
OpenSSL can act as an md5(1) replacement using SHA1 btw; iirc you can just symlink it to a file called sha1, and use it like a normal BSD md5
This is hydrogenaudio; it's MusePack all the way, and with good(ish) reason :)
Not really at this low bitrate though.. 128kbps, ugh!
I have two SMP systems (not counting 5 servers, *cough*); dual PPGA Celerons (BP6 \o/). At the time they didn't cost significantly more than a uniprocessor system, and provided a big boost in responsiveness over other similarly priced systems.
;)
Hopefully dual core will help reduce the view that SMP == server. SMP does a great job making any system smoother, and unless you really need all that power in one CPU it doesn't have to cost much more than a uniprocessor system (it might do *NOW*, it doesn't mean it has to).
As for the heat, aren't these 65nm chips? Sure, it'll be significant, but I'm sure it'll be managable. Mmmm, might be an idea to buy stocks in copper
Opera includes a load of user togglable CSS files which do things like setting high contrast colours, simplifying layouts and such. It also zooms images as well as text. While Firefox is good, you might like to mention a browser which includes features specifically designed for this target audience.
(Note this doesn't work properly in IE; not at all if you specify fonts in pixels, and they get the scaling factor wrong if you use em. Percents should do the right thing though)
mod_fastcgi should be thread safe, and the FastCGI PHP SAPI module is probably better tested than the Apache 2 ones. Plus, if PHP crashes it doesn't take Apache with it, and you can do fancy things like jailing the daemonized PHP's, or running multiple servers as different users.
Same here, Barton 2500+ running at 3200+; a real 3200+ would cost at least twice as much for the 20% or so performance boost you get out of it. I have no significant issues with heat, and stability is top-notch. Worth it for me :)
A binary can choose different code paths to follow based on the CPU it's running on; games do it all the time.
Did you see this latest Python JIT-alike btw? I think it was on SlashDot not long ago.. ah, Psyco. Shame I don't like Python, but it makes for a nice proof-of-concept to show that high level and dynamic doesn't have to mean slow (as if SmallTalk and friends haven't already done that).
Try using a system which doesn't kill each service one by one in a serial manner; the difference between shutdown speed in, say, Slackware or FreeBSD compared with RedHat and friends is quite significant. You'll have to learn to live without the fancy green [OK]'s though :)
It's "Linux", dude. Just as it's "Perl", only more so because it doesn't even have an after-the-fact acronym tagged on to it. Part of keeping it viable is it's users being able to type it's name correctly ;)
It's going to take longer than it should; that's bad, whichever way you look at it. If people didn't care about waiting a while for things to happen they wouldn't get broadband connections, multi-GHz CPU's and 40x+ CF cards.
;)
:/
;)
Having said that, CF card readers aren't exactly expensive, and I guess you can always swap the cards about; people seem to manage with CD's and minidisks, although it's not such a big deal if you lose a CD-R compared to an 80UKP CF card
Vorbis support is good for low bitrates anyway; you get make perfectly good -q-1 (that's quality level minus one; ~60kbps) encodes which will sound fine in the cheapo headphones you'll be using outside. The only problem is most of these "Vorbis capable" players have very limited abilities to do so; low bitrate Vorbis requires more memory to decode, and higher bitrates obviously need more processing, so they tend to only support low-midrange bitrates, and not the useful fairly high and very low ones which are what make Vorbis useful to me
Blegh, wake me up when I can get an 80G player which plays FLAC. In fact, don't bother; I'd rather have a palmtop computer which can just run foobar2000 or so, and be useful for other things too. If you can make it into a decent ultra compact digital camera and a mobile phone as well that would be just great
Note they assume 900kbps for lossless though, which is a bit pessimistic. I'm just downloading my 5th album from them though, with no complaints, aside from the lack of tags. Their download tool properly names them though, and foobar2000's masstagger takes care of the rest \o/
While I agree that security is important, I'd be dubious as to the effectiveness of your password policy. Changing every 60 days is going to mean fewer users bothering to memorize their password; they'll just write them down because, well, they'd have to remember another one in a few weeks anyway! And why the limit of 12 characters? Don't you like passphrases?
If you're really worried about passwords being cracked, you should do so yourself first; weed out the weak passwords early by running john on a spare machine or so. Once you get past the obviously weak ones, you're more likely to have problems with users writing them down or giving them to people.
The entire point of Open and Free software is you're not limited to one system; you can modify and tinker and port to your heart's content. A licensed binary-only player for Linux isn't going to help me play DVDs on FreeBSD, or even Linux itself when I go AMD64 or PPC or ARM.
Like region coding, I see CSS as an attempt to block my ability to play back something I've legitimately paid for; *THAT* should be illegal, not my attempts to work around it. It's just a shame I don't have billions of pounds to back my argument.
I see 99c per song as a complete rip-off; why would I pay 99c for a DRM restricted low bitrate AAC? If I were getting DRM free lossless files then yes, that's pretty good, but I'm not. Other services seem to do just fine selling lossless DRM free files alongside lossy DRM free files with similar if not better pricing structures, so iTunes can bite me. Plus I'm in the UK; I don't think I'm allowed to use iTunes.
Most modern optical drives have AccurateStream, which afaik nullifies this problem. What you're left with is the offset to start reading from, which you need to check with key disks who's offsets are known if you don't know the offset for your drive. Not doing this *will* result in your ripped tracks having parts truncated or prepended, whether you can tell or not. AccurateRip is a good tool to do this, since it checks checksums from your ripped data with those other users have uploaded.