Actually I/O intensive applications like a BitTorrent client are really good places to use Java
Hmmm, maybe I got it confused with C++'s iostream vs. C's stdio (iostreams are at a disadvantage since they have to sync with stdio...or at least they use to be, maybe there is an option to turn that off now).
I don't see how this is any better than extending a class and overriding a method or providing a new on as you would in Java
If you use a category add a method to a class in ObjC when someone passes you a object of that class (or I assume a subclass) it has that method and you can use it. If you extend the class in Java and someone passes you an object of the original class you can't use the new method. E.g. even if Java's string class were not final, adding a "encode to UCS-2 and frobnicate any combining marks" method to a subclass wouldn't let you call that method on string people pass you.
In C++ the "way around" that is to use an overloaded non-member function. I don't recall being able to do anything like that in Java though.
Care to name one that I might use (or see in a store for purchase)?
Azerus is one of the leading BitTorrent clients, and is written in Java, which I think is an odd language for an I/O intensive task, but it sure is popular.
FYI, Java is not a language of choice for me, the only thing I've ever done was a ssh (v1) implementation while learning Java, and a little smart card work. It's not a bad language, but when I use it I miss C++'s STL, and when I use C++ boost::shared_ptr and week_ptr (now tr1::shared_ptr) are enough for me to not miss Java's GC.
Also C++ has libraries of things like shared_ptr that do the reference counting in the constructors and destructors of the object. It also can suffer from the cyclic reference leaks of course but the need to double check code or even suspect it of being wrong at the "use" level is greatly diminished.
For data structures with cycles you can use the "non-counting" weak_ptr template. It'll give you a shared_ptr to the managed object, or a NULL shared_ptr if there were no non-weak references. It is also handy for keeping cached things around, or having references that are easier to check for deletion at use time then to track them all down ahead of time.
And, as a slight aside -- complaining about memory allocation in C++ just means you aren't using the tools available! They already mentioned utilizing Boost, so why weren't they using the Boost shared_ptr classes? Wrap any pointers you may be using in them and you'll stop having to worry about new/delete or malloc/free issues. No, it's still not as simple as a true GC, but it's far better than the old ways.
The declaration is more complex, but if you don't have an circular dependencies in your data structures it is otherwise simpler then GC.
You don't have any non-deterministic issues with when the GC fires off which is better for psudo-realtime (and real-realtime) things like a user interface. It is also better for anything that manages a non-memory resource, like locks or space on the GPU, or file descriptors.
The downside is a very good GC is actually faster then reference counting, and can also compact the heap so you don't have fragmentation issues.
Downsides or not, I've stopped having to find memory leak bugs (in my own code at least) since discovering shared_ptr, and I've stopped having bugs with "other" kinds of leaks on the exception path as well. FYI shared_ptr is also available as part of std::tr1 in many more recent C++ compilers.
So go to a professional printing lab instead of the local Mega-Mart
Yeah, but if you have already done all the color tweaking and left nothing for a pro lab to do why would you want to pay pro lab prices?
What you really want is something in between, like a ritz camera or other mass-market photo place that is still a real photo place. Then you can say "you have a fuji frontier 370 right? I've balanced the color for that, so print it as is please" and not have to worry about them undoing your hard work by pressing "auto balance" without even looking at the picture first!
Just as I can't get warranty service on an EOS300 here (it's obviously a foreign model, it's not named that here) she wouldn't be able to get it on the Rebel 2000 there, though the price differential surely more than made up for any loss of warranty
You might be surprised. Canon USA services Canon warranties from other countries, I think they want to hear that the camera was bought on a trip there, or when you lived there, but they do it with no hassle. I don't know that Canon Brazil will be as understanding, but it would be worth a shot if your camera breaks.
If they can't be produced reliably, why would they waste their time mass producing them.
Depends on how they are unreliable. If say 75% of the tubes one a wafer can't be used to store data, but the ones that do work keep working you can map out the bad ones much like you do with bad disk blocks. On the other hand if they come off the line fine but 75% of them die after a month or two, well, there isn't much use for them.
And of corse you need to calculate the cost per bit after the mapping overhead, and make sure that is still cheap enough to be useful.
Juniper uses FreeBSD (they call it 'JunOS'). Their routers have become quite popular for very high traffic installations, due in no small part to the efficient networking code of the FreeBSD kernel.
Juniper uses FreeBSD in the "brain in a box" model. It runs the CLI, and sshd and the routing daemon(s), but it does not directly drive packet routing on (or between) the line cards. That is all Juniper specific code.
That isn't to say FreeBSD's networking stack is bad, just that it wasn't up to the task of dealing with the line rate of several OC-196s when Juniper made their choices (nor was Cisco's IOS)
OkiData had a short lived Unix workstation product line based around these. I used them for a while.
One fairly unique feature of the i860 was that the pipelines into the functional units were program-accessible, requiring the compilers to carefully order instructions in the object code to keep the pipelines filled.
Only the floating point pipeline was directly exposed. Your first two FMULADD got garbage as the result, the third got the result of the first FMULADD... I *think* it also had a mode with more conventional stalling if you tried to do a 2nd FMULADD before the first completed (or if you used the result register).
The i860 also had a mode where you it would execute two instructions per clock, but you had to pair one integer instruction with one floating point instruction in that mode (and the pairing was static, if you put two integer instructions in a row the CPU would fault with an illegal instruction fault).
Paper performance was impressive for a single-chip solution; however, real-world performance was anything but.
It outperformed it's contemparary SPARC and MIPS CPUs by a considrable margin in FP, and by a small margin in integer heavy code. It was competitave with the HP snake systems (HPPA). It predated the Alpha, and was badly outmatched when the Alpha finally came out.
One problem, perhaps unrecognized at the time, was that runtime code paths are difficult to predict, meaning that it becomes exceedingly difficult to properly order instructions at compile time. For instance, an instruction to add two numbers will take considerably longer if the data is not in the cache, yet there is no way for the programmer to know if it is or not. If you guess wrong the entire pipeline will stall, waiting for the data.
That was extremely common at the time. The best the contemporary CPUs had was the IBM ROMP (pre-IBM POWER!) that had register scoreboarding so it didn't take a stall until the result register was used. It wasn't until five to seven years later that out-of-order CPUs were commercially available (and I can't remember who did them first, maybe the TI SuperSPARC? Or was it the MIPS R8000?)
Another serious problem was the lack of any solution to quickly handle context switching. The i860 had several pipelines (for the ALU and FPU parts) and an interrupt could spill them and need them all to be re-loaded. This took 62 cycles in the best case, and almost 2000 cycles in the worst. The latter is 1/20000th of a second, an eternity for a CPU. This largely eliminated the i860 as a general purpose CPU.
It seemed of handling disk interrupts, mouse movement, and even the relatively tiny FIFO for SoundBlaster 16 audio out. Maybe this was more a problem in theory then in practice? Clearly the i860 never got far in the embedded space though, and this couldn't have possibly helped.
The i860 did see some use in the workstation world as a graphics accelerator. It was used, for instance, in the NeXTDimension, where it ran a cut-down version of the Mach kernel running a complete PostScript. In this role the i860 design worked considerably better, as the core program could be loaded into the cache and made entirely "predictable", allowing the compilers to get the ordering right. This sort of use slowly disappeared as well, as more general-purpose CPUs started to match the i860's performance, and Intel lost interest.
I think it was also used as part of the "geometry engine" on SGI's Reality Engine product. There were something like 4 per GE, and up to 4 GEs on a Reality Engine, which was pretty impressive in 1991ish, but other then having something like 196 bits of memory per pixel falls pretty far short of today's $100 graphics cards.
"run on SPARC, which is a poorly designed processor"
I know this is Slashdot, but do you have anything to back this up. Everything I have read about SPARC seems to suggest that it is a very well designed processor although manufacturers seem to have failed to push uit to the MHz that Intel and AMD have achieved.
There isn't anything really poorly designed about the SPARC, which isn't to say it doesn't have some things nobody would put in a new CPU. For example it is one of only 2 commercial RISC CPUs with register windows (the other being the ill-fated AMD 29k), so I doubt anyone would do that again. It has (optional) branch delay slots, which were a win for a few years, but on OOO CPUs you can get the same gain without the pain. It also has a MULSTEP instruction, which is pretty much a waste when you have the transistor budget for a real multiplier.
All of those can be forgiven as either actually a good idea in the late 80s, or at least not a known to be bad idea. Even the much maligned register stack was a pretty effective cache with way fewer transistors for a while there.
SPARC hasn't suffered because it was a crap design, it has suffered because it doesn't have the same volumes the x86 does, so Intel putting $0.02 per CPU back into R&D gets it a bigger R&D budget then Sun pouring $1000 per CPU back into R&D. Disclaimer: I made those numbers up. Totally invented.
The result was that the 1984 Macintosh had an operating system that looked almost 100% identical to the 1981 Xerox Star
FYI the Star I'm pretty sure had a multibuttion mouse. The Star did not have a menu bar (it only had context menus). I also think it didn't have a Finder, or even what appeared to be separate applications, it featured a system more like OpenDoc or CyberDog.
That's not to say Jef Raskin and crew didn't get a lot of ideas from the Star (I do believe Apple payed for them), but some of the things people think they copied from the star were original to the Mac, or at the very least invented again for the Mac after being on something else. Some of the things were clear improvements (menu bar for example), and some were because the original Mac didn't have the horsepower to do what the Star did (individual applications).
That's one thing I'd like to get more information about, actually. How exactly are they extending webcore and how much have they opened up for Safari.
I don't know, the dev docs other have pointed to might shed some light on it. There are also tidbits in Dave Haytt's blog, including the statement that "This plugin will not be present in Safari or other WebKit applications, and is only accessible from Dashboard".
So it is my guess that while Dashboard is a WebCore app, it and it alone has the stuff that let you bridge JavaScript to Cocoa, which makes it far far harder to attack someone with it via Safari or Mail.
The weather and flight tracking applets don't ship with Panther.
They were in Sherlock. As far as I know they still are.
Yes, right now I don't know of any Dashboard widgets for which there is no third-party alternative... but just wait. Dashboard is going to be like Hypercard. People will do all kinds of things in Dashboard just because scripting is so easy
Well that one I agree with. However any dashboard that doesn't have cocoa or applescript parts will all run in Safari without any alteration (that I know of). I would expect it won't be hard for a 3rd party to make something to let you run your choice of widgets as "standalone" apps.
No, but I do need to have that kind of thing in the corner of my eye when I'm working at a colo or other field location where there aren't any windows
Well that one I think you don't want the widget version of the weather thing, you would want a tiny little menu bar version, or a docklet. The dashboard version is big and distracting, which is fine for a widget that only shows up when you ask for it, but not so good for a "corner of the eye" thing.
o this leaves the question of what to do for the install. I suppose I could put the DVD in my G4 MDD machine and boot it in Target Disk Mode, see if I can boot the G3 from the remote DVD which would be seen as an attached FireWire disk.
That's how I got my G3 PowerBook installed (it has a DVD drive, but the drive has gone south).
Or maybe I should just leave the G3 on Panther, since it's being used as a server and might not benefit much from all the GUI gizmos in Tiger.
What and miss out on the spotlight CLI tools, ACL support, and command line resource fork (er, extended attribute) support?
Spotlight's back end has also been around since MacOS 8.5 when Sherlock was introduced. Content indexing has existed in various forms since then and I happen to use it all of the time. Spotlight basically takes content and metadata indexing and puts a swank front end on it.
Plus the data is indexed as it is written rather then once a day/week/whatever. So you can do a spotlight search and find a file you made this morning, or have a smart folder and things pop into it as soon as you change them rather then the next day. It makes a significant usability difference -- the search goes from something that can sometimes locate your stuff to the thing that always finds it. Plus it is actually fast.
I don't think most of Apple's consumer base (me included) will ever see performance benefit from the G5 over the G4 in the near future.
I have a dual 1.25Ghz G4 PowerMac, and a dual 2.0Ghz G5 PowerMac. The G5 is somewhere between 5 and 10 times faster then the G4 for my daily tasks (which are pretty much just doing compile/link). So I would say at least some of Apple's consumer base will see a pretty big improvement. I don't know if it is because the G5's CPU is more efficient, or the memory bandwidth is better, or what, but it is a significant difference. (I do know it isn't the disk subsystem because I've been using an external firewire drive, and swapped the same one between the two systems because I didn't expect that level of speed up!).
If you don't want to upgrade, don't upgrade. I don't recall Steve going to IT departments with a Louisville Slugger whackin' kneecaps of people who don't upgrade.
Well, I was attempting to explain the original poster's point. It looked like folks didn't believe there is any downside to an OS upgrade. I felt compelled to point out that even if the base reasons are kind of weak, the number of people complaining about minor changes does consume IT resources, and once summed up really is something to think about when deciding when/if to upgrade.
Personally my rollout schedule is seldom dictated by "fear of the new", but I have far fewer systems to deal with then IT departments (my laptop, my wife's laptop, and the home server).
This is such a non-issue. My IT rollout schedule is not dictated by vendors, ever
No, although the longer you don't upgrade the OS the more software packages won't run, or won't have all the features (it is more common in OSX for a program to disable some features then to refuse to run). That probably isn't a huge deal since if you are afraid to upgrade the OS you ought to be at least as afraid to upgrade your applications.
More importantly though is how long the vender promises security updates. I don't know Apple's policy. I seem to recall something about 2 releases, if so they are kind of dictating a 3 year cycle (or if 3 releases, a 4.5 year cycle). Exactly how strongly that influences IT policy would depend on how much the IT department thinks their firewalls and mail scrubbers and the like protect them.
I would assume there is also an element of how long the vender will sell you the old OS (assuming you are buying new computers that come with the new OS and you need to "downgrade" to match), or at the very least how long the vender ships computers that can still run the old OS. Since I don't personally run the old OS for very long after a new one is released, I can't even guess at wether is is a real issue, or just theoretical.
Do you have anything that substantiates your contention that you'd have to re-develop your app every year and a half?
He didn't say he had to re-develop his app with every OS release, he said he gets calls from all his users when he upgrades the OS. That could be because a keyboard short cut was changed, or maybe an app added a keyboard shortcut so the shortcut from the services menu is overridden. Or the user is use to clicking "that little picture in the upper right" which "changed into a magnifying thingie, a blue one, does that do the same thing?".
When I use to work in the help desk at the UofMD we would get lots of calls about broken stuff after each upgrade. Sometimes we announced an upgrade, but for one reason or another we couldn't fit it into the service window so it didn't get done. We still got lots of calls about broken stuff after the non-updates too. I guess people either look around for busted stuff after an upgrade, or they call in with stuff that has been "broken forever" but claim "it worked before the upgrade" just to get the help.
I think it is a shame because it tends to make IT departments hesitant to change things until there is "enough" to make it worthwhile, which means when the changes come they are huge and then reenforce the opinions of some folks that "change is bad". More smaller changes would actually be a good thing for most people.
Clearly, however, I don't decide OS release schedules for Apple, or OS upgrade schedules for the worlds IT departments.
C++ memory management has a form of "GC" which is usually done via reference counting, auto_ptr's, etc.
The auto_ptr isn't really reference counting. It is more of a "pointer with ownership passing". Anytime you do "x = y" with an auto_ptr it is really "x = y; y = NULL;". The auto_ptr has the advantage of being cheap. It has the significant disadvantage of being really confusing, and only sometimes being what you want (and not working as the contents of most STL containers).
There is no standard C++ reference counting smart pointer. Boost's shared_ptr has been proposed as one for the next round of C++ library standards (and may even have been accepted), but it isn't in the current C++ standard, so it isn't universally available.
It'll be nice when shared_ptr gets into common use because weather or not it faster then GC, it sure beats the hell out of trying to figure out when you should free something, when you can't free it, and when you need to make and track a private copy because someone else will free it.
Rather, why not teach C and the good practices in C that let you avoid those security issues?
Because the constant high level of care and attention that needs to be payed is pretty much impossible to sustain forever.
Look at how many buffer overruns there have been in ftpd. I think even OpenSSH has had one, but I might be confusing that with an integer overflow that had a privilege escalation effect.
If you look at the last years worth of CERT advisories I'll bet over half of them wouldn't have happened with a bounds checked safe pointer language.
My concern is that if you lower the bar, so to speak, then the next generation of programmers will be more mediocre.
I doubt it. Or at least I hope you are wrong, because we have already added function prototypes to C and I'll bet most modern C programmers aren't as good at finding "type width errors" as people that programed pre-C89 systems. In fact I'm pretty sure I'm not as good at that as I was in 1987. My compiler spots them, so I have stopped looking. I suspect I'm using that little bit of attention for something else, I couldn't really say what.
But if it is true that having the language take care of nitpicky details makes people worse programmers then we are in trouble. I mean very few people still code in assembly any more, and none of them deal with laying out instruction addresses so the drum has rotated to almost the right spot anymore...
We must be an awful lot worse at this programing stuff then the folks in the 1950s were.
Or maybe we have more time to spend on other parts of the art of programming. Or maybe just in writing more programs. Or solving more complex problems.
Interesting... can you give some examples of the extra overhead? C++ advocates (including Stroustrup) usually claim that apart from the runtime support for exceptions, which can be turned off with many compilers, C++ has the same minimum overhead as C.
I can't speak for idlike, but I can't think of any C++ overhead that isn't related to virtual functions. If you avoid them, you avoid the overhead. You also avoid most of C++ though. Oh, and to a smaller extent the same is true of templates, but replace "overhead" with "code bloat", and "debugger nightmares", and "symbol table overhead".
Virtual functions with normal run time systems give you a pointer's worth of overhead per allocated object (class/union/struct) that has a virtual function, and then another pointer or more (function pointer, or maybe a jump instruction plus a target address) per defined object type. Then there is a little more overhead for typeid support and similar things (structs/classes with no virtual functions have no overhead, and also no typeid support).
If you were going to code up virtual pointer like things in C you would probably get the same sort of overhead, even if you just keep a "type byte" in the object, and then use a switch to manage the dispatch. If you do that more then once you likely have more overhead then the normal C++ way.
However normal C coding style won't lead you to doing that very much. Normal C++ coding style will lead you to doing a fair bit of that sort of thing. You can't really blame the language for that.
As for templates, I firmly believe that C++ could do a much better job there (for example recognizing that some templates or even template functions only vary depending on the size of a type, and using the same expansion for anything with the same sizes). So the code bloat might just go away with smarter compilers.
Personally I use C++ rather then C when given the choice, and if performance is likely to be a big issue I try to be careful about how many of my classes or structs have any virtual functions at all. However since "time to write and debug" is always an issue I don't shy away from templates, even if it is just boost's shared_ptr template.
Same reason we have laws protecting personal property: Because respect for other people's stuff is a core value in our culture.
According to the constitution, it is:
To promote the Progress of Science and useful Arts, by securing for limited Times to Authors and Inventors the exclusive Right to their respective Writings and Discoveries
In other words to give authors and inventors an incentive to continue authoring and inventing.
Implicit in that statement is (to me anyway) that congress does not have the power to secure the rights in such a way that they are detrimental to the progress of science and the useful arts. I haven't seen a court uphold that argument though (nor have I really seen anyone struggle hard to make it)
Nothing to do with core values. In fact we explicitly rejected the patents and copyrights on foreign inventions and music and the like for a very long time.
Slashdot Mirror
Hmmm, maybe I got it confused with C++'s iostream vs. C's stdio (iostreams are at a disadvantage since they have to sync with stdio...or at least they use to be, maybe there is an option to turn that off now).
If you use a category add a method to a class in ObjC when someone passes you a object of that class (or I assume a subclass) it has that method and you can use it. If you extend the class in Java and someone passes you an object of the original class you can't use the new method. E.g. even if Java's string class were not final, adding a "encode to UCS-2 and frobnicate any combining marks" method to a subclass wouldn't let you call that method on string people pass you.
In C++ the "way around" that is to use an overloaded non-member function. I don't recall being able to do anything like that in Java though.
Azerus is one of the leading BitTorrent clients, and is written in Java, which I think is an odd language for an I/O intensive task, but it sure is popular.
FYI, Java is not a language of choice for me, the only thing I've ever done was a ssh (v1) implementation while learning Java, and a little smart card work. It's not a bad language, but when I use it I miss C++'s STL, and when I use C++ boost::shared_ptr and week_ptr (now tr1::shared_ptr) are enough for me to not miss Java's GC.
For data structures with cycles you can use the "non-counting" weak_ptr template. It'll give you a shared_ptr to the managed object, or a NULL shared_ptr if there were no non-weak references. It is also handy for keeping cached things around, or having references that are easier to check for deletion at use time then to track them all down ahead of time.
The declaration is more complex, but if you don't have an circular dependencies in your data structures it is otherwise simpler then GC.
You don't have any non-deterministic issues with when the GC fires off which is better for psudo-realtime (and real-realtime) things like a user interface. It is also better for anything that manages a non-memory resource, like locks or space on the GPU, or file descriptors.
The downside is a very good GC is actually faster then reference counting, and can also compact the heap so you don't have fragmentation issues.
Downsides or not, I've stopped having to find memory leak bugs (in my own code at least) since discovering shared_ptr, and I've stopped having bugs with "other" kinds of leaks on the exception path as well. FYI shared_ptr is also available as part of std::tr1 in many more recent C++ compilers.
Yeah, but if you have already done all the color tweaking and left nothing for a pro lab to do why would you want to pay pro lab prices?
What you really want is something in between, like a ritz camera or other mass-market photo place that is still a real photo place. Then you can say "you have a fuji frontier 370 right? I've balanced the color for that, so print it as is please" and not have to worry about them undoing your hard work by pressing "auto balance" without even looking at the picture first!
You might be surprised. Canon USA services Canon warranties from other countries, I think they want to hear that the camera was bought on a trip there, or when you lived there, but they do it with no hassle. I don't know that Canon Brazil will be as understanding, but it would be worth a shot if your camera breaks.
Depends on how they are unreliable. If say 75% of the tubes one a wafer can't be used to store data, but the ones that do work keep working you can map out the bad ones much like you do with bad disk blocks. On the other hand if they come off the line fine but 75% of them die after a month or two, well, there isn't much use for them.
And of corse you need to calculate the cost per bit after the mapping overhead, and make sure that is still cheap enough to be useful.
Juniper uses FreeBSD in the "brain in a box" model. It runs the CLI, and sshd and the routing daemon(s), but it does not directly drive packet routing on (or between) the line cards. That is all Juniper specific code.
That isn't to say FreeBSD's networking stack is bad, just that it wasn't up to the task of dealing with the line rate of several OC-196s when Juniper made their choices (nor was Cisco's IOS)
OkiData had a short lived Unix workstation product line based around these. I used them for a while.
Only the floating point pipeline was directly exposed. Your first two FMULADD got garbage as the result, the third got the result of the first FMULADD... I *think* it also had a mode with more conventional stalling if you tried to do a 2nd FMULADD before the first completed (or if you used the result register).
The i860 also had a mode where you it would execute two instructions per clock, but you had to pair one integer instruction with one floating point instruction in that mode (and the pairing was static, if you put two integer instructions in a row the CPU would fault with an illegal instruction fault).
It outperformed it's contemparary SPARC and MIPS CPUs by a considrable margin in FP, and by a small margin in integer heavy code. It was competitave with the HP snake systems (HPPA). It predated the Alpha, and was badly outmatched when the Alpha finally came out.
That was extremely common at the time. The best the contemporary CPUs had was the IBM ROMP (pre-IBM POWER!) that had register scoreboarding so it didn't take a stall until the result register was used. It wasn't until five to seven years later that out-of-order CPUs were commercially available (and I can't remember who did them first, maybe the TI SuperSPARC? Or was it the MIPS R8000?)
It seemed of handling disk interrupts, mouse movement, and even the relatively tiny FIFO for SoundBlaster 16 audio out. Maybe this was more a problem in theory then in practice? Clearly the i860 never got far in the embedded space though, and this couldn't have possibly helped.
I think it was also used as part of the "geometry engine" on SGI's Reality Engine product. There were something like 4 per GE, and up to 4 GEs on a Reality Engine, which was pretty impressive in 1991ish, but other then having something like 196 bits of memory per pixel falls pretty far short of today's $100 graphics cards.
There isn't anything really poorly designed about the SPARC, which isn't to say it doesn't have some things nobody would put in a new CPU. For example it is one of only 2 commercial RISC CPUs with register windows (the other being the ill-fated AMD 29k), so I doubt anyone would do that again. It has (optional) branch delay slots, which were a win for a few years, but on OOO CPUs you can get the same gain without the pain. It also has a MULSTEP instruction, which is pretty much a waste when you have the transistor budget for a real multiplier.
All of those can be forgiven as either actually a good idea in the late 80s, or at least not a known to be bad idea. Even the much maligned register stack was a pretty effective cache with way fewer transistors for a while there.
SPARC hasn't suffered because it was a crap design, it has suffered because it doesn't have the same volumes the x86 does, so Intel putting $0.02 per CPU back into R&D gets it a bigger R&D budget then Sun pouring $1000 per CPU back into R&D. Disclaimer: I made those numbers up. Totally invented.
There is a FedEx Tracker dashboard widget already. Probably more then one even. No minesweeper that I've been able to find yet.
FYI the Star I'm pretty sure had a multibuttion mouse. The Star did not have a menu bar (it only had context menus). I also think it didn't have a Finder, or even what appeared to be separate applications, it featured a system more like OpenDoc or CyberDog.
That's not to say Jef Raskin and crew didn't get a lot of ideas from the Star (I do believe Apple payed for them), but some of the things people think they copied from the star were original to the Mac, or at the very least invented again for the Mac after being on something else. Some of the things were clear improvements (menu bar for example), and some were because the original Mac didn't have the horsepower to do what the Star did (individual applications).
I don't know, the dev docs other have pointed to might shed some light on it. There are also tidbits in Dave Haytt's blog, including the statement that "This plugin will not be present in Safari or other WebKit applications, and is only accessible from Dashboard".
So it is my guess that while Dashboard is a WebCore app, it and it alone has the stuff that let you bridge JavaScript to Cocoa, which makes it far far harder to attack someone with it via Safari or Mail.
They were in Sherlock. As far as I know they still are.
Well that one I agree with. However any dashboard that doesn't have cocoa or applescript parts will all run in Safari without any alteration (that I know of). I would expect it won't be hard for a 3rd party to make something to let you run your choice of widgets as "standalone" apps.
Well that one I think you don't want the widget version of the weather thing, you would want a tiny little menu bar version, or a docklet. The dashboard version is big and distracting, which is fine for a widget that only shows up when you ask for it, but not so good for a "corner of the eye" thing.
That's how I got my G3 PowerBook installed (it has a DVD drive, but the drive has gone south).
What and miss out on the spotlight CLI tools, ACL support, and command line resource fork (er, extended attribute) support?
Plus the data is indexed as it is written rather then once a day/week/whatever. So you can do a spotlight search and find a file you made this morning, or have a smart folder and things pop into it as soon as you change them rather then the next day. It makes a significant usability difference -- the search goes from something that can sometimes locate your stuff to the thing that always finds it. Plus it is actually fast.
I have a dual 1.25Ghz G4 PowerMac, and a dual 2.0Ghz G5 PowerMac. The G5 is somewhere between 5 and 10 times faster then the G4 for my daily tasks (which are pretty much just doing compile/link). So I would say at least some of Apple's consumer base will see a pretty big improvement. I don't know if it is because the G5's CPU is more efficient, or the memory bandwidth is better, or what, but it is a significant difference. (I do know it isn't the disk subsystem because I've been using an external firewire drive, and swapped the same one between the two systems because I didn't expect that level of speed up!).
Well, I was attempting to explain the original poster's point. It looked like folks didn't believe there is any downside to an OS upgrade. I felt compelled to point out that even if the base reasons are kind of weak, the number of people complaining about minor changes does consume IT resources, and once summed up really is something to think about when deciding when/if to upgrade.
Personally my rollout schedule is seldom dictated by "fear of the new", but I have far fewer systems to deal with then IT departments (my laptop, my wife's laptop, and the home server).
No, although the longer you don't upgrade the OS the more software packages won't run, or won't have all the features (it is more common in OSX for a program to disable some features then to refuse to run). That probably isn't a huge deal since if you are afraid to upgrade the OS you ought to be at least as afraid to upgrade your applications.
More importantly though is how long the vender promises security updates. I don't know Apple's policy. I seem to recall something about 2 releases, if so they are kind of dictating a 3 year cycle (or if 3 releases, a 4.5 year cycle). Exactly how strongly that influences IT policy would depend on how much the IT department thinks their firewalls and mail scrubbers and the like protect them.
I would assume there is also an element of how long the vender will sell you the old OS (assuming you are buying new computers that come with the new OS and you need to "downgrade" to match), or at the very least how long the vender ships computers that can still run the old OS. Since I don't personally run the old OS for very long after a new one is released, I can't even guess at wether is is a real issue, or just theoretical.
He didn't say he had to re-develop his app with every OS release, he said he gets calls from all his users when he upgrades the OS. That could be because a keyboard short cut was changed, or maybe an app added a keyboard shortcut so the shortcut from the services menu is overridden. Or the user is use to clicking "that little picture in the upper right" which "changed into a magnifying thingie, a blue one, does that do the same thing?".
When I use to work in the help desk at the UofMD we would get lots of calls about broken stuff after each upgrade. Sometimes we announced an upgrade, but for one reason or another we couldn't fit it into the service window so it didn't get done. We still got lots of calls about broken stuff after the non-updates too. I guess people either look around for busted stuff after an upgrade, or they call in with stuff that has been "broken forever" but claim "it worked before the upgrade" just to get the help.
I think it is a shame because it tends to make IT departments hesitant to change things until there is "enough" to make it worthwhile, which means when the changes come they are huge and then reenforce the opinions of some folks that "change is bad". More smaller changes would actually be a good thing for most people.
Clearly, however, I don't decide OS release schedules for Apple, or OS upgrade schedules for the worlds IT departments.
The auto_ptr isn't really reference counting. It is more of a "pointer with ownership passing". Anytime you do "x = y" with an auto_ptr it is really "x = y; y = NULL;". The auto_ptr has the advantage of being cheap. It has the significant disadvantage of being really confusing, and only sometimes being what you want (and not working as the contents of most STL containers).
There is no standard C++ reference counting smart pointer. Boost's shared_ptr has been proposed as one for the next round of C++ library standards (and may even have been accepted), but it isn't in the current C++ standard, so it isn't universally available.
It'll be nice when shared_ptr gets into common use because weather or not it faster then GC, it sure beats the hell out of trying to figure out when you should free something, when you can't free it, and when you need to make and track a private copy because someone else will free it.
Because the constant high level of care and attention that needs to be payed is pretty much impossible to sustain forever.
Look at how many buffer overruns there have been in ftpd. I think even OpenSSH has had one, but I might be confusing that with an integer overflow that had a privilege escalation effect.
If you look at the last years worth of CERT advisories I'll bet over half of them wouldn't have happened with a bounds checked safe pointer language.
I doubt it. Or at least I hope you are wrong, because we have already added function prototypes to C and I'll bet most modern C programmers aren't as good at finding "type width errors" as people that programed pre-C89 systems. In fact I'm pretty sure I'm not as good at that as I was in 1987. My compiler spots them, so I have stopped looking. I suspect I'm using that little bit of attention for something else, I couldn't really say what.
But if it is true that having the language take care of nitpicky details makes people worse programmers then we are in trouble. I mean very few people still code in assembly any more, and none of them deal with laying out instruction addresses so the drum has rotated to almost the right spot anymore...
We must be an awful lot worse at this programing stuff then the folks in the 1950s were.
Or maybe we have more time to spend on other parts of the art of programming. Or maybe just in writing more programs. Or solving more complex problems.
I can't speak for idlike, but I can't think of any C++ overhead that isn't related to virtual functions. If you avoid them, you avoid the overhead. You also avoid most of C++ though. Oh, and to a smaller extent the same is true of templates, but replace "overhead" with "code bloat", and "debugger nightmares", and "symbol table overhead".
Virtual functions with normal run time systems give you a pointer's worth of overhead per allocated object (class/union/struct) that has a virtual function, and then another pointer or more (function pointer, or maybe a jump instruction plus a target address) per defined object type. Then there is a little more overhead for typeid support and similar things (structs/classes with no virtual functions have no overhead, and also no typeid support).
If you were going to code up virtual pointer like things in C you would probably get the same sort of overhead, even if you just keep a "type byte" in the object, and then use a switch to manage the dispatch. If you do that more then once you likely have more overhead then the normal C++ way.
However normal C coding style won't lead you to doing that very much. Normal C++ coding style will lead you to doing a fair bit of that sort of thing. You can't really blame the language for that.
As for templates, I firmly believe that C++ could do a much better job there (for example recognizing that some templates or even template functions only vary depending on the size of a type, and using the same expansion for anything with the same sizes). So the code bloat might just go away with smarter compilers.
Personally I use C++ rather then C when given the choice, and if performance is likely to be a big issue I try to be careful about how many of my classes or structs have any virtual functions at all. However since "time to write and debug" is always an issue I don't shy away from templates, even if it is just boost's shared_ptr template.
According to the constitution, it is:
In other words to give authors and inventors an incentive to continue authoring and inventing.
Implicit in that statement is (to me anyway) that congress does not have the power to secure the rights in such a way that they are detrimental to the progress of science and the useful arts. I haven't seen a court uphold that argument though (nor have I really seen anyone struggle hard to make it)
Nothing to do with core values. In fact we explicitly rejected the patents and copyrights on foreign inventions and music and the like for a very long time.
I think IE has added a JavaScript library to do XML manipulations which Safari doesn't have.