I don't notice the typing problem. I'm on a dual 867 system. I edit rather long messages in forums like this one without noticing such a problem. I admit that in earlier versions of Chimera I hated doing this. But I don't notice it now, although I still prefer Omniweb for typing. What version of Chimera are you using? Something sounds wrong.
Regarding what some others asked about anti-aliasing. This is a real problem although there are modifications you can make to Chimera to limit the smallest font displayed and also the font used. Various hacks have been discussed on many message boards and Version Tracker even has an application to modify them without editing the pref file by hand. Some of these the nightlies have added interfaces for.
To see the problem check out this MacNN Forum thread. Be aware that it is based off on Chimera 0.5 and not the more recent version. But the same basic problem remains. It also demonstrates the display differences between Omniweb and Chimera on ESPN.
I'd have to say that I've modified my position somewhat since that thread. I find that CHimera 0.6 is improved enough that I now use it more than Omniweb.
The problem only really occurs with some fonts that the Carbon anti-aliases handles differently than the Cocoa anti-aliasing. I've complained about browsing the MacNN Forums with Chimera, for instance. They use bold Geneva which anti-aliases horribly with Chimera. There was a discussion of this in the MacNN Forums. Basically there isn't much of a work around. That is more Apple's fault than anyone elses though.
You are right that text input fields still use the Gecko code which is oriented towards crossplatform abilities. Supposedly that will be changed, but because of the difficulty will be one of the last things finished. Hopefully by then Apple will have made more Cocoa features available to the Carbon API.
I believe that this is the only reason for it that makes sense. Presumably it would allow some manufacturers, such as HP, to leverage a lot of their existing network code to better serve the Macintosh market. Whether that happens, of course, is a whole other kettle of fish. While printing has improved dramatically, it still is rather lacking.
Overall though I see this as part of Apple's strategy for true fast plug and play peripherals. Rendezvous is an other part of it. Actual real world applications aren't really available. So we'll see how it all pans out. Apple's had exciting technology before that rarely got used. (OpenDoc, QuickdrawGX, etc.) Given that the Mac is still a small market I'm not sure most peripheral makers will actually end up using all this stuff. Call me skeptical, but I think we need some nice 3rd party companies to offer this sort of thing.
Anyone remember those old laser printers that plugged into the SCSI port? Of course I never thought they worked that well, but I suspect this is setting up a networked version of that. However Apple really needs to offer the peripherals themselves if they want to kickstart the market. Unfortunately the afore mentioned problems of unimplemented cool technology applies to Apple as much as anyone. Take a look at Appleworks and how few OSX features it uses.
Have you used Chimera of late? Most of the Flash bugs have been fixed. You need the latest download from Macromedia, but it works quite well. Many of Flash heavy sites I used to have problems with work perfectly now.
Don't get me wrong. I have some problems with Chimera. Its history is weak. It has few features. It doesn't support most of the nice Cocoa features that Omniweb does. (i.e. spellchecking) But it is very fast and renders pages better than Omniweb. What I've heard about the new Omniweb makes me excited. But that is still likely about two months out.
Sorry, I said Java when I should have said JavaScript. And JavaScript isn't that bad. By limiting things to JavaScript it really relieves a lot of headaches for Apple in terms of security and so forth.
I understand what you are saying about the limited language choices, but it is supposed to be a semi-limited product. If you are already using Perl and so forth why not simply have an application? Why embed it is Sherlock at all? You could whip up a front-end to the Perl with Obj-C and Interface Builder rather quickly.
Admittedly Perl has nice datamunging functions, however if you read the links, you'd see that Apple has provided numerous extensions to both JavaScript and XQuery. Things like data-match and so forth. Further if you must use Perl, simply write a CGI script and call it with your JavaScript or XQuery. It can get data from any URL, after all.
There is something wrong with this article. For one it says all the browsers pretty much rendered ESPN right. However Omniweb, my favorite browser, does NOT render ESPN right. The speeds seem slightly off from what I see on my system as well. Right now Chimera renders about as fast as my PC while the others are far slower.
I really don't think it is a terribly good article. It isn't very specific in problems. They also didn't do what I think is applicable: a bank test. Most problems Mac browsers have are with banks. Chimera handles most of them as well as IE. Omniweb doesn't.
I should add that the browser scene is changing quickly. The latest releases of Chimera really have improved a lot. Although its still a beta, it is a beta far more usable than many iApps. Omniweb is falling behind, but version 5.0 is just around the corner. It'll have an entirely new rendering engine and should remove all the problems it has with CSS and tables.
I'm not quite sure what you mean. Right now the iPod *already* syncs over Firewire. Or do you mean remote syncing when you are on the road? Plug into a friend's Mac and sync with your computer back home?
That might work, but would mean that you'd have to have a lot working in between. (i.e. you couldn't be behind a general NAT server, the ports can't be hidden by a firewall, etc.) There are other issues as well.
Don't get me wrong, it is doable. But it seems that for a general solution for the general public there are too many things that could go wrong. Try explaining to the non-technical Mac user why their ISP is blocking this feature.
Further, who really needs that sort of thing? It sounds to me like a nice 3rd party opportunity. But even there you'd still need the software on the Mac hosting your iPod's connection to the net. I suspect though that all you'd need to do is snag that iPod software for Linux (opensource) and then add a bit of a socking talking (easy and you could crib it from an FTP server if you must).
So the project isn't that hard. I'm just not sure but what it is a solution in search of a problem though. After all don't you typically need to sync only when you've changed what music is in iTunes? And if you've done that, aren't you already in front of your computer? So why the need for an IP connection between the iPod and your computer?
People write for markets they can make money at. Right now while many games make huge profits, many others lose money. If you are investing a lot of time and effort you'll probably develop for the market with the best return on your investment. That is Windows games and likely the various consoles. OSX follows a distant third and even there are usually ports done by subcontracted Mac developers. (And they usually are inferior, unfortunately) Linux is a distant, distant market.
Sorry, but it is the truth.
The problem has less to do with DirectX vs. OpenGL than it does code reuse and other such issues at the gaming companies.
Put an other way, if you think that porting DirectX means fewer games for Linux, you are simply being naive. The reason games don't come to Linux is much more complex.
Xquery is actually very nice. There are whole books on it. The "do a Perl hack" approach to everything isn't always that wise. (And there are XQuery implementations in Perl)
If you are primarily dealing with XML data then XQuery is really the way to go. Further having Java interfaces is also quite nice.
I can't speak to the API itself nor the documentation, but having web services based upon Java and XQuery makes me suspect Apple is doing it right. What they need now is a good O'Reilly book to explain how it all works. . .
Re:32-bit compatible = a temporary half-solution
on
AMD's 64-bit Plot
·
· Score: 2
Many, although not all, of those problems can be solved by compiling your key code on multiple platforms. Obviously you'll have some system dependencies - especially in the interface. But it is almost always a good idea to isolate the interface from the "substance." Making the "substance" crossplatform is almost always a good idea, and not just because of future sales or development.
If you do this sort of crossplatform development you'll find bugs easier and most of the above sorts of issues never happen. Then when 64-bit computing arises, you'll have few problems in your development. I know I compile under OSX, Linux, Solaris, Borland and Visual Studio. It really does find a lot of bugs and prevents a lot of problem. I do a cross-compile every few weeks and it is amazing how many things pop up that never did in my main development system.
You miss the point. Applescript works with the Window Manager running which runs as a user. The problem is that if no one has logged in then iTunes can't run and the Perl script won't work. If you are running your Perl scripts from Apache this can cause problems. Further if you try to make it more robust you open up all sorts of security holes.
Both links I provided discussed this in depth.
I was curious if the Perl scripts mentioned were simply calling the same Applescripts and how they dealt with these issues. My sense was that they were variations on the similar Perl code discussed at the MacDev page at O'Reilly.
Just out of curiousity, how do these Perl scripts work if there is no user currently logged into OSX? After all iTunes works in a user mode. If you call the Perl script and no user is logged in, will it work?
If this is the same code that was discussed over at O'Reilly you need to start tweaking how Apache or other things run.
Actually there was a story on Slashdot last week that Microsoft won't be adopting a nice XML data format for Word. I'm sure they'll use aspects of XML but the difficulty of reading Word files is actually a plus for Redmond. They don't WANT to make it easy to write Office compatible software. They don't WANT OpenOffice or other projects to succeed. So anyone who thinks Word files will one day be easy to write a parser for is simply deluding themselves.
The other problem with this is the idea that simply having a common document format between Word and some other word processor would mean anything. Anyone remember Word PerfecT? It could do this. Word even read and wrote WP files in all versions. However it was almost always a royal pain in the ass having half a company's files in one format or the other. I did IT for a few years out of college and that was a headache at times.
No, if you want Open Office to succeed it has to handle NATIVELY all the various document formats that Microsoft handles. Further it must use those as their default out of the box if you want to have more clueless users using that software. Otherwise you'll have users saving their OpenOffice files, sending them to someone and that other person not being able to open it. Just because they COULD download some plug-in means little. They'll get upset about how you sent them a non-standard file.
The more hassle there is, the less likely it is to be adopted. Half the reason Office is so popular is because, for all its flaws, you just install and go. You KNOW it will work with everyone else.
That's the big achilles heel of Linux and BSD. Microsoft isn't developing Office for them. That's even the big selling point of OSX as a Unix desktop. It has Office without a lot of hassle. YEah the OSX version has problems and isn't 100% compatible with everything. But by and large it is install and go with few worries.
I'd bet that if Microsoft got worried about Apple all they'd have to do to seriously damage them is stop developing Office.
Given the nature of open source expect a variation of this to appear on OSX once the 970 versions of OSX arrive.
However as everyone else is saying, the actual situations where one would need 64-bit apps are rather limited. It might even result in a slight slowdown due to having to move a twice the data around with pointers and other such things.
They monitor both Los Alamos and White Rock a great deal. At a very minimum there are lots of anti-Lab folks down in Sante Fe who do anything and everything to undercut the lab. Since most of them are "New Age mystic environmentalists" the environmental card is their favorite.
Remember a few years back when there were those claims about an increase in Leukima and brain cancer around the golf course there? They did pretty extensive studies and evaluations.
Further, half the people in the area wear dosimeter badges. You technically aren't supposed to wear them home, but everyone does. So I can guarantee that the area is monitored very closely.
Don't get me wrong. There obviously is a lot of waste in the area. Back when I worked there they were cleaning up a field because in the 40's they'd simply driven some trucks in a dug out hole and buried them with their waste. But the lab was cleaning up pretty heavily in preparation for the Tiger Team evaluations back in the early 90's. They've continued since then. If you compare Los Alamos to most other DOE sites it comes out near the top in dealing with environmental issues.
Further, despite the cries of people in Sante Fe, I think that most people at the lab are very ecologically aware. People do have concerns about the area and tend to be disproportionately involved in my opinion. Sometimes you end up with odd situations as well. For instance my supervisor who was doing some classified work on nuclear explosions was also a member of Earth First. (We had some rather interesting discussions on this to me paradox)
iCal has the opportunity to really offer very nice calender services for all OSX applications. The downside is that the iCal application itself is rather slow and definitely an initial release. Further it, along with the Address application, have many questionable limitations. Both cry out for a 2.0 release.
One big thing I'd like to see reconciled is some sort of Office integration with Outlook on the PC. If Apple could do that then they'd really have a very compelling argument for PC users to switch. (Minus their hardware problems)
Apple has been maintaining a i386 version of OSX since the beginning and keeps its features in step with the PowerPC version.
Apple has been doing this, although I'm not sure it is for all the parts of OSX. Purportedly this is to allow them to find many bugs that don't crop up on the PPC version. Having done a lot of crossplatform work, I can attest to this as a great way of finding bugs. Even moving between compilers on the same machine often is helpful. I know that Darwin is regularly compiled on both (and you can download them for both) However word around the campfire is that the x86 version of Darwin isn't very optimized and thus doesn't run that well. If Apple had serious x86 plans you'd expect a lot of work on the x86 version of Darwin. We don't really seem to see that.
In addition the Quartz subsystem probably would need a lot of work to get working well on the x86. You'd then have the problem of remnants of Carbon that still have a lot of legacy code in them that won't port well to the x86.
The big problem isn't the main part of OSX, which could be ported. The big problem is Classic which contains a LOT of PPC code. Further, even if other companies could recode their programs, getting them to do so is an other matter. Look how long it has taken Macromedia and other companies to even come out with OSX versions. Many people still run a lot of legacy code as well. Put it an other way, how many copies of OSX would sell if you couldn't run legacy code? (Or how many copies of XP would with the same?)
The issue isn't how many chips they are selling. The issue is how much money they are making or losing selling them.
You might be selling 10x the chips. But if you are losing money on them. ..
Further the issue isn't what AMD is doing now but what AMD will be doing a year or two from now. If they are devaluing the desktop x86 market what will they shift their focus to? It is either embedded chips, the Mac desktop, or else support chips. What else is left?
They also cleaned up Los Alamos a lot back when they were inspecting all the DOE sites back in the early 90's. I thought a lot of the inspections were a joke. (A friend got in trouble because of the kind of bolts being used were "cheap" even though they didn't really do anything but hold a cheap thin piece of aluminum)
One thing they did look at was radioactive materials. The bathroom where I worked got shut down because of radiation in the walls from the 1950's. Nothing that was really dangerous, but they were so hyper that they checked everyting.
There have been fairly consistent rumors that AMD will, to increase revenue, be helping manufacture the 970 for Apple and IBM. This, of course, isn't designing chips. But it is almost certain Apple will be moving away from Motorola. Thus if IBM can't supply the volume they may contract to AMD. This would give them cash to survive to find various niche markets - probably the embedded market - to sell to.
I don't think this means a pull out from x86 chips, but perhaps a change in what x86 they focus in on.
If AMD does move towards the PowerPC it makes sense. It is a market that has been largely devalued by Motorola and Apple is hungry for chips. I've read that Steve Jobs and the AMD CEO are old friends. So Apple may even offer incentives that will keep AMD afloat and be a win - win for both sides.
Of course many of the rumors are very silly. (i.e. the rumors going around that OSX will run on AMD's Hammer chips - difficult if not impossible due to the difficulty of emulating PPC code on a x86 platform) However there may be a core of truth to them. Certainly AMD hasn't been making it competing with Intel.
Does this mean that all comments here get modded -1:Redundant?
Re:Adopt Apple's HI guidelines for Linux
on
Ellen Feiss Interview
·
· Score: 3, Informative
How many times does this need to be stated? Macs support multiple mouse buttons. I'd never use a single button on my Mac. I use right button for the context menu and the scroll button to scroll windows. What is different is that on the Mac you have a choice. On Windows many applications require the context menu. And on Linux there is typically little rhyme nor reason for how the buttons work. (Yes Gnome and KDE are improving consistency - but that is still my #1 compaint while using X11 apps)
Slashdot Mirror
Regarding what some others asked about anti-aliasing. This is a real problem although there are modifications you can make to Chimera to limit the smallest font displayed and also the font used. Various hacks have been discussed on many message boards and Version Tracker even has an application to modify them without editing the pref file by hand. Some of these the nightlies have added interfaces for.
To see the problem check out this MacNN Forum thread. Be aware that it is based off on Chimera 0.5 and not the more recent version. But the same basic problem remains. It also demonstrates the display differences between Omniweb and Chimera on ESPN.
I'd have to say that I've modified my position somewhat since that thread. I find that CHimera 0.6 is improved enough that I now use it more than Omniweb.
You are right that text input fields still use the Gecko code which is oriented towards crossplatform abilities. Supposedly that will be changed, but because of the difficulty will be one of the last things finished. Hopefully by then Apple will have made more Cocoa features available to the Carbon API.
Overall though I see this as part of Apple's strategy for true fast plug and play peripherals. Rendezvous is an other part of it. Actual real world applications aren't really available. So we'll see how it all pans out. Apple's had exciting technology before that rarely got used. (OpenDoc, QuickdrawGX, etc.) Given that the Mac is still a small market I'm not sure most peripheral makers will actually end up using all this stuff. Call me skeptical, but I think we need some nice 3rd party companies to offer this sort of thing.
Anyone remember those old laser printers that plugged into the SCSI port? Of course I never thought they worked that well, but I suspect this is setting up a networked version of that. However Apple really needs to offer the peripherals themselves if they want to kickstart the market. Unfortunately the afore mentioned problems of unimplemented cool technology applies to Apple as much as anyone. Take a look at Appleworks and how few OSX features it uses.
Don't get me wrong. I have some problems with Chimera. Its history is weak. It has few features. It doesn't support most of the nice Cocoa features that Omniweb does. (i.e. spellchecking) But it is very fast and renders pages better than Omniweb. What I've heard about the new Omniweb makes me excited. But that is still likely about two months out.
I understand what you are saying about the limited language choices, but it is supposed to be a semi-limited product. If you are already using Perl and so forth why not simply have an application? Why embed it is Sherlock at all? You could whip up a front-end to the Perl with Obj-C and Interface Builder rather quickly.
Admittedly Perl has nice datamunging functions, however if you read the links, you'd see that Apple has provided numerous extensions to both JavaScript and XQuery. Things like data-match and so forth. Further if you must use Perl, simply write a CGI script and call it with your JavaScript or XQuery. It can get data from any URL, after all.
I really don't think it is a terribly good article. It isn't very specific in problems. They also didn't do what I think is applicable: a bank test. Most problems Mac browsers have are with banks. Chimera handles most of them as well as IE. Omniweb doesn't.
I should add that the browser scene is changing quickly. The latest releases of Chimera really have improved a lot. Although its still a beta, it is a beta far more usable than many iApps. Omniweb is falling behind, but version 5.0 is just around the corner. It'll have an entirely new rendering engine and should remove all the problems it has with CSS and tables.
That might work, but would mean that you'd have to have a lot working in between. (i.e. you couldn't be behind a general NAT server, the ports can't be hidden by a firewall, etc.) There are other issues as well.
Don't get me wrong, it is doable. But it seems that for a general solution for the general public there are too many things that could go wrong. Try explaining to the non-technical Mac user why their ISP is blocking this feature.
Further, who really needs that sort of thing? It sounds to me like a nice 3rd party opportunity. But even there you'd still need the software on the Mac hosting your iPod's connection to the net. I suspect though that all you'd need to do is snag that iPod software for Linux (opensource) and then add a bit of a socking talking (easy and you could crib it from an FTP server if you must).
So the project isn't that hard. I'm just not sure but what it is a solution in search of a problem though. After all don't you typically need to sync only when you've changed what music is in iTunes? And if you've done that, aren't you already in front of your computer? So why the need for an IP connection between the iPod and your computer?
Sorry, but it is the truth.
The problem has less to do with DirectX vs. OpenGL than it does code reuse and other such issues at the gaming companies.
Put an other way, if you think that porting DirectX means fewer games for Linux, you are simply being naive. The reason games don't come to Linux is much more complex.
My bad.
Xquery is actually very nice. There are whole books on it. The "do a Perl hack" approach to everything isn't always that wise. (And there are XQuery implementations in Perl) If you are primarily dealing with XML data then XQuery is really the way to go. Further having Java interfaces is also quite nice. I can't speak to the API itself nor the documentation, but having web services based upon Java and XQuery makes me suspect Apple is doing it right. What they need now is a good O'Reilly book to explain how it all works. . .
If you do this sort of crossplatform development you'll find bugs easier and most of the above sorts of issues never happen. Then when 64-bit computing arises, you'll have few problems in your development. I know I compile under OSX, Linux, Solaris, Borland and Visual Studio. It really does find a lot of bugs and prevents a lot of problem. I do a cross-compile every few weeks and it is amazing how many things pop up that never did in my main development system.
Both links I provided discussed this in depth.
I was curious if the Perl scripts mentioned were simply calling the same Applescripts and how they dealt with these issues. My sense was that they were variations on the similar Perl code discussed at the MacDev page at O'Reilly.
Capiche?
If this is the same code that was discussed over at O'Reilly you need to start tweaking how Apache or other things run.
There was a discussion of this over at MacNN Forums as well.
What I like is that Apple is poking fun at their own Switch ads. Great stuff. Here's hoping we have some more.
The other problem with this is the idea that simply having a common document format between Word and some other word processor would mean anything. Anyone remember Word PerfecT? It could do this. Word even read and wrote WP files in all versions. However it was almost always a royal pain in the ass having half a company's files in one format or the other. I did IT for a few years out of college and that was a headache at times.
No, if you want Open Office to succeed it has to handle NATIVELY all the various document formats that Microsoft handles. Further it must use those as their default out of the box if you want to have more clueless users using that software. Otherwise you'll have users saving their OpenOffice files, sending them to someone and that other person not being able to open it. Just because they COULD download some plug-in means little. They'll get upset about how you sent them a non-standard file.
The more hassle there is, the less likely it is to be adopted. Half the reason Office is so popular is because, for all its flaws, you just install and go. You KNOW it will work with everyone else.
That's the big achilles heel of Linux and BSD. Microsoft isn't developing Office for them. That's even the big selling point of OSX as a Unix desktop. It has Office without a lot of hassle. YEah the OSX version has problems and isn't 100% compatible with everything. But by and large it is install and go with few worries.
I'd bet that if Microsoft got worried about Apple all they'd have to do to seriously damage them is stop developing Office.
However as everyone else is saying, the actual situations where one would need 64-bit apps are rather limited. It might even result in a slight slowdown due to having to move a twice the data around with pointers and other such things.
Remember a few years back when there were those claims about an increase in Leukima and brain cancer around the golf course there? They did pretty extensive studies and evaluations.
Further, half the people in the area wear dosimeter badges. You technically aren't supposed to wear them home, but everyone does. So I can guarantee that the area is monitored very closely.
Don't get me wrong. There obviously is a lot of waste in the area. Back when I worked there they were cleaning up a field because in the 40's they'd simply driven some trucks in a dug out hole and buried them with their waste. But the lab was cleaning up pretty heavily in preparation for the Tiger Team evaluations back in the early 90's. They've continued since then. If you compare Los Alamos to most other DOE sites it comes out near the top in dealing with environmental issues.
Further, despite the cries of people in Sante Fe, I think that most people at the lab are very ecologically aware. People do have concerns about the area and tend to be disproportionately involved in my opinion. Sometimes you end up with odd situations as well. For instance my supervisor who was doing some classified work on nuclear explosions was also a member of Earth First. (We had some rather interesting discussions on this to me paradox)
One big thing I'd like to see reconciled is some sort of Office integration with Outlook on the PC. If Apple could do that then they'd really have a very compelling argument for PC users to switch. (Minus their hardware problems)
In addition the Quartz subsystem probably would need a lot of work to get working well on the x86. You'd then have the problem of remnants of Carbon that still have a lot of legacy code in them that won't port well to the x86.
The big problem isn't the main part of OSX, which could be ported. The big problem is Classic which contains a LOT of PPC code. Further, even if other companies could recode their programs, getting them to do so is an other matter. Look how long it has taken Macromedia and other companies to even come out with OSX versions. Many people still run a lot of legacy code as well. Put it an other way, how many copies of OSX would sell if you couldn't run legacy code? (Or how many copies of XP would with the same?)
You might be selling 10x the chips. But if you are losing money on them. . .
Further the issue isn't what AMD is doing now but what AMD will be doing a year or two from now. If they are devaluing the desktop x86 market what will they shift their focus to? It is either embedded chips, the Mac desktop, or else support chips. What else is left?
One thing they did look at was radioactive materials. The bathroom where I worked got shut down because of radiation in the walls from the 1950's. Nothing that was really dangerous, but they were so hyper that they checked everyting.
I don't think this means a pull out from x86 chips, but perhaps a change in what x86 they focus in on.
If AMD does move towards the PowerPC it makes sense. It is a market that has been largely devalued by Motorola and Apple is hungry for chips. I've read that Steve Jobs and the AMD CEO are old friends. So Apple may even offer incentives that will keep AMD afloat and be a win - win for both sides.
Of course many of the rumors are very silly. (i.e. the rumors going around that OSX will run on AMD's Hammer chips - difficult if not impossible due to the difficulty of emulating PPC code on a x86 platform) However there may be a core of truth to them. Certainly AMD hasn't been making it competing with Intel.
The best part is when Shatner makes an unannounced appearance and all of them join in a rendition of "Tamborine Man"
Does this mean that all comments here get modded -1:Redundant?
How many times does this need to be stated? Macs support multiple mouse buttons. I'd never use a single button on my Mac. I use right button for the context menu and the scroll button to scroll windows. What is different is that on the Mac you have a choice. On Windows many applications require the context menu. And on Linux there is typically little rhyme nor reason for how the buttons work. (Yes Gnome and KDE are improving consistency - but that is still my #1 compaint while using X11 apps)