(I'm not attacking the config-file approach, just saying that having a convenient standardised interface to config data across all applications is a Good Thing).
How about a config file approach which has a convenient standardised interface to config data across all applications ? This is what Apple's CFPreferences API does. There is one API and it stores prefs in files in various locations you specify... hang on, no point in me explaining it, here's a link:
To sum up, preferences are stored in XML files in various locations, for example the current user of your application, all users of your application etc. No reason it has to use XML files with the API it has, but that's what it does. You don't actually deal with the files yourself, you just specify a domain and start adding and retrieving values as you will. It has the advantage of consistent access without the possibility of borking the entire system when someone does something stupid with the registry trying to store config info for their application.
It isn't illegal to sell stuff with region coding here ( New Zealand, of course ). My DVD player ( Sony ) is region 4 and my aunt's DVD player ( Panasonic I think ) is also region 4 but does at least have a relatively easy to use remote hack to change the region, unlike my one. I have around 5 DVD drives in various computers, all purchased in NZ ( Apple/PC/upgraded new drives ) and all are region locked. One of my laptops ( iBook ) has patched firmware so it is region free. You can get region free DVD players here easily enough, I didn't come across in any in appliance stores but electronics stores ( similar to Fry's ) have them. They're usually fairly cheap and nasty units.
I'm not sure where this whole "region coding illegal in NZ" thing came from, but it hasn't been the case for a long time. I did try and find out if there was any truth to it once, because as far as I knew everything was region locked as elsewhere, but managed to find only one or two outdated official-ish references and a handful of foreign sites which referred to it but which were also old or had since been corrected. Simply put, we suffer under the same region encoding most other places do, particularly because it's often tricky to get stuff in Region 4.
Apart from the old guy who runs the Foundation ( Elliot, Devon ?? ) and the girl super mechanic plus whoever drives that truck he's always pulling into the back of, and I guess all the members of the Foundation who support him...
on a crusade to champion the cause of the innocent, the helpless, the powerless,
As long as they or someone they know ( older sister, guardian etc. ) are cute and Michael can hook up with them at the end of the show.
in a world of criminals who operate above the law.
Not so many criminals who operate within the law... or they wouldn't be criminals.
It was on TV here ( New Zealand ) again fairly recently. Used to love it as a kid, found it harder to watch this time around. The music/opening credits are the best part.
but xbox 360 makes one innovation - moving closer to photorealism. that's it.
That isn't even innovative. That's what every single person involved with developing rendering hw/sw ( who isn't interested in non-photorealistic rendering:-) is working on. Our rendering software ( and others ) is already more photorealistic than the 360 graphics, but of course our stuff is non-realtime. The 360 just has more powerful hardware than previous consoles, so it can do more toward photorealism because it can crunch more numbers in a shorter time, but that holds true for any computer.
In this next round of consoles, the only thing I've seen so far which I would call "innovative", in the true dictionary meaning of the word instead of the watered down marketing buzzword use of the word so prevalent nowadays, is the Revolution controller and the potential for different kinds of gameplay it will allow. Possibly the Cell could be described as innovative, although the all-on-one-die main core and multiple DSP-ish/special purpose cores is perhaps more of something whose time has come due to manufacturing improvements.
Ah, you Ozzie wits. Just can't get past the sheep jokes can you;-). Last time my I was in Oz virtually every person I met had a lame sheep joke. I have a cousin working there at the moment who gets the same thing.
Funny thing ( or not ) is that there are about 3 times as many sheep in Australia as in NZ [1]. What's more I hear there is a shortage of women in rural Australia, for example in many parts of WA it's 3 men for every woman. My cousin does occupational health around rural NSW and Queensland and can confirm similar issues there. All those sheep, all those isolated places, so few women... you do the maaaa-th;-).
BTW, the number of sheep are steeply on the decline in NZ [2]. The main methane producers are cattle, whose numbers have increased greatly recently, particularly for dairy. There's still way more of both in Oz though.
3) If you're using Carbon, your interests really are Mac only.
Beeeehhhh, double wrong. I'm writing a cross platform UI framework using Carbon right now. It's C++ and abstracts most of the platform specific functionality ( currently Mac and Windows, maybe Linux in the future ) away primarily using a Bridge pattern. Works well. It takes a thin approach and allows access to platform specific underpinnings to allow you to give the best platform specific experience where that can only be given by writing platform specific code. It also doesn't try and abstract away general drawing stuff ( apart from OpenGL stuff ), so you would write drawing code on OS X using Quartz and on Windows using GDI or whatever. This approach has worked well for us in our current product, so we're sticking with it.
Most of the major cross platform apps I'm aware of use Carbon, mainly because it's easier to use with C/C++ and also no doubt because they didn't see sufficient value in adopting Cocoa when they moved to OS X. I don't know of anyone taking the approach you suggest, I've never heard anyone saying anything except GNUstep covers enough ground relative to Cocoa to make using it as the basis for a portable application of any size. I don't really know much about it except that as a developer it seems to me that trying to maintain an app using two different frameworks ( Cocoa and GNUstep ) with different Objective-C runtimes ( Apple's one and GNUsteps ) is likely to be just as much hassle as using two different APIs ( Carbon and Win32 ) underneath a C++ framework. Does GNUstep keep with all the new things Apple adds which developers are likely to want to use, such as Cocoa Bindings ? Do you have to compromise and take a least common denominator approach ?
Qt uses Carbon under the hood on OS X.
It may surprise you to learn that people have been writing cross platform applications on the Mac for a long, long time, long before OS X and Cocoa, for example, virtually ever major 2D graphics/DTP app. They used the predecessor of Carbon. Carbon is the "classic" MacOS C APIs cleaned up, modernised and improved.
In theory I could be using Cocoa instead of Carbon for the Mac specific stuff in our framework, but using Carbon isn't hard and it's what I know, so there doesn't seem to be much point in adding the extra compexity of meshing two languages.
So, dude, it seems like you're the one who needs to get a klew;-).
Most importantly, Altivec, while really fast, only support single precision computations. This is sufficient for improving multimedia playback, applying image filters on photos or compressing music, but lacking for high-precision computations. SSE supports double precision, a big improvement for the scientific market.
I'm on Apple's performance optimisation list and the simdtech.org Altivec mailing list. No one really seems to miss double precision floats in vectors. You can only operate on 2 at once with the 128 bit wide vector registers anyway. The G5/PPC 970 has two 2 64 bit wide FPUs, which gets you pretty much the equivalent of a vector unit, plus you can do everything you can normally do with the FPU that you can't do or is more difficult with Altivec ( IIRC division for example ). You can even use the vector unit at the same time, if you have single precision or integer work to do.
Most people who work with Altivec on the Mac don't seem to be particularly relishing moving to SSE, mostly because it's more primitive and not as capable ( that's aside from those who are just annoyed about their investment in Altivec going down the tubes ). I haven't really seen anyone getting excited about double precision in SSE. Could be because of the audience for that isn't really the same as the Altivec programmers I'm aware of, but when you consider there are quite a lot of scientific users on Mac already perhaps it isn't a big deal ? I'd be interested to hear if anyone is planning to change to OS X on Intel just because SSE can do double precision floats.
As a Mac developer, if we have to switch processors, I'd rather they went to Intel than to a Cell. Cell just doesn't seem like it will be that good for general computing. The main general purpose core ( sorry, I've forgotten the names the different Cell components ) seems to be less capable than a regular PPC chip. The peripheral cores sound like they will be tricky to develop for, and not suited to a lot of tasks. I'm sure once console guys get to grips with it they'll be able to some interesting stuff, but I'm not convinced that your average Mac developer is going to be able to invest much time in it - especially if they write something like a file utility, notebooking app, word processor and all the other stuff we need to make the Mac a good platform alongside cutting edge multimedia apps and such.
At least with Intel chips the whole performance question goes away. I don't think that for general purposes there is going to be a time when PPC has a clear and maintainable lead over Intel, not enough to justify sticking it out. I work on graphics software. I look forward to seeing a number of cross platform graphics apps take a jump forward in performance as optimisations from the Intel side of things also apply to the Mac versions. Don't get me wrong, I like Altivec and all, but I would imagine that most companies have many more people working on Intel optimisations than PPC ones. For our product I've added Altivec optimisations and threaded some parts of the Mac version, whereas the PC version doesn't have anything like this, but when there is only so much time in the day it's hard to justify spending time on new optimisations for a smaller group of users when there is new functionality and such to be added.
As Mac user I'm not really looking forward to the transition, but I think things are in place for it to be as smooth as it can be. Apple are giving developers good information, Rosetta works well for things I have tried it with. Even as a user I would prefer Intel to Cell ( again, if we must make a change ), because at least Intel is an established pretty well known quantity, and we know nothing too drastic is going to happen to them and if they have problems, pretty much everyone else does as well, and not just Apple with Motorola issues or IBM-actually-we-can't-do-3.0GHz problems.
I don't think there is such a thing as a cloned Intel Mac. AFAICT Intel Macs are just going to be Intel based PCs. I was going to say "with a TPM chip" but I wouldn't be surprised if those or something like them became a standard part of PC hardware ( hopefully not, but not surprised if they do ). Macs are pretty much PCs now anyway, with the exception of the CPU and chipset. It will be interesting to see how much of the chipset Apple will design on the Intel Macs, or whether they just end up using Intel ones. I'm guessing they'll use the Intel ones, because that will save them a lot of time and money.
That's also insulting to OpenSSH, come to think of it. You're saying OpenSSH is a pig ? Perhaps you mean "just putting some gilding on the lily" or similar ?
Desktop applications are finaly moving to the concept of "drawing" the UI in Photoshop or Acrylic and then adding functionality to it like when doing web pages.
Wow, that's exactly what I don't want from a desktop application. More applications with inconsistent appearances and behaviours, hooray... I recently helped install a bunch of Windows software on a relative's computer ( after installing a DVD drive for them, much of it was bundled stuff ) and every single app I dealt with had its own custom interface ( varying in crappiness ) which bore very little resemblance to anything else. I've been using computers for a fair old while now and I still had trouble figuring out how to quit some of these apps.
What you're suggesting makes me feel glad I'm not a ( full time ) Windows user...
and Apple's is trying desperately to duplicate Visual Studio with XCode (but failing miserably)
As an Xcode and VS6/VS 2003 user, I can say I don't think Apple is trying to duplicate VS at all. They haven't really made all that many concessions to CodeWarrior users, and have stated many times that they aren't trying to emulate anything with Xcode, just trying to make a good IDE.
In any case, Interface Builder ( part of the Xcode suite ) is the best GUI layout app I have ever used, hands down. It knocks the GUI layout tools of VS-whatever ( including VB ) into a cocked hat. It is better by miles than every other GUI layout app I've used - aforementioned VS environments, REALbasic, Glade, Delphi, wxDesigner, Qt Designer etc.
If you're a Cocoa developer ( which I'm not ), Interface Builder also has a lot of tools for visually connecting UI components to objects, data sources etc.
Straying a bit, but I don't actually understand why people think VS is such a great IDE. I only really use it for C++. VS 6 had me tearing my hair out over a number of UI things which were so awkward compared to what I had been used to ( in CodeWarrior ). VS 2003 improved much of that, but added quirks of its own. The code completion is good, but I don't actually find myself using it all that much. The parameter hints can be useful, but don't always work when they could be handy. I don't find general editing tasks as flexible as I'm used to on the editors I use on the Mac. When I have a lot of code to write, I generally write it in Xcode, even if it's Windows only code, which is far from perfect but which I find myself more productive in. I still have to do a lot in various VS versions, so I think I've given them a fair chance.
One thing I do appreciate about VS is the VBA support which lets me write scripts to automate a bunch of stuff I often have to do. I also have scripts to give the same results in Xcode and CodeWarrior. I find VBA is more flexible ( for various reasons, not necessarily related to the language ) than Perl in Xcode and AppleScript for CodeWarrior.
I have a 1.5 GHz PB G4. I also had the spinning beachball but I got it in the Spotlight menu, which I found to be unusable if I didn't type fast enough to get a good few letters in before Spotlight started searching. I had to use the Finder Find window if I wanted Spotlight to be useful. However, last night I installed a 1 GB stick of RAM to bring the PB up to 1.5 GB and now everything is hunky dory. Spotlight still isn't as instantly tremendous on this machine as has been suggested, but on my dual 2.7 G5 with 2 GB RAM it's super instantly tremendous. OTOH, I don't have nearly as much on my G5 as I do on my PB at the moment.
dgatwood already pointed out that Classic != Carbon, so I'll just add that Carbon apps can also use NIBs. My app does. Interface Builder ( which generates NIBs ) is a great tool, the best UI layout tool I've used, and I've used a few . It's not perfect mind you, one or two annoying bugs.
People here on/. seem to underestimate the importance of Carbon. There are a lot of developers still using it. It makes a lot of sense for cross platform apps particularly. Cocoa is a good OO framework, but Carbon is a pretty good API as well ( much nicer than Win32 ), especially since the advent of Carbon Events. It used to take pages of code to put up a window, write an event loop and and handle all its basic behaviour ( moving, sizing, zooming, closing etc. ) but now it's less than a page as most ( all ) of the basic behaviour is handled for you by the OS.
So the apps most people make will probably not see this compiler, except for tuned C code. So it'll probably mostly mean some faster libraries on the Intel macs.
I'm not sure most people use Cocoa to develop for OS X. A lot of people do, but I don't know that it would be half of Mac developers. Most of the important Mac apps ( at least what I consider important in my experience ) are written using Carbon.
Anyway, nothing to stop people moving performance critical code out to a library and compiling it with ICC. My own app has its Altivec code in a shared library/DLL, as that's the safest way to support machines without an Altivec unit ( G3 and earlier ).
I'm an ADC Select developer, and have one of the P4 'G5' boxes on my desk...
I have one too, but I'm unfortunately not able to use it yet.
Photoshop and the Altivec-intence apps are a LITTLE sluggish, but nothing that a native build won't fix.
Erm, Altivec intense apps won't even run, unless they can fall back to work with pure scalar code. Most would, I'd imagine, but even so. Altivec code just doesn't work on x86. A native build won't fix that either, unless the developer rewrites all the Altivec code for SSE. That's a bit more than just a native build if the app isn't already cross platform with SSE code in place.
I understand now why they don't have any seat at my new work: everybody just sit on the floor, in a hippie style...
You'd better get them to check the fine print of the license again :
The software is licensed per seat(1)...
(1) Seat is defined as sitting apparatus, seat-of-your-pants or as a simile for backside/butt/buns/arse [ covering hippies who might not be wearing pants ].
You might want to get that sorted out before the next BSA audit or your company could be in for a rude surprise ! Actually, if the hippies have no pants on, it might be the auditors who are rudely surprised first, but that doesn't mean you shouldn't make sure you're in total compliance with the license, because it takes more than that to throw off the BSA.
I shall have to make sure our software, which is licensed per seat, adds a clause which requires pants to be worn at all times while using the software, just to avoid embarassment. Nobody should have a problem with that, unless of course they're no-pants-wearing open source hippies, who wouldn't be using our software because of the draconian proprietary pants clause anyway.
Ah, but the great joint-Iluminati/World Zionist Consipracy/Knights Templar/other causers of tinfoil hat wearing group responsible rewrote all the books, obviously.
Ah, of course, how foolish of me.
Also, tides are caused by special machinery installed for the purpose.;)
Let me get this straight though - could the giant balloon not also be responsible for the tides ? No need for what would have to be some impressive machinery ( and associated maintenance, salt water can be rough on things ) if it were just a side effect of the giant balloon flying about. Those nuclear reactors would probably have a quite a bit of mass after all.
We also have the moon here in New Zealand. We're pretty liberal already, and we don't have the same issues with guns as the US does, so what could the liberal moon pilots be looking for ?
Yes, I know this probably sounds paranoid and preposterous, but consider this. Despite what the revisionist historians tell you, there is no mention of the "moon" anywhere in literature or historical documents -- anywhere -- before 1950.
Replying is troll feeding, and frankly I'm surprised you spent the energy to type all that out ( unless you're trying to be funny ), but I was reading this just the other day :
Romeo
But soft! What light through yonder window breaks?
It is the east, and Juliet is the sun.
Arise, fair sun, and kill the envious moon
The altivec implementation on G5s is weak compared to that on G4s, so the advantage isn't as great.
The bus speed is so greatly improved in the G5s though, 800 MHz and upwards ( half processor clock ), vs 167 MHz max in the G4s that you can get so much more data for the Altivec unit to work on. It's really easy to write Altivec code on a G4 which is memory bound. I don't think Altivec on G5s is so weak that it can be outweighed by the basic ability to get more data to work on more quickly. I haven't seen anyone complaining much about it.
This problem was resolved about 12 years ago when NextStep shipped on Intel.
The IO libs just take care of it.
You're kind of missing all of those Mac apps which were written prior to OS X and those afterwards which are based on Carbon and not Cocoa, or which are pure C/C++. The Cocoa IO libs might handle byte swapping ( in fact they do ) but neither the Carbon IO APIs or the C/C++ standard IO APIs do, and a lot of apps use those. MacOS development != NeXT derived.
Of course a lot of Mac apps are cross platform already and have sorted out endian issues years ago. With my own app it will just need a few changes to #defines and the Mac Intel version will be ready to go, from an endian-ness perspective anyway.
With regards to NeXT developers, I would have thought the number of old NeXT developers on the Mac since OS X was pretty small compared to the number of seasoned Mac developers who have also been involved in cross platform applications. Most of the Mac apps I've been using for years are cross platform after all.
Slashdot Mirror
How about a config file approach which has a convenient standardised interface to config data across all applications ? This is what Apple's CFPreferences API does. There is one API and it stores prefs in files in various locations you specify... hang on, no point in me explaining it, here's a link :
http://developer.apple.com/documentation/CoreFound ation/Conceptual/CFPreferences/index.html
To sum up, preferences are stored in XML files in various locations, for example the current user of your application, all users of your application etc. No reason it has to use XML files with the API it has, but that's what it does. You don't actually deal with the files yourself, you just specify a domain and start adding and retrieving values as you will. It has the advantage of consistent access without the possibility of borking the entire system when someone does something stupid with the registry trying to store config info for their application.
Seems like the best of both worlds to me.
Regards,
Jo Meder
I'm not sure where this whole "region coding illegal in NZ" thing came from, but it hasn't been the case for a long time. I did try and find out if there was any truth to it once, because as far as I knew everything was region locked as elsewhere, but managed to find only one or two outdated official-ish references and a handful of foreign sites which referred to it but which were also old or had since been corrected. Simply put, we suffer under the same region encoding most other places do, particularly because it's often tricky to get stuff in Region 4.
Regards,
Jo Meder
Apart from the old guy who runs the Foundation ( Elliot, Devon ?? ) and the girl super mechanic plus whoever drives that truck he's always pulling into the back of, and I guess all the members of the Foundation who support him...
on a crusade to champion the cause of the innocent, the helpless, the powerless,
As long as they or someone they know ( older sister, guardian etc. ) are cute and Michael can hook up with them at the end of the show.
in a world of criminals who operate above the law.
Not so many criminals who operate within the law ... or they wouldn't be criminals.
It was on TV here ( New Zealand ) again fairly recently. Used to love it as a kid, found it harder to watch this time around. The music/opening credits are the best part.
Regards,
Jo Meder
That isn't even innovative. That's what every single person involved with developing rendering hw/sw ( who isn't interested in non-photorealistic rendering :-) is working on. Our rendering software ( and others ) is already more photorealistic than the 360 graphics, but of course our stuff is non-realtime. The 360 just has more powerful hardware than previous consoles, so it can do more toward photorealism because it can crunch more numbers in a shorter time, but that holds true for any computer.
In this next round of consoles, the only thing I've seen so far which I would call "innovative", in the true dictionary meaning of the word instead of the watered down marketing buzzword use of the word so prevalent nowadays, is the Revolution controller and the potential for different kinds of gameplay it will allow. Possibly the Cell could be described as innovative, although the all-on-one-die main core and multiple DSP-ish/special purpose cores is perhaps more of something whose time has come due to manufacturing improvements.
Regards,
Jo Meder
Funny thing ( or not ) is that there are about 3 times as many sheep in Australia as in NZ [1]. What's more I hear there is a shortage of women in rural Australia, for example in many parts of WA it's 3 men for every woman. My cousin does occupational health around rural NSW and Queensland and can confirm similar issues there. All those sheep, all those isolated places, so few women... you do the maaaa-th ;-).
BTW, the number of sheep are steeply on the decline in NZ [2]. The main methane producers are cattle, whose numbers have increased greatly recently, particularly for dairy. There's still way more of both in Oz though.
[1]http://www.abs.gov.au/Ausstats/abs@.nsf/0/a3328 a1f1ca80e9dca2568a9001393ff?OpenDocument
[2]http://www.farmtofarm.co.nz/nz.html
Regards,
Jo Meder
Beeeehhhh, double wrong. I'm writing a cross platform UI framework using Carbon right now. It's C++ and abstracts most of the platform specific functionality ( currently Mac and Windows, maybe Linux in the future ) away primarily using a Bridge pattern. Works well. It takes a thin approach and allows access to platform specific underpinnings to allow you to give the best platform specific experience where that can only be given by writing platform specific code. It also doesn't try and abstract away general drawing stuff ( apart from OpenGL stuff ), so you would write drawing code on OS X using Quartz and on Windows using GDI or whatever. This approach has worked well for us in our current product, so we're sticking with it.
Most of the major cross platform apps I'm aware of use Carbon, mainly because it's easier to use with C/C++ and also no doubt because they didn't see sufficient value in adopting Cocoa when they moved to OS X. I don't know of anyone taking the approach you suggest, I've never heard anyone saying anything except GNUstep covers enough ground relative to Cocoa to make using it as the basis for a portable application of any size. I don't really know much about it except that as a developer it seems to me that trying to maintain an app using two different frameworks ( Cocoa and GNUstep ) with different Objective-C runtimes ( Apple's one and GNUsteps ) is likely to be just as much hassle as using two different APIs ( Carbon and Win32 ) underneath a C++ framework. Does GNUstep keep with all the new things Apple adds which developers are likely to want to use, such as Cocoa Bindings ? Do you have to compromise and take a least common denominator approach ?
Qt uses Carbon under the hood on OS X.
It may surprise you to learn that people have been writing cross platform applications on the Mac for a long, long time, long before OS X and Cocoa, for example, virtually ever major 2D graphics/DTP app. They used the predecessor of Carbon. Carbon is the "classic" MacOS C APIs cleaned up, modernised and improved.
In theory I could be using Cocoa instead of Carbon for the Mac specific stuff in our framework, but using Carbon isn't hard and it's what I know, so there doesn't seem to be much point in adding the extra compexity of meshing two languages.
So, dude, it seems like you're the one who needs to get a klew ;-).
Regards,
Jo Meder
I'm on Apple's performance optimisation list and the simdtech.org Altivec mailing list. No one really seems to miss double precision floats in vectors. You can only operate on 2 at once with the 128 bit wide vector registers anyway. The G5/PPC 970 has two 2 64 bit wide FPUs, which gets you pretty much the equivalent of a vector unit, plus you can do everything you can normally do with the FPU that you can't do or is more difficult with Altivec ( IIRC division for example ). You can even use the vector unit at the same time, if you have single precision or integer work to do.
Most people who work with Altivec on the Mac don't seem to be particularly relishing moving to SSE, mostly because it's more primitive and not as capable ( that's aside from those who are just annoyed about their investment in Altivec going down the tubes ). I haven't really seen anyone getting excited about double precision in SSE. Could be because of the audience for that isn't really the same as the Altivec programmers I'm aware of, but when you consider there are quite a lot of scientific users on Mac already perhaps it isn't a big deal ? I'd be interested to hear if anyone is planning to change to OS X on Intel just because SSE can do double precision floats.
Regards,
Jo Meder
At least with Intel chips the whole performance question goes away. I don't think that for general purposes there is going to be a time when PPC has a clear and maintainable lead over Intel, not enough to justify sticking it out. I work on graphics software. I look forward to seeing a number of cross platform graphics apps take a jump forward in performance as optimisations from the Intel side of things also apply to the Mac versions. Don't get me wrong, I like Altivec and all, but I would imagine that most companies have many more people working on Intel optimisations than PPC ones. For our product I've added Altivec optimisations and threaded some parts of the Mac version, whereas the PC version doesn't have anything like this, but when there is only so much time in the day it's hard to justify spending time on new optimisations for a smaller group of users when there is new functionality and such to be added.
As Mac user I'm not really looking forward to the transition, but I think things are in place for it to be as smooth as it can be. Apple are giving developers good information, Rosetta works well for things I have tried it with. Even as a user I would prefer Intel to Cell ( again, if we must make a change ), because at least Intel is an established pretty well known quantity, and we know nothing too drastic is going to happen to them and if they have problems, pretty much everyone else does as well, and not just Apple with Motorola issues or IBM-actually-we-can't-do-3.0GHz problems.
Regards,
Jo Meder
Regards,
Jo Meder
That's also insulting to OpenSSH, come to think of it. You're saying OpenSSH is a pig ? Perhaps you mean "just putting some gilding on the lily" or similar ?
Jo Meder
Wow, that's exactly what I don't want from a desktop application. More applications with inconsistent appearances and behaviours, hooray... I recently helped install a bunch of Windows software on a relative's computer ( after installing a DVD drive for them, much of it was bundled stuff ) and every single app I dealt with had its own custom interface ( varying in crappiness ) which bore very little resemblance to anything else. I've been using computers for a fair old while now and I still had trouble figuring out how to quit some of these apps.
What you're suggesting makes me feel glad I'm not a ( full time ) Windows user...
and Apple's is trying desperately to duplicate Visual Studio with XCode (but failing miserably)
As an Xcode and VS6/VS 2003 user, I can say I don't think Apple is trying to duplicate VS at all. They haven't really made all that many concessions to CodeWarrior users, and have stated many times that they aren't trying to emulate anything with Xcode, just trying to make a good IDE.
In any case, Interface Builder ( part of the Xcode suite ) is the best GUI layout app I have ever used, hands down. It knocks the GUI layout tools of VS-whatever ( including VB ) into a cocked hat. It is better by miles than every other GUI layout app I've used - aforementioned VS environments, REALbasic, Glade, Delphi, wxDesigner, Qt Designer etc.
If you're a Cocoa developer ( which I'm not ), Interface Builder also has a lot of tools for visually connecting UI components to objects, data sources etc.
Straying a bit, but I don't actually understand why people think VS is such a great IDE. I only really use it for C++. VS 6 had me tearing my hair out over a number of UI things which were so awkward compared to what I had been used to ( in CodeWarrior ). VS 2003 improved much of that, but added quirks of its own. The code completion is good, but I don't actually find myself using it all that much. The parameter hints can be useful, but don't always work when they could be handy. I don't find general editing tasks as flexible as I'm used to on the editors I use on the Mac. When I have a lot of code to write, I generally write it in Xcode, even if it's Windows only code, which is far from perfect but which I find myself more productive in. I still have to do a lot in various VS versions, so I think I've given them a fair chance.
One thing I do appreciate about VS is the VBA support which lets me write scripts to automate a bunch of stuff I often have to do. I also have scripts to give the same results in Xcode and CodeWarrior. I find VBA is more flexible ( for various reasons, not necessarily related to the language ) than Perl in Xcode and AppleScript for CodeWarrior.
Jo Meder
I have a 1.5 GHz PB G4. I also had the spinning beachball but I got it in the Spotlight menu, which I found to be unusable if I didn't type fast enough to get a good few letters in before Spotlight started searching. I had to use the Finder Find window if I wanted Spotlight to be useful. However, last night I installed a 1 GB stick of RAM to bring the PB up to 1.5 GB and now everything is hunky dory. Spotlight still isn't as instantly tremendous on this machine as has been suggested, but on my dual 2.7 G5 with 2 GB RAM it's super instantly tremendous. OTOH, I don't have nearly as much on my G5 as I do on my PB at the moment.
People here on /. seem to underestimate the importance of Carbon. There are a lot of developers still using it. It makes a lot of sense for cross platform apps particularly. Cocoa is a good OO framework, but Carbon is a pretty good API as well ( much nicer than Win32 ), especially since the advent of Carbon Events. It used to take pages of code to put up a window, write an event loop and and handle all its basic behaviour ( moving, sizing, zooming, closing etc. ) but now it's less than a page as most ( all ) of the basic behaviour is handled for you by the OS.
Jo Meder
So the apps most people make will probably not see this compiler, except for tuned C code. So it'll probably mostly mean some faster libraries on the Intel macs.
I'm not sure most people use Cocoa to develop for OS X. A lot of people do, but I don't know that it would be half of Mac developers. Most of the important Mac apps ( at least what I consider important in my experience ) are written using Carbon.
Anyway, nothing to stop people moving performance critical code out to a library and compiling it with ICC. My own app has its Altivec code in a shared library/DLL, as that's the safest way to support machines without an Altivec unit ( G3 and earlier ).
Ack, I'm too tired, let me say that again -
:-).
I'm assuming it makes clicking noises rather than squeaking noises
Just about have my own thread going on here... must sleep... zzzz NO CARRIER etc.
I assuming it makes clicking noises rather squeaking noises :-).
The design page says it has a little speaker to provide audible feedback. How exactly that would compare with tactile feedback I'm not sure.
I have one too, but I'm unfortunately not able to use it yet.
Photoshop and the Altivec-intence apps are a LITTLE sluggish, but nothing that a native build won't fix.
Erm, Altivec intense apps won't even run, unless they can fall back to work with pure scalar code. Most would, I'd imagine, but even so. Altivec code just doesn't work on x86. A native build won't fix that either, unless the developer rewrites all the Altivec code for SSE. That's a bit more than just a native build if the app isn't already cross platform with SSE code in place.
You'd better get them to check the fine print of the license again :
The software is licensed per seat(1)...
(1) Seat is defined as sitting apparatus, seat-of-your-pants or as a simile for backside/butt/buns/arse [ covering hippies who might not be wearing pants ].
You might want to get that sorted out before the next BSA audit or your company could be in for a rude surprise ! Actually, if the hippies have no pants on, it might be the auditors who are rudely surprised first, but that doesn't mean you shouldn't make sure you're in total compliance with the license, because it takes more than that to throw off the BSA.
I shall have to make sure our software, which is licensed per seat, adds a clause which requires pants to be worn at all times while using the software, just to avoid embarassment. Nobody should have a problem with that, unless of course they're no-pants-wearing open source hippies, who wouldn't be using our software because of the draconian proprietary pants clause anyway.
Ah, of course, how foolish of me.
Also, tides are caused by special machinery installed for the purpose. ;)
Let me get this straight though - could the giant balloon not also be responsible for the tides ? No need for what would have to be some impressive machinery ( and associated maintenance, salt water can be rough on things ) if it were just a side effect of the giant balloon flying about. Those nuclear reactors would probably have a quite a bit of mass after all.
We also have the moon here in New Zealand. We're pretty liberal already, and we don't have the same issues with guns as the US does, so what could the liberal moon pilots be looking for ?
Food for thought...
Replying is troll feeding, and frankly I'm surprised you spent the energy to type all that out ( unless you're trying to be funny ), but I was reading this just the other day :
Romeo
But soft! What light through yonder window breaks?
It is the east, and Juliet is the sun.
Arise, fair sun, and kill the envious moon
by William Shakespeare, 1597
The bus speed is so greatly improved in the G5s though, 800 MHz and upwards ( half processor clock ), vs 167 MHz max in the G4s that you can get so much more data for the Altivec unit to work on. It's really easy to write Altivec code on a G4 which is memory bound. I don't think Altivec on G5s is so weak that it can be outweighed by the basic ability to get more data to work on more quickly. I haven't seen anyone complaining much about it.
Jo Meder
The IO libs just take care of it.
You're kind of missing all of those Mac apps which were written prior to OS X and those afterwards which are based on Carbon and not Cocoa, or which are pure C/C++. The Cocoa IO libs might handle byte swapping ( in fact they do ) but neither the Carbon IO APIs or the C/C++ standard IO APIs do, and a lot of apps use those. MacOS development != NeXT derived.
Jo Meder
Of course a lot of Mac apps are cross platform already and have sorted out endian issues years ago. With my own app it will just need a few changes to #defines and the Mac Intel version will be ready to go, from an endian-ness perspective anyway.
With regards to NeXT developers, I would have thought the number of old NeXT developers on the Mac since OS X was pretty small compared to the number of seasoned Mac developers who have also been involved in cross platform applications. Most of the Mac apps I've been using for years are cross platform after all.
Jo Meder