Are you seriously suggesting that XML's error handling is ideal - that the correct way, after 17 years of accepting non-perfect content in web browsers is to inform readers of a page that a href attribute that contains an & that's not part of an entity like & that the page is broken and then quit without showing any information? XML is awesome for programs reading data produced by other programs. Draconian error-handling is appropriate in such scenarios. However, way too many people are hand-writing HTML - and it's way too hard to generate sensible HTML - to be able to make that plausible.
HTML5 defines and codifies separate HTML parsing rules, mostly backwards-compatible. You're able to download a HTML5 package and parse almost any site on the web today - are you willing to bet you can do that with half the XHTML pages? (Even if you still want to use XML, you can just write XHTML5, which is HTML5 with XML parsing.)
WHATWG's two specs specify both the HTML markup and the DOM. The two go hand in hand - that's why it in comparison to HTML 4.01 or even XHTML 2 looks like a "mish-mash of markup and javascript", because it's just not solely a markup spec anymore. If there's going to be a new HTML spec, it deserves to be a solid and holistic spec. The least you can do is include the DOM model inline, and not just publish a different spec, by a different working group, and brand it as "DOM HTML Extensions", or what have you.
I agree. This would be tremendously useful and even enable the true kind of table-like column layouts we've been wanting (not just text flowing into other boxes like CSS3 columns). Something like:
#column1 {/* Assume this exists */ } /* Assume a function, of, that takes two arguments, the name of the property and the selector, and another function, own, that takes the name of the property and works on its own rule. */ #column2 { width: (of(width, body) - of(width, #column1) - (own(padding)*2)); height: of(height, #column1); padding: 0.5em; }
Point versions would be a silly place to start supporting a major new standard. Usually it takes two or three versions to approach what could be called reasonably full compliance, depending on how 'major version' hungry you are (Mozilla Suite - by that name, yes, I know Seamonkey exists - was abandoned around 1.7 or 1.8).
I don't think the goal is "expose the personal details of everyone". I think the goal is "for everyone paid to write something, make them write that they *were* paid to write something or they won't get their money".
I still think writing what they're told in exchange for a check is ridiculous, but at least now you'd know which ones were paid. (Or, rather, you'd know which ones were written by people getting paid by companies who demanded they write that.) In any event, disclosing that you're getting paid does nothing to erode anonymity.
Re:ze frank: sad, but typical
on
Ze End of The Show
·
· Score: 4, Informative
[W]e should all really care about why ze frank stopped the show. ze frank was a perfect example of a slick little gem of a performance idea that had legs. If it died because ze frank just got tired, well, OK. But if it died because it didn't ever have a hope of turning into something that sustained ze, then we should all be concerned and try to figure out why.
It 'died' because Ze had his mind set from very early on to run it for a full year. I'm not going to tell you Ze didn't want to continue. It seems fairly obvious to me that he wanted to.
A recent article said Ze's got some kind of gig in Tinseltown now. I have no idea what exactly it is, or if he's a producer or writer or performer, but there are two basic outcomes: He falls victim of dramatic Hollywoodization, or he keeps going, doing his own tremendous thing, bringing his stuff more or less to the masses. I know what I'm rooting for.
Yes, I rarely consider using anything else than BSD, MIT or public domain for my projects if I can help it, and I know that I "enjoy the practical benefits of freedom" and can help others. That was my point. My point was that I wasn't *forced* to do so by the terms of my license.
If you had to accurately represent the concept of open source every time you said something involving it, you wouldn't be in a free market, you'd be in a controlled market. In a controlled market, there's less of a chance that people could be assholes, but there's also less freedom. I don't think it's awesome that there are people who misrepresent it, but I do think it's great that there's people pushing for poetic justice and calling those people on their bluffs.
Not really, since there are plenty of actual open source developers - like yours truly - that don't want to subscribe to the militia-style enforced 'freedom' preservation, but who do want the pragmatic benefits of making source available and helping others. As many people have commented, open source has its own definition - that it was ever simply a 'mispronouncement' of Free Software and doesn't thrive on its own merit is bullshit. (Yes, even if some people will write 'open source' when you tell them to write 'Free Software'.)
That's not to say that there aren't people that misrepresent the concept of "open source" to gain benefits or goodwill. If this surprises you, welcome to the free market as driven by humans.
The real problem with the iPhone is its strengths. No, I'm not being facetious. Look at it.
Some of the iPhone's strengths are the high resolution screen (160dpi), Multi-touch and OS X - ie their own operating system. Do you want to run a keypad-based Java game on the iPhone? There's no tactile feedback for what I presume would be an on-screen keypad for controlling the thing, and the program itself would be downright piddly on a higher resolution display than is normal. Squint city, I tell you. Not to mention that since Apple is using their own OS, they'd need to implement Java ME on it, maintain not only feature compatibility but bug compatibility, and regularly check with new programs to make sure they all run. That's a tall order even if the end result was going to be as good as Java on any other phone (it won't) and Apple were motivated to make it happen (they aren't). In short: Java midlets, even if perfectly implemented, would look small, not feel natural to control and not actually take advantage of any of the features. If you live and die by those exact Java apps, you would be better off buying another phone.
Like with any phone, I do want third-party software, but unlike any other phone, I want software written for the iPhone specifically. Anything else wouldn't work. You wouldn't be able to take advantage of multi-touch to zoom or scroll easily. My desire for the iPhone is hampered by Apple's 'closed box' stance, since extra apps are more important on a smartphone than on an MP3 player, but I am optimistic that Apple will come to their senses eventually and allow more open third party development.
The iPhone's got two wild cards. The first is that the shipping apps seem to actually not suck since they've been spending years building mail clients and web browsers on their own on the desktop before. Bundled cell phone software tends to suck, and the iPhone software looks like it's actually been designed more than thrown together. The second wild card is call management. You mean there are big, fat, easily pressed and clearly labelled buttons on the screen I can push to merge calls or put people on hold instead of needing to push codes via the key pad? I guess I'll excuse the traditional cell phone creators for not coming up with that, though. Most have had a piddly 20 years or so to come up with that.
Didn't they change the Store to make it add DRM when PyMusique got out? (Because as you say, PyMusique didn't add (and couldn't reasonably have added) DRM after downloading songs.)
That said, I'm not buying the "fool into thinking it's DRM-less". First of all, Apple serves up DRM-less music *today* with the iTunes U (U for University) program where they host AAC files of lectures. Now that this is all done of the server, getting that changed would be either a wide-open hole in the code OR getting into the database and changing, say, hasDRM from 1 to 0. If either of those holes are there, you could do much worse than remove DRM.
I do believe that since the Big Four labels were on first and got to dictate that they absolutely needed DRM, it wouldn't be beyond them to say "and don't let anyone else serve up DRM-less music from iTunes". After all, when iTunes offers only DRM-ed music, Apple looks bad; if iTunes offered non-DRM-ed music from a bunch of artists but not from the Big Fours, the Big Four would look bad. And we know which one the Big Four would prefer.
- Imagine perpetual copyrights and no public domain. While, at the same time, artists are forced to hand over their right to control what happens to their work.
I never said that, did I.
How else than by making everyone waive their rights to the music will you be able to concentrate everything to a single vendor? Because if people have any say in it, out of *the creators of all the music ever* there will definitely be two artists who don't want to be with the same vendor, or that want to create their own. And if everything will be there and it's going to be convenient for customers, there's going to be liberal usage rights, and there's probably one or two artists that want more control over their own stuff than that, too.
I'd definitely enjoy renting the music from the single reliable, full-stock and honest source you're describing, but that's not to say that it'd be practically possible. Way over the horizon. Handwaving to counter the real argument. How about describing DRM as it applies to today's situation rather than in the Republic of Imaginary Perfect Bliss? (Population: speculative.)
Uh. Correction. Minus: "Correct: no piece of complex software (and almost no pieces of easy software as well) contain bugs." Plus: "Correct: no piece of complex software (and almost no pieces of easy software as well) are free of bugs."
Correct: it is a workaround offered by a user, and surely firmware updates will straighten things out. Correct: no piece of complex software (and almost no pieces of easy software as well) contain bugs. My confidence in Apple to provide an upgrade to the problem has nothing to do with the fact that it is a problem now, and that the workaround - offered by Apple or not - is crap when compared to a real fix.
My comment's parent was arguing that vending a computer directly to the Internet is acceptable and even to be preferred instead of "having to hide behind some shitty, ineffective firewall". Then he got started on Mac OS X's security record, which really has nothing to do with anything other than, in effect, making the workaround a little less horrible. He got labelled a Troll, and that seems fairly accurate.
I am not trying to tell Apple they suck - and believe you me, I would if *they* offered the workaround as a permanent solution, which they assuredly won't. I'm saying that embracing the workaround as somehow a better state of affairs than a functional solution (see, again, my comment's parent) is foolish.
"The issue seems to be that, without setting your computer as the DMZ in the base station settings, you can't establish a VPN connection with an external VPN server from your computer."
No, the issue is that without this workaround, you can't connect one specific VPN client (Nortel Contivity) to an external VPN server.
That was exactly what I said, unless you can parse that sentence another way. (I probably should have said "you can't establish a VPN connection to an external VPN server" instead of "with".) Computer has a VPN client, tries to connect to VPN server outside the internal network, the connection doesn't go through the base station. Computer is set to DMZ, connection does go through.
The issue seems to be that, without setting your computer as the DMZ in the base station settings, you can't establish a VPN connection with an external VPN server from your computer.
That doesn't change the fact that you shouldn't have to put it in the DMZ in the first place. It's a horrible workaround from a security point-of-view, and it's not even practical - if you have two computers inside that want to use a VPN, you're screwed because you can't have two "default hosts".
Even if Mac OS X was twice as secure as it is - and yes, I'm one of them who thinks that outside of bugs and vulnerabilities that almost every piece of software has (unless it was developed by either NASA or djb), it's reasonably secure because it was designed to be more secure, not just because it enjoys less market share - that still wouldn't be a justification for an obvious bug in the base station's firmware. It's a lucky circumstance that may function as a workaround, but there's no way it actually qualifies as an acceptable solution to anything.
Just to clarify, I said 95-thru-Me BSOD not to imply that they were the only ones with BSODs, but because they BSODed much more frequently due to errors that won't bring down an NT-based Windows setup. Personally, I've seen both BSODs in Windows 2000 and in Windows XP (and far more in 2000 than in XP, despite using XP quite a bit more).
I never understood the unabashed Clippy hatred. It was certainly a more friendly window to the whole help interface since it's much easier for a novice to ask a question than rummage through indices. It was one checkbox to turn the little bugger off, and you could choose something that you thought was less annoying if that was the problem. (I've almost always used the dog.) Not to mention that he's being going away more and more the past few versions: "It looks like you are writing a letter" is becoming about as relevant as the 95-thru-Me era BSOD.
I agree with the new notions that the Office user interface team has chosen to adopt, like only being able to access a feature from one place. Jensen Harris is a smart guy and I've been enjoying reading his weblog and the trials and tribulations of the Ribbon and the new UI as a whole.
Vista has been coming forever, the shipping version already shipped for some before the turn of the year. Apple is entirely to blame for not pre-emptively putting out 7.0.3 to fix these things, because boy have they had the time to do so. They *have* put out a fix by now for part of the problems, but it's not an iTunes update, and Vista may have botched these things, but it's not like they haven't had time or opportunity to fix them.
I do like Apple and I do like iTunes, but this is the same arrogant flank of the company that told you they were mad at Microsoft because Windows wasn't secure enough when they accidently shipped a batch of iPods with a Windows virus on the hard drive.
Apple's stuff has the distinct feel of being written by a few very select programmers. Microsoft's stuff has the distinct feel of being forced together from many disparate pieces none of which quite work the same way. If Microsoft is going to compete they are basically going to have to fire most of their employees. The problem is, you're already seeing the good ones start to leave for greener pastures.
This is really interesting. Apple *has* several teams since they also have Carbon and their own Java runtime. The Java team has obviously got their agenda set, but not much is happening with Carbon. Jens Alfke, an Apple engineer, was knee-deep in the Java runtime for some time but defected to another team and wrote the iChat prototype after just one week of internal Cocoa training. Not to mention that around the time when the plans for Mac OS X were made public, they said they'd just use their Java port of QuickTime, and now they're rewriting basic layers in Objective-C to be eased in with 64-bit (where the old versions are not ported). Apple was very unsure of Cocoa when they first acquired it as the OpenStep APIs, and now it's one of the company's most valuable software possessions.
And Microsoft, of course... Microsoft seems to have very happy and genuinely enthusiastic developers. This isn't their problem, it's one of cobbling together something coherent with that many people, and being under the onus of needing to provide "Enterprise stuff" - expensive but unneeded and acronym-heavy solutions, all regularly updated to new, wildly incompatible versions at the drop of a hat to keep it 'fresh' for CIOs. (Uh. Not that I'm bitter.)
As someone who develops in Cocoa and.NET (but who, admittedly, is writing this on a MacBook), I have to say that Cocoa is not *that* far ahead of.NET. If you're the hairy-chest C++ strongly typed unsigned volatile sealed abstract interface kind of programmer, you'll definitely like.NET more than Cocoa.
The difference it'd take me to develop an application in Cocoa and in.NET is negligible - they both are pretty good. I get around faster in Cocoa, but until 10.5 comes out (and in reality for about two years after that as well), I'll have to do manual memory management. As for.NET, that framework has more symbols than, well, all of Unicode.;)
Cocoa started out smaller, has grown more carefully and is as a result reasonably mature and fairly easy to get your head around..NET has been through two major and one minor iterations beyond the initial launch and is filled with stuff that can be done several ways because Microsoft did it one way in 1.0, then another in 1.1, then another yet in 2.0, and so on. Visual Studio does completely kick Xcode around the block at the moment, but Interface Builder similarly kicks Visual Studio around the block, and I can't wait for Xray, the dtrace-based debugger interface.
Right, because "internal database" equals "willfully belligerent restriction".
I try to avoid DRM as far as possible, but the iPod's database isn't DRM. It's an implementation detail. Currently it allows 'smart playlists' and metadata that I've already set (such as, on a song-to-song-basis: the rating, whether to remember playback position in-between plays, whether to include when playing the whole catalogue, and so on). I use these features and I will personally gladly trade-in file manager-based drag and drop for them - it's a tradeoff.
Of course, if you want to keep inferring that I'm using the music player that I do because I'm merely being sold Kool Toys for Kool Kids, that's your decision. Just don't let the idea that any amount of thought went into my choice settle in and you'll be fine.
Slashdot Mirror
JavaScript is a programming language. HTML is a markup language.
All things being equal and HTML starting out fresh, I guess you could make a case for a "strict only"-policy. We're not starting out fresh though.
Saying "IE8 is more likely to introduce HTML5 support than is any point release of IE7" sounds like it makes sense.
Are you seriously suggesting that XML's error handling is ideal - that the correct way, after 17 years of accepting non-perfect content in web browsers is to inform readers of a page that a href attribute that contains an & that's not part of an entity like & that the page is broken and then quit without showing any information? XML is awesome for programs reading data produced by other programs. Draconian error-handling is appropriate in such scenarios. However, way too many people are hand-writing HTML - and it's way too hard to generate sensible HTML - to be able to make that plausible.
HTML5 defines and codifies separate HTML parsing rules, mostly backwards-compatible. You're able to download a HTML5 package and parse almost any site on the web today - are you willing to bet you can do that with half the XHTML pages? (Even if you still want to use XML, you can just write XHTML5, which is HTML5 with XML parsing.)
WHATWG's two specs specify both the HTML markup and the DOM. The two go hand in hand - that's why it in comparison to HTML 4.01 or even XHTML 2 looks like a "mish-mash of markup and javascript", because it's just not solely a markup spec anymore. If there's going to be a new HTML spec, it deserves to be a solid and holistic spec. The least you can do is include the DOM model inline, and not just publish a different spec, by a different working group, and brand it as "DOM HTML Extensions", or what have you.
I agree. This would be tremendously useful and even enable the true kind of table-like column layouts we've been wanting (not just text flowing into other boxes like CSS3 columns). Something like:
#column1 { /* Assume this exists */ }
/* Assume a function, of, that takes two arguments, the name of the property and the selector, and another function, own, that takes the name of the property and works on its own rule. */
#column2 {
width: (of(width, body) - of(width, #column1) - (own(padding)*2));
height: of(height, #column1);
padding: 0.5em;
}
Point versions would be a silly place to start supporting a major new standard. Usually it takes two or three versions to approach what could be called reasonably full compliance, depending on how 'major version' hungry you are (Mozilla Suite - by that name, yes, I know Seamonkey exists - was abandoned around 1.7 or 1.8).
One day every 365.2425 days. Somehow, I think you'll survive this time too without the high-quality, in-depth Slashdot reporting we all know and love.
I don't think the goal is "expose the personal details of everyone". I think the goal is "for everyone paid to write something, make them write that they *were* paid to write something or they won't get their money".
I still think writing what they're told in exchange for a check is ridiculous, but at least now you'd know which ones were paid. (Or, rather, you'd know which ones were written by people getting paid by companies who demanded they write that.) In any event, disclosing that you're getting paid does nothing to erode anonymity.
[W]e should all really care about why ze frank stopped the show. ze frank was a perfect example of a slick little gem of a performance idea that had legs. If it died because ze frank just got tired, well, OK. But if it died because it didn't ever have a hope of turning into something that sustained ze, then we should all be concerned and try to figure out why.
It 'died' because Ze had his mind set from very early on to run it for a full year. I'm not going to tell you Ze didn't want to continue. It seems fairly obvious to me that he wanted to.
A recent article said Ze's got some kind of gig in Tinseltown now. I have no idea what exactly it is, or if he's a producer or writer or performer, but there are two basic outcomes: He falls victim of dramatic Hollywoodization, or he keeps going, doing his own tremendous thing, bringing his stuff more or less to the masses. I know what I'm rooting for.
Because the thickness of the current model iPod is more important?
Yes, I rarely consider using anything else than BSD, MIT or public domain for my projects if I can help it, and I know that I "enjoy the practical benefits of freedom" and can help others. That was my point. My point was that I wasn't *forced* to do so by the terms of my license.
If you had to accurately represent the concept of open source every time you said something involving it, you wouldn't be in a free market, you'd be in a controlled market. In a controlled market, there's less of a chance that people could be assholes, but there's also less freedom. I don't think it's awesome that there are people who misrepresent it, but I do think it's great that there's people pushing for poetic justice and calling those people on their bluffs.
Not really, since there are plenty of actual open source developers - like yours truly - that don't want to subscribe to the militia-style enforced 'freedom' preservation, but who do want the pragmatic benefits of making source available and helping others. As many people have commented, open source has its own definition - that it was ever simply a 'mispronouncement' of Free Software and doesn't thrive on its own merit is bullshit. (Yes, even if some people will write 'open source' when you tell them to write 'Free Software'.)
That's not to say that there aren't people that misrepresent the concept of "open source" to gain benefits or goodwill. If this surprises you, welcome to the free market as driven by humans.
The real problem with the iPhone is its strengths. No, I'm not being facetious. Look at it.
Some of the iPhone's strengths are the high resolution screen (160dpi), Multi-touch and OS X - ie their own operating system. Do you want to run a keypad-based Java game on the iPhone? There's no tactile feedback for what I presume would be an on-screen keypad for controlling the thing, and the program itself would be downright piddly on a higher resolution display than is normal. Squint city, I tell you. Not to mention that since Apple is using their own OS, they'd need to implement Java ME on it, maintain not only feature compatibility but bug compatibility, and regularly check with new programs to make sure they all run. That's a tall order even if the end result was going to be as good as Java on any other phone (it won't) and Apple were motivated to make it happen (they aren't). In short: Java midlets, even if perfectly implemented, would look small, not feel natural to control and not actually take advantage of any of the features. If you live and die by those exact Java apps, you would be better off buying another phone.
Like with any phone, I do want third-party software, but unlike any other phone, I want software written for the iPhone specifically. Anything else wouldn't work. You wouldn't be able to take advantage of multi-touch to zoom or scroll easily. My desire for the iPhone is hampered by Apple's 'closed box' stance, since extra apps are more important on a smartphone than on an MP3 player, but I am optimistic that Apple will come to their senses eventually and allow more open third party development.
The iPhone's got two wild cards. The first is that the shipping apps seem to actually not suck since they've been spending years building mail clients and web browsers on their own on the desktop before. Bundled cell phone software tends to suck, and the iPhone software looks like it's actually been designed more than thrown together. The second wild card is call management. You mean there are big, fat, easily pressed and clearly labelled buttons on the screen I can push to merge calls or put people on hold instead of needing to push codes via the key pad? I guess I'll excuse the traditional cell phone creators for not coming up with that, though. Most have had a piddly 20 years or so to come up with that.
Didn't they change the Store to make it add DRM when PyMusique got out? (Because as you say, PyMusique didn't add (and couldn't reasonably have added) DRM after downloading songs.)
That said, I'm not buying the "fool into thinking it's DRM-less". First of all, Apple serves up DRM-less music *today* with the iTunes U (U for University) program where they host AAC files of lectures. Now that this is all done of the server, getting that changed would be either a wide-open hole in the code OR getting into the database and changing, say, hasDRM from 1 to 0. If either of those holes are there, you could do much worse than remove DRM.
I do believe that since the Big Four labels were on first and got to dictate that they absolutely needed DRM, it wouldn't be beyond them to say "and don't let anyone else serve up DRM-less music from iTunes". After all, when iTunes offers only DRM-ed music, Apple looks bad; if iTunes offered non-DRM-ed music from a bunch of artists but not from the Big Fours, the Big Four would look bad. And we know which one the Big Four would prefer.
How else than by making everyone waive their rights to the music will you be able to concentrate everything to a single vendor? Because if people have any say in it, out of *the creators of all the music ever* there will definitely be two artists who don't want to be with the same vendor, or that want to create their own. And if everything will be there and it's going to be convenient for customers, there's going to be liberal usage rights, and there's probably one or two artists that want more control over their own stuff than that, too.
I'd definitely enjoy renting the music from the single reliable, full-stock and honest source you're describing, but that's not to say that it'd be practically possible. Way over the horizon. Handwaving to counter the real argument. How about describing DRM as it applies to today's situation rather than in the Republic of Imaginary Perfect Bliss? (Population: speculative.)
Uh. Correction. Minus: "Correct: no piece of complex software (and almost no pieces of easy software as well) contain bugs." Plus: "Correct: no piece of complex software (and almost no pieces of easy software as well) are free of bugs."
Correct: it is a workaround offered by a user, and surely firmware updates will straighten things out. Correct: no piece of complex software (and almost no pieces of easy software as well) contain bugs. My confidence in Apple to provide an upgrade to the problem has nothing to do with the fact that it is a problem now, and that the workaround - offered by Apple or not - is crap when compared to a real fix.
My comment's parent was arguing that vending a computer directly to the Internet is acceptable and even to be preferred instead of "having to hide behind some shitty, ineffective firewall". Then he got started on Mac OS X's security record, which really has nothing to do with anything other than, in effect, making the workaround a little less horrible. He got labelled a Troll, and that seems fairly accurate.
I am not trying to tell Apple they suck - and believe you me, I would if *they* offered the workaround as a permanent solution, which they assuredly won't. I'm saying that embracing the workaround as somehow a better state of affairs than a functional solution (see, again, my comment's parent) is foolish.
That was exactly what I said, unless you can parse that sentence another way. (I probably should have said "you can't establish a VPN connection to an external VPN server" instead of "with".) Computer has a VPN client, tries to connect to VPN server outside the internal network, the connection doesn't go through the base station. Computer is set to DMZ, connection does go through.
The issue seems to be that, without setting your computer as the DMZ in the base station settings, you can't establish a VPN connection with an external VPN server from your computer.
That doesn't change the fact that you shouldn't have to put it in the DMZ in the first place. It's a horrible workaround from a security point-of-view, and it's not even practical - if you have two computers inside that want to use a VPN, you're screwed because you can't have two "default hosts".
Even if Mac OS X was twice as secure as it is - and yes, I'm one of them who thinks that outside of bugs and vulnerabilities that almost every piece of software has (unless it was developed by either NASA or djb), it's reasonably secure because it was designed to be more secure, not just because it enjoys less market share - that still wouldn't be a justification for an obvious bug in the base station's firmware. It's a lucky circumstance that may function as a workaround, but there's no way it actually qualifies as an acceptable solution to anything.
Just to clarify, I said 95-thru-Me BSOD not to imply that they were the only ones with BSODs, but because they BSODed much more frequently due to errors that won't bring down an NT-based Windows setup. Personally, I've seen both BSODs in Windows 2000 and in Windows XP (and far more in 2000 than in XP, despite using XP quite a bit more).
I never understood the unabashed Clippy hatred. It was certainly a more friendly window to the whole help interface since it's much easier for a novice to ask a question than rummage through indices. It was one checkbox to turn the little bugger off, and you could choose something that you thought was less annoying if that was the problem. (I've almost always used the dog.) Not to mention that he's being going away more and more the past few versions: "It looks like you are writing a letter" is becoming about as relevant as the 95-thru-Me era BSOD.
I agree with the new notions that the Office user interface team has chosen to adopt, like only being able to access a feature from one place. Jensen Harris is a smart guy and I've been enjoying reading his weblog and the trials and tribulations of the Ribbon and the new UI as a whole.
Vista has been coming forever, the shipping version already shipped for some before the turn of the year. Apple is entirely to blame for not pre-emptively putting out 7.0.3 to fix these things, because boy have they had the time to do so. They *have* put out a fix by now for part of the problems, but it's not an iTunes update, and Vista may have botched these things, but it's not like they haven't had time or opportunity to fix them.
I do like Apple and I do like iTunes, but this is the same arrogant flank of the company that told you they were mad at Microsoft because Windows wasn't secure enough when they accidently shipped a batch of iPods with a Windows virus on the hard drive.
This is really interesting. Apple *has* several teams since they also have Carbon and their own Java runtime. The Java team has obviously got their agenda set, but not much is happening with Carbon. Jens Alfke, an Apple engineer, was knee-deep in the Java runtime for some time but defected to another team and wrote the iChat prototype after just one week of internal Cocoa training. Not to mention that around the time when the plans for Mac OS X were made public, they said they'd just use their Java port of QuickTime, and now they're rewriting basic layers in Objective-C to be eased in with 64-bit (where the old versions are not ported). Apple was very unsure of Cocoa when they first acquired it as the OpenStep APIs, and now it's one of the company's most valuable software possessions.
And Microsoft, of course... Microsoft seems to have very happy and genuinely enthusiastic developers. This isn't their problem, it's one of cobbling together something coherent with that many people, and being under the onus of needing to provide "Enterprise stuff" - expensive but unneeded and acronym-heavy solutions, all regularly updated to new, wildly incompatible versions at the drop of a hat to keep it 'fresh' for CIOs. (Uh. Not that I'm bitter.)
As someone who develops in Cocoa and .NET (but who, admittedly, is writing this on a MacBook), I have to say that Cocoa is not *that* far ahead of .NET. If you're the hairy-chest C++ strongly typed unsigned volatile sealed abstract interface kind of programmer, you'll definitely like .NET more than Cocoa.
.NET is negligible - they both are pretty good. I get around faster in Cocoa, but until 10.5 comes out (and in reality for about two years after that as well), I'll have to do manual memory management. As for .NET, that framework has more symbols than, well, all of Unicode. ;)
.NET has been through two major and one minor iterations beyond the initial launch and is filled with stuff that can be done several ways because Microsoft did it one way in 1.0, then another in 1.1, then another yet in 2.0, and so on. Visual Studio does completely kick Xcode around the block at the moment, but Interface Builder similarly kicks Visual Studio around the block, and I can't wait for Xray, the dtrace-based debugger interface.
The difference it'd take me to develop an application in Cocoa and in
Cocoa started out smaller, has grown more carefully and is as a result reasonably mature and fairly easy to get your head around.
Right, because "internal database" equals "willfully belligerent restriction".
I try to avoid DRM as far as possible, but the iPod's database isn't DRM. It's an implementation detail. Currently it allows 'smart playlists' and metadata that I've already set (such as, on a song-to-song-basis: the rating, whether to remember playback position in-between plays, whether to include when playing the whole catalogue, and so on). I use these features and I will personally gladly trade-in file manager-based drag and drop for them - it's a tradeoff.
Of course, if you want to keep inferring that I'm using the music player that I do because I'm merely being sold Kool Toys for Kool Kids, that's your decision. Just don't let the idea that any amount of thought went into my choice settle in and you'll be fine.