What's even more embarrassing is when you zip up those files, send them to a Mac associate, and they don't work. Those hidden files are necessary for basic operation in some cases, and are there solely because Windows and Linux filesystems (generally) do not handle multi-fork files.
By inserting the word "solely" you seem to assert that multi-fork file systems are a good idea. They've been the bane of Mac users existence since the beginning and we'd all have been better off if Apple had just used multiple individual files. Fortunately using extra forks is now officially not recommended by Apple. Apple should just name these files .EMBARRASSING_LEGACY_MAC_SUPPORT.
Quote:
Originally Posted by Kickaha
Apple's general position has been that, if you put a manual button in for the user, then the developer's will never try and fix the problem on the back end.
So you're going to hinder the use for every Mac user just to teach a few developers a lesson? This makes no sense. It's just a plain old omission... there is no good reason for it. MacOS X still has omitted, necessary features.
Quote:
Originally Posted by Kickaha
The only OS to use CR *and* LF is Windows. Unix systems use LF. All of them. It isn't an Apple crazy anything, it is the *correct* EOL, by definition, in the original ASCII layout. They actually got it right this time, Macs used to use CR. MacOS X flipped it to LF. Windows remains the incorrect one.
This is a pretty annoying problem, but as you say, with the advent of XML file formats everywhere it's increasingly not an issue. Because of this, I wouldn't care if MacOS did switch to use the line endings that 95% of the industry (ie. "just Windows") uses.
What I never understood about this rumour was why October was specified. Vista is out, and beta releases have been available for quite some time (years even). If Vista support delayed Leopard (highly unlikely but anyway) why would it have delayed the release until October? Anyway, cheers to Apple for shooting this one down. Like everyone else, I'm getting antsy, but I think some of the Big Things Apple has planned in the next little while will make the waiting all worthwhile.
The only OS to use CR *and* LF is Windows. Unix systems use LF. All of them. It isn't an Apple crazy anything, it is the *correct* EOL, by definition, in the original ASCII layout.
I can't find anything to confirm whether there is a correct way according to a national or international standard.
Quote:
What incompatibility issues are you seeing? I haven't had an issue with this in a long, long time.
At most, text files are a pain to convert. I still get the text, but it's sometimes a mess unless I add another step.
I can't find anything to confirm whether there is a correct way according to a national or international standard.
Originally, LF was for physical shifts in lines, CR was for 'soft-returns', where the user intended a linebreak to be, but there may not be one in 'reality'. It was an early attempt at a separation of semantics and layout. Unix went with LF as the "No, really, this is a break and return" since it makes more sense if that's really what you mean. The original Macintosh went with CR, since it was more GUI-user oriented, and wanted to abstract out the line breaks a level. Windows went with CRLF for... well, I'm sure they had a good reason at the time.
Quote:
At most, text files are a pain to convert. I still get the text, but it's sometimes a mess unless I add another step.
Like I said, I haven't seen this in literally a few years, and that's with tossing files over to Windows and Unix folks on a regular basis. Wacky. Where are you seeing this?
Windows went with CRLF for... well, I'm sure they had a good reason at the time.
Logically, on a physical printer, a LF character would rotate the paper roller one line, and CR would return the print head (carriage) to the beginning of the line. Thus, if you want the print head at the beginning of the next line, you send a \\CR\\LF. UNIX and Mac took shortcuts here, probably to save a little disk space or something But Windows is the "correct" usage of LF and CR as far as printers are concerned.
By inserting the word "solely" you seem to assert that multi-fork file systems are a good idea. They've been the bane of Mac users existence since the beginning and we'd all have been better off if Apple had just used multiple individual files. Fortunately using extra forks is now officially not recommended by Apple. Apple should just name these files .EMBARRASSING_LEGACY_MAC_SUPPORT.
Sorry, but I vehemently disagree with you on this, and if you look at the direction the industry is going, so does most of it. Multi-forked filesystems are becoming the norm, just very slowly. They offer some very large benefits over non-forked filesystems. The only place they have ever caused problems is when migrating files to non-forked systems. I'm sorry, but that's like saying that GUI apps in general are bad because they can't run on a Z19 text terminal.
Quote:
So you're going to hinder the use for every Mac user just to teach a few developers a lesson? This makes no sense. It's just a plain old omission... there is no good reason for it. MacOS X still has omitted, necessary features.
No, that's not it. First of all, I'm not defending the position, only outlining it. So please don't aim that at me. Secondly, it's not an omission at all, *if* the system works correctly. *If* the system always saw the file as soon as it showed up, then the manual approach would be completely unnecessary, right? The manual approach is only required when a) the automatic approach isn't even coded in, or b) it is coded in incorrectly. If it's broken, then fix it, don't punt the job to the user with a manual override. Doing so just means you've given up on making it work right. Like I said, file a bug report. That's how Apple decides how to allocate programming resources. Every report filed is a vote to get that feature fixed.
Quote:
This is a pretty annoying problem, but as you say, with the advent of XML file formats everywhere it's increasingly not an issue. Because of this, I wouldn't care if MacOS did switch to use the line endings that 95% of the industry (ie. "just Windows") uses.
Windows is 95% of the PC market, by some counts. They are *not* 95% of the industry, by any means. Not even close. Add in embedded systems, mainframes, server clusters, and so on, and they're down around half, at best. As someone who deals with pretty much the whole range, I'd hate to see CRLF adopted just because *some* portion of the market, and possibly not even a plurality, got it wrong and can't get in line with everyone else.
Logically, on a physical printer, a LF character would rotate the paper roller one line, and CR would return the print head (carriage) to the beginning of the line. Thus, if you want the print head at the beginning of the next line, you send a \\CR\\LF. UNIX and Mac took shortcuts here, probably to save a little disk space or something But Windows is the "correct" usage of LF and CR as far as printers are concerned.
You're right, I forgot about printers. Did Stretch operate that way?
When dealing with text files though, in the absence of printing, LF was the accepted practice, as I recall. I know it was certainly that way on every legacy system I used, although I can't say I remember which way it was on the line printer terminal. (Those were a bear - no screen, just paper output.)
I agree. One thing that can be said about Digitimes: they're at least consistent...consistently wrong. Someone else that needs filtering-out is Shawn Wu (an "analyst"), who's correct about as often as Digitimes.
I don't think you can say that Shawn's accuracy is as good as Digitimes. His predictions aren't normally wrong - just obvious. He usually just reiterates what many of us in the AI forums already know. That could still be a reason to filter him out of AI articles, but I'd rather leave that to Kasper's judgment.
------------------
A message to DigiTimes on behalf of us all: TOLD YOU SO.
Logically, on a physical printer, a LF character would rotate the paper roller one line, and CR would return the print head (carriage) to the beginning of the line. Thus, if you want the print head at the beginning of the next line, you send a \\CR\\LF. UNIX and Mac took shortcuts here, probably to save a little disk space or something But Windows is the "correct" usage of LF and CR as far as printers are concerned.
Actually it goes back to the old teletype machines. These were separate functions in the teletype machines. A LF character advanced the paper one line. (Allowing for the insertion of white space and gaps between news stories and messages.) A CR moved the type head to the beginning of the line. And there was even a BELL character to get the operators attention. AP had a special bell code that they used to identify FLASH news stories, like Kennedy's assassination.
Like I said, I haven't seen this in literally a few years, and that's with tossing files over to Windows and Unix folks on a regular basis. Wacky. Where are you seeing this?
I think it was with text clippings between Notepad and Textedit.
I think it was with text clippings between Notepad and Textedit.
Hmm. I keep my encoding on Automatic, and it seems to work alright, but I'll confess I don't recall knowingly swapping files with Notepad. (Wow, that sounds salacious.)
Honestly, I do most of my raw text work in TextMate, which handles it all beautifully. Never had a problem there. Well, that and vi, where I can swap the line endings easily at the command line, so... huh.
Dual boot for Vista is not a problem. To push Leopard's release date back 5 months in order to get dual boot to work just seemed like a silly report to start with. Of course it'll work for anyone who's interested. No, a 5-6 month delay would mean Apple decided to incorporate technology still under consideration. But that could be introduced as a later update. If the original report holds any truth at all it could hint at something else coming this october, like touch screens + additional OS X user interface or something other OS X related.
Sorry, but I vehemently disagree with you on this, and if you look at the direction the industry is going, so does most of it. Multi-forked filesystems are becoming the norm, just very slowly. They offer some very large benefits over non-forked filesystems. The only place they have ever caused problems is when migrating files to non-forked systems. I'm sorry, but that's like saying that GUI apps in general are bad because they can't run on a Z19 text terminal.
I see what direction the industry is going. Microsoft added multiple forks when they introduced NTFS in the early 90's, but was smart enough not to depend on them. Novell, Netware, UFS, ZFS, and others all support it, so there's really no OS that doesn't. And even Apple recommends against using resource forks as of MacOS 8.6 and all versions of MacOS X (see the "Carbon Porting Guide".)
But this conversation has gotten a little off-track. Since almost no one uses resource forks anymore, most of the time the .DS_Store file doesn't contain resources. It contains window size information, Finder preferences, and similar Mac-specific information.
Quote:
Originally Posted by Kickaha
No, that's not it. First of all, I'm not defending the position, only outlining it. So please don't aim that at me. Secondly, it's not an omission at all, *if* the system works correctly. *If* the system always saw the file as soon as it showed up, then the manual approach would be completely unnecessary, right? The manual approach is only required when a) the automatic approach isn't even coded in, or b) it is coded in incorrectly. If it's broken, then fix it, don't punt the job to the user with a manual override. Doing so just means you've given up on making it work right. Like I said, file a bug report. That's how Apple decides how to allocate programming resources. Every report filed is a vote to get that feature fixed.
"given up on making it work right" for your definition of "right". There will always be systems out there that don't implement remote callbacks for change notification on directories, and polling takes up resources. These systems really do need a manual way to refresh a directory, and I'm sure Apple knows that. They've probably just prioritized this feature way down.
Quote:
Originally Posted by Kickaha
Windows is 95% of the PC market, by some counts. They are *not* 95% of the industry, by any means. Not even close. Add in embedded systems, mainframes, server clusters, and so on, and they're down around half, at best. As someone who deals with pretty much the whole range, I'd hate to see CRLF adopted just because *some* portion of the market, and possibly not even a plurality, got it wrong and can't get in line with everyone else.
Microsoft is the #1 vendor of desktop, embedded, and server operating systems, with over 50% market share in the first two and continuing to gain market share in the second two. And as someone who agrees with me that the difference in line ending doesn't really affect them much, my mind boggles at your vehemence with which you argue against standardizing the industry on the most common practice. Honestly, I doubt anyone would notice.
I don't think you can say that Shawn's accuracy is as good as Digitimes. His predictions aren't normally wrong - just obvious. He usually just reiterates what many of us in the AI forums already know. That could still be a reason to filter him out of AI articles, but I'd rather leave that to Kasper's judgment.
The name is Shaw Wu. I can understand the mistake, but it's still a mistake.
I don't think Shaw has made as spectacular blunders as DigiTimes has. I think it would be interesting if someone can keep a rumor scoreboard of some sort, but that's a lot of work, and that's work that I wouldn't wish on anyone.
Ayup. Spring is March 21-June 21 in the Northern Hemisphere. More relevantly, the Spring financial quarter is Apr-June.
Frank777, March isn't the end of spring, it's the start.
Yes, but my point is that the features of the OS must be locked down by now. Jobs was the one who stood up and told everybody at MacWorld to be ready for it this spring.
What's the harm in previewing the OS so that we can start to plan for our new equipment purchases?
I'd like to see the recommended specs, whether we're moving to a new Filesystem and Finder, and if there are any other special equipment needs to make good use of Leopard (like how Time Machine requires an external drive, etc.)
With the CS3 announcement on Tuesday, many Vista users will have a green light to upgrade immediately while Mac users are caught in a no man's land of wondering whether a 24 inch iMac is okay, or if a Mac Pro is worth the extra money.
Is the 3GB limit something to be concerned about over the long term? I have no idea.
The name is Shaw Wu. I can understand the mistake, but it's still a mistake.
I don't think Shaw has made as spectacular blunders as DigiTimes has. I think it would be interesting if someone can keep a rumor scoreboard of some sort, but that's a lot of work, and that's work that I wouldn't wish on anyone.
Macrumors.com keeps a scoreboard for several analysts in their guides section.
But it did come in the first quarter as Steve first said. And again, I would hope that our troops in Iraq could only be just delayed 3 weeks before coming home.
Delayed 3 weeks? How can they be delayed? I have yet to hear any kind of release date for that product. Imagine if Steve were handling the release of Leopard this way. "We must and we will continue [coding Leopard] until the job is finished. We owe this to the many brave [software engineers] who have given their lives in the cause of [Leopard]. Giving a firm release date would only embolden [Microsoft]."
I wonder how people would have reacted back in the mid 1900's if there was a product delay before an impending release of a updated typewriter with new features such as "better correction methods".
"given up on making it work right" for your definition of "right".
For the definition that Apple uses, yes. Again, don't make this personal. I'm just outlining the position that Apple is using, not adopting it as my own. I'd appreciate it if you'd see and respect the distinction.
Quote:
There will always be systems out there that don't implement remote callbacks for change notification on directories, and polling takes up resources. These systems really do need a manual way to refresh a directory, and I'm sure Apple knows that. They've probably just prioritized this feature way down.
Yes, just as there will always be systems out there that don't implement multi-forked systems. But what are the remote filesharing systems that the Finder implements clients for? AFP (Apple's), SMB, NFS... and for most people it's AFP and SMB. It doesn't have to be *ALL* systems out there to implement the necessary features, only that the ones Apple supplies clients for do. So here's the 64k$ question - how many of those selected protocols don't offer a way of pushing down file changes to the Finder client? If the answer is 'none', then it should be expected that this would be quite doable without a manual refresh.
Quote:
Microsoft is the #1 vendor of desktop, embedded, and server operating systems, with over 50% market share in the first two and continuing to gain market share in the second two.
Er, which set of two does embedded fit into? I count three, so... Seriously, while they may be the largest single-source vendor of embedded (which I'm not convinced of - I think Symbian is pretty damned large there), and server OSs, I don't believe they're even close to the largest OS in those markets. When you combine all the Unix/Linux variants sold by various vendors, together they more than equal the MS offerings. I mean seriously - think of all the embedded systems out there in consumer electronics, cars, medical devices, you name it. It's a *massive* space, and Windows is running at all in what slices of it? Phones, and... ? (Yes, I know that there's an Embedded Windows product, I honestly don't know what it runs on these days.)
Quote:
And as someone who agrees with me that the difference in line ending doesn't really affect them much, my mind boggles at your vehemence with which you argue against standardizing the industry on the most common practice. Honestly, I doubt anyone would notice.
You haven't convinced me that it's the most common, by any means. I mean, you do realize that the programming language still with the largest use (as measured in shipping LOC) is COBOL, right? The PC market is, when you come down to it, just a piece of the whole, and not even a particularly massive one.
Since our positions hinge solely on which line ending has the most common use, and we can't agree on that, (and I don't think either of us going to uncover compelling evidence to that end) let's just agree to disagree, alright?
Yes, just as there will always be systems out there that don't implement multi-forked systems. But what are the remote filesharing systems that the Finder implements clients for? AFP (Apple's), SMB, NFS... and for most people it's AFP and SMB. It doesn't have to be *ALL* systems out there to implement the necessary features, only that the ones Apple supplies clients for do. So here's the 64k$ question - how many of those selected protocols don't offer a way of pushing down file changes to the Finder client? If the answer is 'none', then it should be expected that this would be quite doable without a manual refresh.
How about WebDAV? I'm pretty sure it doesn't do notification. Or ftp, which Apple insists on using the Finder to gateway to.
Quote:
Originally Posted by Kickaha
Seriously, while they may be the largest single-source vendor of embedded (which I'm not convinced of - I think Symbian is pretty damned large there), and server OSs, I don't believe they're even close to the largest OS in those markets. When you combine all the Unix/Linux variants sold by various vendors, together they more than equal the MS offerings. I mean seriously - think of all the embedded systems out there in consumer electronics, cars, medical devices, you name it. It's a *massive* space, and Windows is running at all in what slices of it? Phones, and... ? (Yes, I know that there's an Embedded Windows product, I honestly don't know what it runs on these days.)
It's true that Microsoft is only the #1 embedded OS maker in revenue, not in unit shipments, but it's certainly the dominant force in that industry these days. If you count in-house embedded OSes, like Cisco's routers, it may skew the numbers a little. But Symbian on this list is #4, behind Wind River and Palm.
Quote:
Originally Posted by Kickaha
You haven't convinced me that it's the most common, by any means. I mean, you do realize that the programming language still with the largest use (as measured in shipping LOC) is COBOL, right? The PC market is, when you come down to it, just a piece of the whole, and not even a particularly massive one.
How many text files to those embedded OSes deal with? I'd argue that when you account for desktop and server OSes, you've already covered 90% of the text files in use.
And I'd like to see a citation for the oft-repeated assertion regarding COBOL. In the late 90's and early 00's, a lot of that code was ported to Java, which last I saw had the most number of new code lines shipped in any given year for several years now. (Objective-C isn't even on the radar-- another move of Apple's I consider somewhat boneheaded. The sooner Apple dumps ObjC the faster they'll pick up industry support.)
Quote:
Originally Posted by Kickaha
Since our positions hinge solely on which line ending has the most common use, and we can't agree on that, (and I don't think either of us going to uncover compelling evidence to that end) let's just agree to disagree, alright?
That's how this problem happened in the first place....
Comments
What's even more embarrassing is when you zip up those files, send them to a Mac associate, and they don't work. Those hidden files are necessary for basic operation in some cases, and are there solely because Windows and Linux filesystems (generally) do not handle multi-fork files.
By inserting the word "solely" you seem to assert that multi-fork file systems are a good idea. They've been the bane of Mac users existence since the beginning and we'd all have been better off if Apple had just used multiple individual files. Fortunately using extra forks is now officially not recommended by Apple. Apple should just name these files .EMBARRASSING_LEGACY_MAC_SUPPORT.
Apple's general position has been that, if you put a manual button in for the user, then the developer's will never try and fix the problem on the back end.
So you're going to hinder the use for every Mac user just to teach a few developers a lesson? This makes no sense. It's just a plain old omission... there is no good reason for it. MacOS X still has omitted, necessary features.
The only OS to use CR *and* LF is Windows. Unix systems use LF. All of them. It isn't an Apple crazy anything, it is the *correct* EOL, by definition, in the original ASCII layout. They actually got it right this time, Macs used to use CR. MacOS X flipped it to LF. Windows remains the incorrect one.
This is a pretty annoying problem, but as you say, with the advent of XML file formats everywhere it's increasingly not an issue. Because of this, I wouldn't care if MacOS did switch to use the line endings that 95% of the industry (ie. "just Windows") uses.
The only OS to use CR *and* LF is Windows. Unix systems use LF. All of them. It isn't an Apple crazy anything, it is the *correct* EOL, by definition, in the original ASCII layout.
I can't find anything to confirm whether there is a correct way according to a national or international standard.
What incompatibility issues are you seeing? I haven't had an issue with this in a long, long time.
At most, text files are a pain to convert. I still get the text, but it's sometimes a mess unless I add another step.
I can't find anything to confirm whether there is a correct way according to a national or international standard.
Originally, LF was for physical shifts in lines, CR was for 'soft-returns', where the user intended a linebreak to be, but there may not be one in 'reality'. It was an early attempt at a separation of semantics and layout. Unix went with LF as the "No, really, this is a break and return" since it makes more sense if that's really what you mean. The original Macintosh went with CR, since it was more GUI-user oriented, and wanted to abstract out the line breaks a level. Windows went with CRLF for... well, I'm sure they had a good reason at the time.
At most, text files are a pain to convert. I still get the text, but it's sometimes a mess unless I add another step.
Like I said, I haven't seen this in literally a few years, and that's with tossing files over to Windows and Unix folks on a regular basis. Wacky. Where are you seeing this?
Windows went with CRLF for... well, I'm sure they had a good reason at the time.
Logically, on a physical printer, a LF character would rotate the paper roller one line, and CR would return the print head (carriage) to the beginning of the line. Thus, if you want the print head at the beginning of the next line, you send a \\CR\\LF. UNIX and Mac took shortcuts here, probably to save a little disk space or something But Windows is the "correct" usage of LF and CR as far as printers are concerned.
By inserting the word "solely" you seem to assert that multi-fork file systems are a good idea. They've been the bane of Mac users existence since the beginning and we'd all have been better off if Apple had just used multiple individual files. Fortunately using extra forks is now officially not recommended by Apple. Apple should just name these files .EMBARRASSING_LEGACY_MAC_SUPPORT.
Sorry, but I vehemently disagree with you on this, and if you look at the direction the industry is going, so does most of it. Multi-forked filesystems are becoming the norm, just very slowly. They offer some very large benefits over non-forked filesystems. The only place they have ever caused problems is when migrating files to non-forked systems. I'm sorry, but that's like saying that GUI apps in general are bad because they can't run on a Z19 text terminal.
So you're going to hinder the use for every Mac user just to teach a few developers a lesson? This makes no sense. It's just a plain old omission... there is no good reason for it. MacOS X still has omitted, necessary features.
No, that's not it. First of all, I'm not defending the position, only outlining it. So please don't aim that at me. Secondly, it's not an omission at all, *if* the system works correctly. *If* the system always saw the file as soon as it showed up, then the manual approach would be completely unnecessary, right? The manual approach is only required when a) the automatic approach isn't even coded in, or b) it is coded in incorrectly. If it's broken, then fix it, don't punt the job to the user with a manual override. Doing so just means you've given up on making it work right. Like I said, file a bug report. That's how Apple decides how to allocate programming resources. Every report filed is a vote to get that feature fixed.
This is a pretty annoying problem, but as you say, with the advent of XML file formats everywhere it's increasingly not an issue. Because of this, I wouldn't care if MacOS did switch to use the line endings that 95% of the industry (ie. "just Windows") uses.
Windows is 95% of the PC market, by some counts. They are *not* 95% of the industry, by any means. Not even close. Add in embedded systems, mainframes, server clusters, and so on, and they're down around half, at best. As someone who deals with pretty much the whole range, I'd hate to see CRLF adopted just because *some* portion of the market, and possibly not even a plurality, got it wrong and can't get in line with everyone else.
Logically, on a physical printer, a LF character would rotate the paper roller one line, and CR would return the print head (carriage) to the beginning of the line. Thus, if you want the print head at the beginning of the next line, you send a \\CR\\LF. UNIX and Mac took shortcuts here, probably to save a little disk space or something But Windows is the "correct" usage of LF and CR as far as printers are concerned.
You're right, I forgot about printers. Did Stretch operate that way?
When dealing with text files though, in the absence of printing, LF was the accepted practice, as I recall. I know it was certainly that way on every legacy system I used, although I can't say I remember which way it was on the line printer terminal. (Those were a bear - no screen, just paper output.)
I agree. One thing that can be said about Digitimes: they're at least consistent...consistently wrong. Someone else that needs filtering-out is Shawn Wu (an "analyst"), who's correct about as often as Digitimes.
I don't think you can say that Shawn's accuracy is as good as Digitimes. His predictions aren't normally wrong - just obvious. He usually just reiterates what many of us in the AI forums already know. That could still be a reason to filter him out of AI articles, but I'd rather leave that to Kasper's judgment.
------------------
A message to DigiTimes on behalf of us all: TOLD YOU SO.
Logically, on a physical printer, a LF character would rotate the paper roller one line, and CR would return the print head (carriage) to the beginning of the line. Thus, if you want the print head at the beginning of the next line, you send a \\CR\\LF. UNIX and Mac took shortcuts here, probably to save a little disk space or something But Windows is the "correct" usage of LF and CR as far as printers are concerned.
Actually it goes back to the old teletype machines. These were separate functions in the teletype machines. A LF character advanced the paper one line. (Allowing for the insertion of white space and gaps between news stories and messages.) A CR moved the type head to the beginning of the line. And there was even a BELL character to get the operators attention. AP had a special bell code that they used to identify FLASH news stories, like Kennedy's assassination.
Like I said, I haven't seen this in literally a few years, and that's with tossing files over to Windows and Unix folks on a regular basis. Wacky. Where are you seeing this?
I think it was with text clippings between Notepad and Textedit.
I think it was with text clippings between Notepad and Textedit.
Hmm. I keep my encoding on Automatic, and it seems to work alright, but I'll confess I don't recall knowingly swapping files with Notepad. (Wow, that sounds salacious.)
Honestly, I do most of my raw text work in TextMate, which handles it all beautifully. Never had a problem there. Well, that and vi, where I can swap the line endings easily at the command line, so... huh.
Sorry, but I vehemently disagree with you on this, and if you look at the direction the industry is going, so does most of it. Multi-forked filesystems are becoming the norm, just very slowly. They offer some very large benefits over non-forked filesystems. The only place they have ever caused problems is when migrating files to non-forked systems. I'm sorry, but that's like saying that GUI apps in general are bad because they can't run on a Z19 text terminal.
I see what direction the industry is going. Microsoft added multiple forks when they introduced NTFS in the early 90's, but was smart enough not to depend on them. Novell, Netware, UFS, ZFS, and others all support it, so there's really no OS that doesn't. And even Apple recommends against using resource forks as of MacOS 8.6 and all versions of MacOS X (see the "Carbon Porting Guide".)
But this conversation has gotten a little off-track. Since almost no one uses resource forks anymore, most of the time the .DS_Store file doesn't contain resources. It contains window size information, Finder preferences, and similar Mac-specific information.
No, that's not it. First of all, I'm not defending the position, only outlining it. So please don't aim that at me. Secondly, it's not an omission at all, *if* the system works correctly. *If* the system always saw the file as soon as it showed up, then the manual approach would be completely unnecessary, right? The manual approach is only required when a) the automatic approach isn't even coded in, or b) it is coded in incorrectly. If it's broken, then fix it, don't punt the job to the user with a manual override. Doing so just means you've given up on making it work right. Like I said, file a bug report. That's how Apple decides how to allocate programming resources. Every report filed is a vote to get that feature fixed.
"given up on making it work right" for your definition of "right". There will always be systems out there that don't implement remote callbacks for change notification on directories, and polling takes up resources. These systems really do need a manual way to refresh a directory, and I'm sure Apple knows that. They've probably just prioritized this feature way down.
Windows is 95% of the PC market, by some counts. They are *not* 95% of the industry, by any means. Not even close. Add in embedded systems, mainframes, server clusters, and so on, and they're down around half, at best. As someone who deals with pretty much the whole range, I'd hate to see CRLF adopted just because *some* portion of the market, and possibly not even a plurality, got it wrong and can't get in line with everyone else.
Microsoft is the #1 vendor of desktop, embedded, and server operating systems, with over 50% market share in the first two and continuing to gain market share in the second two. And as someone who agrees with me that the difference in line ending doesn't really affect them much, my mind boggles at your vehemence with which you argue against standardizing the industry on the most common practice. Honestly, I doubt anyone would notice.
I don't think you can say that Shawn's accuracy is as good as Digitimes. His predictions aren't normally wrong - just obvious. He usually just reiterates what many of us in the AI forums already know. That could still be a reason to filter him out of AI articles, but I'd rather leave that to Kasper's judgment.
The name is Shaw Wu. I can understand the mistake, but it's still a mistake.
I don't think Shaw has made as spectacular blunders as DigiTimes has. I think it would be interesting if someone can keep a rumor scoreboard of some sort, but that's a lot of work, and that's work that I wouldn't wish on anyone.
Ayup. Spring is March 21-June 21 in the Northern Hemisphere. More relevantly, the Spring financial quarter is Apr-June.
Frank777, March isn't the end of spring, it's the start.
Yes, but my point is that the features of the OS must be locked down by now. Jobs was the one who stood up and told everybody at MacWorld to be ready for it this spring.
What's the harm in previewing the OS so that we can start to plan for our new equipment purchases?
I'd like to see the recommended specs, whether we're moving to a new Filesystem and Finder, and if there are any other special equipment needs to make good use of Leopard (like how Time Machine requires an external drive, etc.)
With the CS3 announcement on Tuesday, many Vista users will have a green light to upgrade immediately while Mac users are caught in a no man's land of wondering whether a 24 inch iMac is okay, or if a Mac Pro is worth the extra money.
Is the 3GB limit something to be concerned about over the long term? I have no idea.
The name is Shaw Wu. I can understand the mistake, but it's still a mistake.
I don't think Shaw has made as spectacular blunders as DigiTimes has. I think it would be interesting if someone can keep a rumor scoreboard of some sort, but that's a lot of work, and that's work that I wouldn't wish on anyone.
Macrumors.com keeps a scoreboard for several analysts in their guides section.
But it did come in the first quarter as Steve first said. And again, I would hope that our troops in Iraq could only be just delayed 3 weeks before coming home.
Delayed 3 weeks? How can they be delayed? I have yet to hear any kind of release date for that product. Imagine if Steve were handling the release of Leopard this way. "We must and we will continue [coding Leopard] until the job is finished. We owe this to the many brave [software engineers] who have given their lives in the cause of [Leopard]. Giving a firm release date would only embolden [Microsoft]."
I wonder how people would have reacted back in the mid 1900's if there was a product delay before an impending release of a updated typewriter with new features such as "better correction methods".
Ooh, has that come out yet?
"given up on making it work right" for your definition of "right".
For the definition that Apple uses, yes. Again, don't make this personal. I'm just outlining the position that Apple is using, not adopting it as my own. I'd appreciate it if you'd see and respect the distinction.
There will always be systems out there that don't implement remote callbacks for change notification on directories, and polling takes up resources. These systems really do need a manual way to refresh a directory, and I'm sure Apple knows that. They've probably just prioritized this feature way down.
Yes, just as there will always be systems out there that don't implement multi-forked systems. But what are the remote filesharing systems that the Finder implements clients for? AFP (Apple's), SMB, NFS... and for most people it's AFP and SMB. It doesn't have to be *ALL* systems out there to implement the necessary features, only that the ones Apple supplies clients for do. So here's the 64k$ question - how many of those selected protocols don't offer a way of pushing down file changes to the Finder client? If the answer is 'none', then it should be expected that this would be quite doable without a manual refresh.
Microsoft is the #1 vendor of desktop, embedded, and server operating systems, with over 50% market share in the first two and continuing to gain market share in the second two.
Er, which set of two does embedded fit into? I count three, so...
And as someone who agrees with me that the difference in line ending doesn't really affect them much, my mind boggles at your vehemence with which you argue against standardizing the industry on the most common practice. Honestly, I doubt anyone would notice.
You haven't convinced me that it's the most common, by any means. I mean, you do realize that the programming language still with the largest use (as measured in shipping LOC) is COBOL, right? The PC market is, when you come down to it, just a piece of the whole, and not even a particularly massive one.
Since our positions hinge solely on which line ending has the most common use, and we can't agree on that, (and I don't think either of us going to uncover compelling evidence to that end) let's just agree to disagree, alright?
Yes, just as there will always be systems out there that don't implement multi-forked systems. But what are the remote filesharing systems that the Finder implements clients for? AFP (Apple's), SMB, NFS... and for most people it's AFP and SMB. It doesn't have to be *ALL* systems out there to implement the necessary features, only that the ones Apple supplies clients for do. So here's the 64k$ question - how many of those selected protocols don't offer a way of pushing down file changes to the Finder client? If the answer is 'none', then it should be expected that this would be quite doable without a manual refresh.
How about WebDAV? I'm pretty sure it doesn't do notification. Or ftp, which Apple insists on using the Finder to gateway to.
Seriously, while they may be the largest single-source vendor of embedded (which I'm not convinced of - I think Symbian is pretty damned large there), and server OSs, I don't believe they're even close to the largest OS in those markets. When you combine all the Unix/Linux variants sold by various vendors, together they more than equal the MS offerings. I mean seriously - think of all the embedded systems out there in consumer electronics, cars, medical devices, you name it. It's a *massive* space, and Windows is running at all in what slices of it? Phones, and... ? (Yes, I know that there's an Embedded Windows product, I honestly don't know what it runs on these days.)
It's true that Microsoft is only the #1 embedded OS maker in revenue, not in unit shipments, but it's certainly the dominant force in that industry these days. If you count in-house embedded OSes, like Cisco's routers, it may skew the numbers a little. But Symbian on this list is #4, behind Wind River and Palm.
You haven't convinced me that it's the most common, by any means. I mean, you do realize that the programming language still with the largest use (as measured in shipping LOC) is COBOL, right? The PC market is, when you come down to it, just a piece of the whole, and not even a particularly massive one.
How many text files to those embedded OSes deal with? I'd argue that when you account for desktop and server OSes, you've already covered 90% of the text files in use.
And I'd like to see a citation for the oft-repeated assertion regarding COBOL. In the late 90's and early 00's, a lot of that code was ported to Java, which last I saw had the most number of new code lines shipped in any given year for several years now. (Objective-C isn't even on the radar-- another move of Apple's I consider somewhat boneheaded. The sooner Apple dumps ObjC the faster they'll pick up industry support.)
Since our positions hinge solely on which line ending has the most common use, and we can't agree on that, (and I don't think either of us going to uncover compelling evidence to that end) let's just agree to disagree, alright?
That's how this problem happened in the first place....