Well, not exactly. Here is the scoop as far as I can tell. The line mode browser and the NeXT browser apparently were developed simultaneously. The line mode browser seems to have been released a little earlier, and in any case, was the only browser most people would see until Mosaic came out. See here for a timeline.
There's one problem with your logic. To my knowledge, Gamespy still doesn't actually own the source to Gamespy3D, to which I believe these security holes refer. That codebase is owned by the original coders of Quakespy, the program that got the company started.
If Gamespy has managed their software licensing so incompetently that they can't fix bugs in what they ship, that's their problem. They should go out of business and be replaced by a company that can put out products that don't endanger the security of my computer. Trying to suppress reporting of those bugs is not an acceptable response.
What this really shows us again is what a horrendous security mess closed source software is. We really need to replace that kind of junk with software we can trust.
You can do that with OpenGL too. You need a few extensions (namely, rectangular textures) but that's it.
Where exactly does OpenGL specify pixel-accurate rendering semantics? And which OpenGL implementations actually guarantee conformance?
Note that being able to put up a texture pixel-by-pixel is not the same as having hardware accelerated line drawing or circles with pixel-accurate semantics.
Where in the heck are you getting this text web browser thing? Or are you making this up as you go along?
The way most people were able to access the web initially was through a line mode browser from CERN. Turns out, it was developed almost concurrently with the NeXT-based one. I thought the NeXT browser was actually a few months later. Certainly, very few people would have been able to run the NeXT-based browser.
In any case, I suspect the point of that claim that it was "first" was probably that NeXT was a good platform to develop innovative GUI apps on, which is quite true. But that was in 1989. Today, there are better choices available than Objective-C and DisplayPostscript.
but [Venti is] only loosely related to and by no means the same as what I was talking about...
Well, golly, gee, and it isn't at all related to what I was talking about. So why do you keep bringing it up?
Saying Venti is block-level when it only works with one filesystem and OS is like saying that a libc hack is the same as a real distributed filesystem;
Between the terminology of some experienced Bell Labs researchers and you, frankly, I give precedence to their choice of terminology. If you think your product distinguishes itself, call it something different.
and you were still not quite telling the truth when you said nobody found it useful.
Look up the word "hyperbole" in the dictionary. Better yet, look up the words "get a clue".
IMO, Objective-C is actually a much nicer and more consistent OOL than C++. The syntax is a little oddball, but ultimately no big deal, and the method naming actually helps.
What kills Objective-C in my opinion is that its resource management is a kludgy mess. Java and C# have bullet proof and worry-proof resource management, and in C++ you can get it if you know what you are doing. But in Objective-C, resource management and exception handling are as flaky and cumbersome as in C (Objective-C has lots of library support for it, but that doesn't help much).
Objective-C could have a renaissance if Apple updates it for the 21st century. Foremost, it needs some runtime safety and some garbage collection. Something like the Tom language. But in its current form, it will fade from view.
Why not? I helped build a whole GUI toolkit out of OpenGL primitives, and didn't find anything lacking.
Because many 2D applications need graphics primitives with precise guarantees for pixel placement and pixel values, features that are not very important for 3D applications. For example, you may want 2D line drawing to guarantee that if you draw two one-pixel-wide lines at the same slope one pixel shifted relative to one another, they line up correctly. Or you might want guarantees that a rendering operation only renders pixels with exactly the RGB values you specified or that it stays precisely within some bounding box, guarantees that 3D hardware may not necessarily give you.
So, yes, you can build nice looking UIs on top of OpenGL and you can get many applications to work on top of it. But, ultimately, the requirements for 2D and 3D graphics rendering are somewhat different and the hardware reflects that. Whether that will matter in the long term, I don't know. But today, it still does.
Then why are so many more people going with Gnome and KDE? Why don't more people just support the GNUstep people instead?
Easy: while a lot of people like the look of the Mac, they don't like the underlying technologies: DisplayPDF and Objective-C. Personally, I think those technologies are obsolete, inefficient, and cumbersome.
I think adding transparency to X11 is a technically much better solution. It is language neutral and transport agnostic. It also has the virtue of being backwards compatible. And it doesn't require people to throw away their existing X11 software--there is a lot more X11 software than OpenStep or Apple software.
X11 will also get server-side stored vector graphics based on SVG. Again, same functionality as DisplayPDF but more standards compliant and a better design.
Also, OpenStep exists as a standard so it sure will make easier to port commercial applications written in Cocoa to the Unix world.
In what sense do you believe OpenStep is a "standard"? Where are the standards documents? Where can you even get an implementation?
It seems that right now, we have GNUstep and Cocoa, two similar but incompatible implementations, together with some copyrighted API documents.
Note, incidentally, that few of the features that make the Macintosh API visually appealing (shadows, transparency, etc.) were pioneered by Apple, and historically were implemented without anything like Apple's software infrastructure.
I think a really fast way of getting this in the hands of programmers would be to make a VNC version of this server. I may be reluctant to replace my regular development desktop with it, but developing against a VNC server with alpha transparency would be fine.
X11 isn't like the stuff Microsoft or Apple churn out. Microsoft and Apple just hack something together, throw it out, and call it a "standard API". It's easy. It's quick to market. And it locks people into proprietary APIs and has all sorts of other problems.
X11 is a protocol, not an implementation. As part of defining protocol extensions, people build a reference implementation of the protocol extension. It makes perfect sense to build the reference implementation in software. Hardware vendors and implementors can then build hardware accelerated versions of it and compare it with the software implementation.
This approach has worked very well. It means that X11 has remained backwards and forwards compatible over more than a decade and that X servers have been able to take advantage of new hardware technologies as they have come out.
Note that Apple is not using the "innate RGBA capabilities of the video card" to its fullest extent either. Furthermore, even good 3D cards may not do the right thing for 2D rendering--2D desktop rendering is not simply a subset of 3D rendering.
Obviously, no sane mammal should ever rely on something as silly as two-legged locomotion with dynamic stabilization. If either one of your legs were to fail, you'd fall down, probably breaking something and being eaten by the next carnivore passing by--absolutely deadly. To avoid falling, you'd have to control your legs with incredible precision--you would need a brain bigger than the size of a pea and much of your muscle mass would have to move to the legs. And then just look how high your body would be above your legs: if you are running and try to stop, unless you stop very gradually, you are just going to tumble over head over heels--highly dangerous. You can't even stand up still without a dangerous balancing act--how are you even going to sleep?
I'm telling you: two-legged locomotion with dynamic stabilization is just never going to make it. Any mammal that follows down that path is going to become extinct instantaneously. Don't be stupid--be a four-legged mammal. It's safe. It's stable. Mooo.
but I certainly hope that intentionally unstable vehicle designs with no fault-tolerance are NOT the norm in 2050.
There almost certainly is fault tolerance, it just isn't mechanical. There are plenty of devices like that people use every day: elevators, helicopters, some modern airplanes.
Even cars have single-points-of-failure, where a single defect will kill you; yes, you can usually survive the motor cutting out, but even a blown out wheel can kill you. Oh, and let's not forget the biggest single-point-of-failure: the hamburger-eating, cell-phone-speaking, map-reading, make-up-on-putting mom driving around in an SUV with three screaming kids behind her.
This is one of those instances, I think, where just because you can doesn't mean you should.
Maybe, maybe not. As a recreational vehicle, it seems no worse than a lot of other vehicles. As transportation, it doesn't seem much worse than other modes of transportation.
but I certainly hope that intentionally unstable vehicle designs with no fault-tolerance are NOT the norm in 2050.
I hope that individually owned, powered transportation will itself go away by 2050--it's wasteful, inefficient, inconvenient, unsafe, and expensive, no matter what vehicle you use. A much better choice, IMO, is personal rapid transit, which essentially gives you the comfort of a personal driver without the cost or hassles.
Venti. Filesystem-level, research project, and it was Plan 9 not UNIX. In other words, pretty much totally unlike what I was talking about.
Venti is described as a "block-level" system. Yes, it uses different technology from the buzzword-laden approach you are taking, although it doesn't sound like your user experience will be any better. And, no, it's not what I was talking about. Venti is only one of several such systems at Bell Labs.
What I had used is described in "Sean Quinlan. A cached WORM file system. Software---Practice and Experience, 21(12):1289--1299, December 1991.". While the server ran on Plan 9, it was exported to Research UNIX systems, which is where I think most real users used it.
Furthermore, others have already mentioned it on this very thread and said it was useful to them, putting the lie to your claim that it's not useful.
Yes, probably in the same sense that the other systems you talk about are "useful" to someone: mostly people with deep pockets looking for a silver bullet to intrinsically hard data management problems. Hey, your company may have a market there as well--silver bullet sales are up again.
Nice troll, kid.
I'm always grateful for compliments about my youthful appearance. Now, go back read some research papers on file systems, replication, and versioning--you really seem to need it.
Yes, but it's trivial to run [rsync] twice, once in each direction, with arguments that result in updates propagating in both directions.
Yeah, it will propagate updates in both directions alright, it just won't do it correctly.
Name one. No filesystem-level stuff please, and no snapshots either. I've worked on both kinds of systems before, and they're not what I was talking about. Block level, continuous rollback capability.
Bell Labs had several versions of such a system, built into the research UNIX kernel (different in details, but from the user's point of view, they could easily look at the file system at any point in the past). It was a neat, gee-whiz kind of thing, but ultimately, not very useful.
or in anything else, I'll guess. I'll wait for someone with an actual job to comment.
Don't worry about my job--it looks to me like you should be more worried about your own.
As I was mentioning, unison has the option to merge files. It also has the option to keep old versions of files, if you like, and the class of files for which that happens is configurable.
Re:unison is probably a better solution
on
Home Directory In CVS
·
· Score: 2, Interesting
Rsync can actually be used in that fashion too, BTW, right out of the box, and it works well too.
No, it cannot. rsync is a uni-directional file synchronizer and it doesn't have an interactive interface. unison is a bi-directional file synchronizer with non-timestamp-based change detection and a GUI for resolving conflicts. The two are completely different things. unison does much more than rsync.
However, versioning allows you to go back to the most useful prior version of the file, not just the most recent. What if you finally managed to get your configuration right last week, but that version got overwritten by the version with "just one more tweak" that was used for this week's rsync/unison run?
Unison can create histories and backups if you like, even on a path or type-dependent basis. In several years of using it, I have never bothered because all the applications I use already keep their own backups or histories. (Incidentally, rsync can keep version histories and backups, too.)
I guess I should mention, just for the sake of full disclosure (not because it's really relevant) that I'm a product architect at a company seeking to do provide just this sort of "go back to any time" functionality at the block level. Of course I have some strong opinions about the relative utility of "single point in time" vs. continuous backup/restoration, or I wouldn't have taken the job.
Such systems have been around since at least the 1980's. Most people who have used them (including myself) have found them to be profoundly useless even though they worked exactly as advertised and were really easy to use.
Over several decades of experience with such systems, people generally have come to the conclusion that versioning and histories are application-dependent and best left to applications. That's why systems like Emacs, Microsoft Word, etc. have that sort of thing built in and why people use CVS on a per-project basis.
(And, in the interest of full disclosure, I have no commercial interest whatsoever in any of these systems.)
I think Motorola made a mistake by choosing Qt/Embedded, and one that may cost Linux the phone market.
Choosing Qt/Embedded means that Motorola is now tied to the fortunes of Troll Tech. The GPL option of Troll Tech's license may be acceptable for open source developers, but it wouldn't be an option for Motorola should Troll Tech decide to take a wrong turn somewhere with where they take Qt/Embedded (some would argue that they already have). Furthermore, commercial developers for these phones have a much higher cost of entry into the market than if Motorola had chosen one of the LGPL'ed toolkits.
Altogether, Motorola is in roughly the same situation with respect to Troll Tech as they would be with respect to Microsoft if they had chosen Windows CE. But Microsoft at least is guaranteed to stay around a little longer.
What is particularly sad is that Qt/Embedded really has technically no advantages over any of the alternatives. Even compared to X11 and Gtk+, Qt/Embedded is slow and memory hungry; it's less featureful and without open implementations.
Congratulations on a good marketing and sales job to Troll Tech. But this is a pretty sad day for Linux and open source.
unison is probably a better solution
on
Home Directory In CVS
·
· Score: 4, Interesting
My recommendation: use the Unison file synchronizer to keep multiple copies of your home directory in sync.
It's not quite the same thing as CVS, but that's probably a good thing. Most importantly, it won't give you versioning. On the other hand, it is symmetric (meaning, none of the copies are distinguished) and it is much less hassle to use. Also, you can define custom merge methods to automate merging of things like mailboxes. Unison is great for keeping a home directory (or portions of it) in sync between different desktops, and between desktops and laptops.
Note that for live backups, rsync is probably still the best choice because you want something unidirectional.
If you compare Apple's own SPEC marks against those on spec.org for other systems, you'll see that the G5 is slower than the Opteron, Athlon 64, or recent P4's. It's also neither the only nor the first 64bit personal computer.
The G5 based Macs are nice machine that has helped Apple catch up with the performance of PCs, but that's all.
In this case, because the Keychain would appear to be a well-known piece of prior art, which would make it unpatentable (at least by IBM).
IBM didn't patent the keychain, they patented a particular UI by which people enter the password for the keychain. The UI has the advantage of requiring explicit entry of a password for authorizing each transaction while requiring the user only to remember a single password.
Apple didn't invent SCSI, but it had SCSI standard long before the rest of the mainstream computer world did.
Sun used SCSI for far longer than Apple, as did many high-end PCs. Apple is less mainstream than even the SCSI-using sliver of the PC world, let alone Sun.
Apple gets cited because even though they didn't invent, or weren't the first to commercially use, a given product, it seems like they did. And perception is 99% of reality.
Yes, and that's a perception one should put an end to so that Apple competes fairly with other companies, rather than by giving the appearance of being innovative. You may not remember, but Apple's PR prowess killed off a number of companies and products that really deserved to have seen the light of day. And Apple's pretty but technically inferior implementation of WIMP held back the industry for a decade, if not because of Apple itself then because Microsoft copied Apple's architecture.
You can get COBOL compilers for just about any target. For example, there are also COBOL-to-JVM compilers (not that the JVM is any less proprietary than.NET). Interoperability with non-COBOL languages may, however, be a problem in either case because COBOL has some pretty oddball and low-level features.
Whether COBOL programmers will bite remains to be seen. I suspect what they are most interested in in a platform is performance, reliability, and predictability. Neither.NET nor the JVM deliver those (yet?). That's why most COBOL applications will probably remain native for the time being.
What does this mean for the Symbian OS, which is currently an open OS?"
In what sense is Symbian OS "open"? It looks to me like it's a proprietary set of APIs and a proprietary product that is controlled by a single company that just happens to have a lot of investors. That's better than Windows CE, but still not "open".
I think the best thing for the phone market would be if it switched aggressively to truly open systems. That means systems with open APIs (POSIX, X11, Gtk+) and preferably open source implementations (Linux, BSD). Then, nobody would have to worry about whether Nokia is the lesser evil than Microsoft.
Right. But if they had a real thing to photograph, they'd probably put a photograph there. Hence, my point: I think it's vaporware and they don't even have a prototype.
If they support open source Linux drivers and they work even moderately well, I'll replace all my cards and buy a dozen (I'm not kidding). I'm really tired of the hassles resulting from nVidia and ATI's binary-only drivers.
Slashdot Mirror
Well, not exactly. Here is the scoop as far as I can tell. The line mode browser and the NeXT browser apparently were developed simultaneously. The line mode browser seems to have been released a little earlier, and in any case, was the only browser most people would see until Mosaic came out. See here for a timeline.
There's one problem with your logic. To my knowledge, Gamespy still doesn't actually own the source to Gamespy3D, to which I believe these security holes refer. That codebase is owned by the original coders of Quakespy, the program that got the company started.
If Gamespy has managed their software licensing so incompetently that they can't fix bugs in what they ship, that's their problem. They should go out of business and be replaced by a company that can put out products that don't endanger the security of my computer. Trying to suppress reporting of those bugs is not an acceptable response.
What this really shows us again is what a horrendous security mess closed source software is. We really need to replace that kind of junk with software we can trust.
You can do that with OpenGL too. You need a few extensions (namely, rectangular textures) but that's it.
Where exactly does OpenGL specify pixel-accurate rendering semantics? And which OpenGL implementations actually guarantee conformance?
Note that being able to put up a texture pixel-by-pixel is not the same as having hardware accelerated line drawing or circles with pixel-accurate semantics.
Where in the heck are you getting this text web browser thing? Or are you making this up as you go along?
r y/ All.html
The way most people were able to access the web initially was through a line mode browser from CERN. Turns out, it was developed almost concurrently with the NeXT-based one. I thought the NeXT browser was actually a few months later. Certainly, very few people would have been able to run the NeXT-based browser.
A timeline is here:
http://cern.web.cern.ch/CERN/WorldWideWeb/Histo
In any case, I suspect the point of that claim that it was "first" was probably that NeXT was a good platform to develop innovative GUI apps on, which is quite true. But that was in 1989. Today, there are better choices available than Objective-C and DisplayPostscript.
but [Venti is] only loosely related to and by no means the same as what I was talking about...
Well, golly, gee, and it isn't at all related to what I was talking about. So why do you keep bringing it up?
Saying Venti is block-level when it only works with one filesystem and OS is like saying that a libc hack is the same as a real distributed filesystem;
Between the terminology of some experienced Bell Labs researchers and you, frankly, I give precedence to their choice of terminology. If you think your product distinguishes itself, call it something different.
and you were still not quite telling the truth when you said nobody found it useful.
Look up the word "hyperbole" in the dictionary. Better yet, look up the words "get a clue".
That was the first graphical web browser. The first web browser was text based and not written in Objective-C.
IMO, Objective-C is actually a much nicer and more consistent OOL than C++. The syntax is a little oddball, but ultimately no big deal, and the method naming actually helps.
What kills Objective-C in my opinion is that its resource management is a kludgy mess. Java and C# have bullet proof and worry-proof resource management, and in C++ you can get it if you know what you are doing. But in Objective-C, resource management and exception handling are as flaky and cumbersome as in C (Objective-C has lots of library support for it, but that doesn't help much).
Objective-C could have a renaissance if Apple updates it for the 21st century. Foremost, it needs some runtime safety and some garbage collection. Something like the Tom language. But in its current form, it will fade from view.
Why not? I helped build a whole GUI toolkit out of OpenGL primitives, and didn't find anything lacking.
Because many 2D applications need graphics primitives with precise guarantees for pixel placement and pixel values, features that are not very important for 3D applications. For example, you may want 2D line drawing to guarantee that if you draw two one-pixel-wide lines at the same slope one pixel shifted relative to one another, they line up correctly. Or you might want guarantees that a rendering operation only renders pixels with exactly the RGB values you specified or that it stays precisely within some bounding box, guarantees that 3D hardware may not necessarily give you.
So, yes, you can build nice looking UIs on top of OpenGL and you can get many applications to work on top of it. But, ultimately, the requirements for 2D and 3D graphics rendering are somewhat different and the hardware reflects that. Whether that will matter in the long term, I don't know. But today, it still does.
Then why are so many more people going with Gnome and KDE? Why don't more people just support the GNUstep people instead?
Easy: while a lot of people like the look of the Mac, they don't like the underlying technologies: DisplayPDF and Objective-C. Personally, I think those technologies are obsolete, inefficient, and cumbersome.
I think adding transparency to X11 is a technically much better solution. It is language neutral and transport agnostic. It also has the virtue of being backwards compatible. And it doesn't require people to throw away their existing X11 software--there is a lot more X11 software than OpenStep or Apple software.
X11 will also get server-side stored vector graphics based on SVG. Again, same functionality as DisplayPDF but more standards compliant and a better design.
Also, OpenStep exists as a standard so it sure will make easier to port commercial applications written in Cocoa to the Unix world.
In what sense do you believe OpenStep is a "standard"? Where are the standards documents? Where can you even get an implementation?
It seems that right now, we have GNUstep and Cocoa, two similar but incompatible implementations, together with some copyrighted API documents.
Note, incidentally, that few of the features that make the Macintosh API visually appealing (shadows, transparency, etc.) were pioneered by Apple, and historically were implemented without anything like Apple's software infrastructure.
I think a really fast way of getting this in the hands of programmers would be to make a VNC version of this server. I may be reluctant to replace my regular development desktop with it, but developing against a VNC server with alpha transparency would be fine.
X11 isn't like the stuff Microsoft or Apple churn out. Microsoft and Apple just hack something together, throw it out, and call it a "standard API". It's easy. It's quick to market. And it locks people into proprietary APIs and has all sorts of other problems.
X11 is a protocol, not an implementation. As part of defining protocol extensions, people build a reference implementation of the protocol extension. It makes perfect sense to build the reference implementation in software. Hardware vendors and implementors can then build hardware accelerated versions of it and compare it with the software implementation.
This approach has worked very well. It means that X11 has remained backwards and forwards compatible over more than a decade and that X servers have been able to take advantage of new hardware technologies as they have come out.
Note that Apple is not using the "innate RGBA capabilities of the video card" to its fullest extent either. Furthermore, even good 3D cards may not do the right thing for 2D rendering--2D desktop rendering is not simply a subset of 3D rendering.
Obviously, no sane mammal should ever rely on something as silly as two-legged locomotion with dynamic stabilization. If either one of your legs were to fail, you'd fall down, probably breaking something and being eaten by the next carnivore passing by--absolutely deadly. To avoid falling, you'd have to control your legs with incredible precision--you would need a brain bigger than the size of a pea and much of your muscle mass would have to move to the legs. And then just look how high your body would be above your legs: if you are running and try to stop, unless you stop very gradually, you are just going to tumble over head over heels--highly dangerous. You can't even stand up still without a dangerous balancing act--how are you even going to sleep?
I'm telling you: two-legged locomotion with dynamic stabilization is just never going to make it. Any mammal that follows down that path is going to become extinct instantaneously. Don't be stupid--be a four-legged mammal. It's safe. It's stable. Mooo.
but I certainly hope that intentionally unstable vehicle designs with no fault-tolerance are NOT the norm in 2050.
There almost certainly is fault tolerance, it just isn't mechanical. There are plenty of devices like that people use every day: elevators, helicopters, some modern airplanes.
Even cars have single-points-of-failure, where a single defect will kill you; yes, you can usually survive the motor cutting out, but even a blown out wheel can kill you. Oh, and let's not forget the biggest single-point-of-failure: the hamburger-eating, cell-phone-speaking, map-reading, make-up-on-putting mom driving around in an SUV with three screaming kids behind her.
This is one of those instances, I think, where just because you can doesn't mean you should.
Maybe, maybe not. As a recreational vehicle, it seems no worse than a lot of other vehicles. As transportation, it doesn't seem much worse than other modes of transportation.
but I certainly hope that intentionally unstable vehicle designs with no fault-tolerance are NOT the norm in 2050.
I hope that individually owned, powered transportation will itself go away by 2050--it's wasteful, inefficient, inconvenient, unsafe, and expensive, no matter what vehicle you use. A much better choice, IMO, is personal rapid transit, which essentially gives you the comfort of a personal driver without the cost or hassles.
Venti. Filesystem-level, research project, and it was Plan 9 not UNIX. In other words, pretty much totally unlike what I was talking about.
Venti is described as a "block-level" system. Yes, it uses different technology from the buzzword-laden approach you are taking, although it doesn't sound like your user experience will be any better. And, no, it's not what I was talking about. Venti is only one of several such systems at Bell Labs.
What I had used is described in "Sean Quinlan. A cached WORM file system. Software---Practice and Experience, 21(12):1289--1299, December 1991.". While the server ran on Plan 9, it was exported to Research UNIX systems, which is where I think most real users used it.
Furthermore, others have already mentioned it on this very thread and said it was useful to them, putting the lie to your claim that it's not useful.
Yes, probably in the same sense that the other systems you talk about are "useful" to someone: mostly people with deep pockets looking for a silver bullet to intrinsically hard data management problems. Hey, your company may have a market there as well--silver bullet sales are up again.
Nice troll, kid.
I'm always grateful for compliments about my youthful appearance. Now, go back read some research papers on file systems, replication, and versioning--you really seem to need it.
Yes, but it's trivial to run [rsync] twice, once in each direction, with arguments that result in updates propagating in both directions.
Yeah, it will propagate updates in both directions alright, it just won't do it correctly.
Name one. No filesystem-level stuff please, and no snapshots either. I've worked on both kinds of systems before, and they're not what I was talking about. Block level, continuous rollback capability.
Bell Labs had several versions of such a system, built into the research UNIX kernel (different in details, but from the user's point of view, they could easily look at the file system at any point in the past). It was a neat, gee-whiz kind of thing, but ultimately, not very useful.
or in anything else, I'll guess. I'll wait for someone with an actual job to comment.
Don't worry about my job--it looks to me like you should be more worried about your own.
As I was mentioning, unison has the option to merge files. It also has the option to keep old versions of files, if you like, and the class of files for which that happens is configurable.
Rsync can actually be used in that fashion too, BTW, right out of the box, and it works well too.
No, it cannot. rsync is a uni-directional file synchronizer and it doesn't have an interactive interface. unison is a bi-directional file synchronizer with non-timestamp-based change detection and a GUI for resolving conflicts. The two are completely different things. unison does much more than rsync.
However, versioning allows you to go back to the most useful prior version of the file, not just the most recent. What if you finally managed to get your configuration right last week, but that version got overwritten by the version with "just one more tweak" that was used for this week's rsync/unison run?
Unison can create histories and backups if you like, even on a path or type-dependent basis. In several years of using it, I have never bothered because all the applications I use already keep their own backups or histories. (Incidentally, rsync can keep version histories and backups, too.)
I guess I should mention, just for the sake of full disclosure (not because it's really relevant) that I'm a product architect at a company seeking to do provide just this sort of "go back to any time" functionality at the block level. Of course I have some strong opinions about the relative utility of "single point in time" vs. continuous backup/restoration, or I wouldn't have taken the job.
Such systems have been around since at least the 1980's. Most people who have used them (including myself) have found them to be profoundly useless even though they worked exactly as advertised and were really easy to use.
Over several decades of experience with such systems, people generally have come to the conclusion that versioning and histories are application-dependent and best left to applications. That's why systems like Emacs, Microsoft Word, etc. have that sort of thing built in and why people use CVS on a per-project basis.
(And, in the interest of full disclosure, I have no commercial interest whatsoever in any of these systems.)
I think Motorola made a mistake by choosing Qt/Embedded, and one that may cost Linux the phone market.
Choosing Qt/Embedded means that Motorola is now tied to the fortunes of Troll Tech. The GPL option of Troll Tech's license may be acceptable for open source developers, but it wouldn't be an option for Motorola should Troll Tech decide to take a wrong turn somewhere with where they take Qt/Embedded (some would argue that they already have). Furthermore, commercial developers for these phones have a much higher cost of entry into the market than if Motorola had chosen one of the LGPL'ed toolkits.
Altogether, Motorola is in roughly the same situation with respect to Troll Tech as they would be with respect to Microsoft if they had chosen Windows CE. But Microsoft at least is guaranteed to stay around a little longer.
What is particularly sad is that Qt/Embedded really has technically no advantages over any of the alternatives. Even compared to X11 and Gtk+, Qt/Embedded is slow and memory hungry; it's less featureful and without open implementations.
Congratulations on a good marketing and sales job to Troll Tech. But this is a pretty sad day for Linux and open source.
My recommendation: use the Unison file synchronizer to keep multiple copies of your home directory in sync.
It's not quite the same thing as CVS, but that's probably a good thing. Most importantly, it won't give you versioning. On the other hand, it is symmetric (meaning, none of the copies are distinguished) and it is much less hassle to use. Also, you can define custom merge methods to automate merging of things like mailboxes. Unison is great for keeping a home directory (or portions of it) in sync between different desktops, and between desktops and laptops.
Note that for live backups, rsync is probably still the best choice because you want something unidirectional.
If you compare Apple's own SPEC marks against those on spec.org for other systems, you'll see that the G5 is slower than the Opteron, Athlon 64, or recent P4's. It's also neither the only nor the first 64bit personal computer.
The G5 based Macs are nice machine that has helped Apple catch up with the performance of PCs, but that's all.
In this case, because the Keychain would appear to be a well-known piece of prior art, which would make it unpatentable (at least by IBM).
IBM didn't patent the keychain, they patented a particular UI by which people enter the password for the keychain. The UI has the advantage of requiring explicit entry of a password for authorizing each transaction while requiring the user only to remember a single password.
Apple didn't invent SCSI, but it had SCSI standard long before the rest of the mainstream computer world did.
Sun used SCSI for far longer than Apple, as did many high-end PCs. Apple is less mainstream than even the SCSI-using sliver of the PC world, let alone Sun.
Apple gets cited because even though they didn't invent, or weren't the first to commercially use, a given product, it seems like they did. And perception is 99% of reality.
Yes, and that's a perception one should put an end to so that Apple competes fairly with other companies, rather than by giving the appearance of being innovative. You may not remember, but Apple's PR prowess killed off a number of companies and products that really deserved to have seen the light of day. And Apple's pretty but technically inferior implementation of WIMP held back the industry for a decade, if not because of Apple itself then because Microsoft copied Apple's architecture.
You can get COBOL compilers for just about any target. For example, there are also COBOL-to-JVM compilers (not that the JVM is any less proprietary than .NET). Interoperability with non-COBOL languages may, however, be a problem in either case because COBOL has some pretty oddball and low-level features.
.NET nor the JVM deliver those (yet?). That's why most COBOL applications will probably remain native for the time being.
Whether COBOL programmers will bite remains to be seen. I suspect what they are most interested in in a platform is performance, reliability, and predictability. Neither
What does this mean for the Symbian OS, which is currently an open OS?"
In what sense is Symbian OS "open"? It looks to me like it's a proprietary set of APIs and a proprietary product that is controlled by a single company that just happens to have a lot of investors. That's better than Windows CE, but still not "open".
I think the best thing for the phone market would be if it switched aggressively to truly open systems. That means systems with open APIs (POSIX, X11, Gtk+) and preferably open source implementations (Linux, BSD). Then, nobody would have to worry about whether Nokia is the lesser evil than Microsoft.
Right. But if they had a real thing to photograph, they'd probably put a photograph there. Hence, my point: I think it's vaporware and they don't even have a prototype.
If they support open source Linux drivers and they work even moderately well, I'll replace all my cards and buy a dozen (I'm not kidding). I'm really tired of the hassles resulting from nVidia and ATI's binary-only drivers.