Also, if the developers do change a library that way, it doesn't matter what language it's written in. If the new API isn't compatible with the old one, then all those dependencies will have to be upgraded too.
But the new API is compatible--merely adding a field (or method) does not change any of the semantics of the object. And, in fact, there are many languages in which you don't have to recompile.
That's true if the Gtk+ developers are dipshits. Changing the API in such a way that it breaks previous versions is not only usually not done, but it's big enough to trigger a major version number change when it's done.
The Gtk+ developers are just responding to the irrational limitations of the C language; there is no intrinsic reason why adding a field or method to an existing object is anything to be avoided. Quite to the contrary: the workarounds that are being used with C/C++ in the name of binary compatibility are far worse.
Email did not used to be as open as it is today. Although many academic and business systems were not much different, it was often a hassle to communicate between different systems. Even ten years ago, my college was using a system called "All-In-One", and to send something off campus, you had to prefix the address it with some bizarre code, because for some reason the computer couldn't figure it out otherwise.
What does that have to do with it being open? Yes, we used to have UUCP, Bitnet, DECnet, ARPAnet, and lots more, and, yes, you had to concoct some pretty strange addresses. But most of those implementations were open, and people made at least an effort to keep them interoperable.
I think that some early internet services like compuserve and prodigy were even more disinterested in letting you email with people not on your system.
Of course, they were. But they lost out.
But, somewhat ironically, the ancestors of IM that we used at the time (unix talk and ytalk) were free, sans advertising, and used well-understood communication protocols. So as email has grown more open, chat tools have grown less so. But this is probably just because a lot of IM used in business/school is not officially sanctioned, and also not budgeted, so management is letting their employees pay (by looking at advertising) for an increasingly-important business infrastructure.
No, it has more to do with the technology, and the problem happened earlier. "talk" requires a constant internet presence and a fixed IP address to be useful, "mail" doesn't. In order to make "talk" work otherwise, you need global naming and directory services, but those weren't widely used or standardized by the time commercial ISPs started up. So, ISPs ended up providing mail service but not talk services.
I fail to see how a choice of two (completely different and incompatible) video chat solutions would constitute "too many choices". Once we get to, say, ten, then let's worry about "too many choices".
The situation is similar, and it's a reason to avoid closed-source software, but it's not quite the same. Most closed-source software keeps running even if is discontinued. So, you can keep running WordPerfect on DOS for years if you like, until the hardware breaks or you get tired of it. With a proprietary service, things can stop working without warning from one day to the next.
The problem isn't too many dependencies, the problem is that all current package managers suck. If I'm trying to migrate to the newest GIMP, I must first resolve all the dependencies for the new GIMP.
With Debian, you don't have to: apt will do it for you. But that doesn't remove the dependencies--you still pay the price. What's the price? Huge downloads and enormous amounts of human effort going into this.
Instead of lumping everything together in/usr/local, wouldn't it be better if packages binaries were separated by directory as well as symlinks to library dependencies?
How does that help? The package specifications already contain the library dependencies and use it to minimize necessary package upgrades.
No, the real problem is that if someone adds a field to the Gtk+ Window structure, every piece of software that included that structure definition (all Gnome applications, etc.) need to be recompiled. If you use a binary distribution, then all binary packages of software using that header file need to be downloaded again. And that's not a packaging problem, it's a problem with the underlying programming language and its implementation.
If you're looking for a power-user Linux with binaries, Debian would probably be a better way to go.
Debian indeed gives you a great selection of packages and does a good job on the dependency management.
But that doesn't mean that the dependency problem has been solved--you are still paying the price for it. To make the Debian magic happen requires an enormous amount of labor and coordination. Even with that, there are dependency problems (fewer than if you try to do the same thing by hand with RedHat or SuSE, but they still occur), and "apt-get upgrade" results in huge downloads with regularity.
I wouldn't advocate the use of Java in OSS because Java is highly proprietary and has many design flaws.
I would advocate the use of Mono/C#, however, since it is open source, non-proprietary, and fixes many of Java's problems. And I don't "disguise" that at all--why should I?
Unfortunately, neither Java nor C# were designed to deal specifically with this problem, so neither of them is a complete solution. But they help, and if you know what you are doing, they can actually help a lot. Another language that is an improvement over C/C++ in this regard and is a bit "closer to the metal" is Objective-C (although, frankly, I wouldn't recommend using Objective-C either at this point).
Have you ever deployed a component solution? I'm all for language agnostic component solutions, but there is tons of version hell in both the.NET and JAVA worlds.
Yes, indeed there is..NET and Java don't solve this problem. That's both because they have many other dependencies between modules and because their byte code format unnecessarily encodes too many dependencies.
Nevertheless, JITs are an important part of the solution because they allow you to remove almost all compiled-in dependencies between object files without sacrificing efficiency.
That is, all object file A has to know about structure X in object file B is that structure X contains a field called Q; where that field is located inside the structure doesn't matter, or whether there are other fields. It doesn't even necessarily need to know the exact type of Q. Yet, a JIT can make access to Q as fast as if the structure definition for X had been included in file A as a header file and had been hard-compiled in. That means that with a JIT and good language semantics, the definition and implementation of Q can change in almost arbitrary ways without ever requiring recompilation of A.
So, again, JITs aren't the solution by themselves, but they are an important part of the solution, because, when implemented right, they remove the need to compile in knowledge about data structures and codes in different modules.
if they are going to further fracture the way-too-many-standards-already arena of instant messenger video
That's exactly the trouble: AIM, Yahoo! IM, and MSN Messenger are not "standards", they are commercial services. If they were standards, then implementing them would be much less of a problem.
However, there are standards for audio and video conferencing, and GnomeMeeting implements them, along with NetMeeting, iChat, and lots and lots of other software and hardware. People just need to be smart enough to figure out that they should use it.
Also, I have lots of x86 using friends that hate booting into Windows from Linux just to use advertising-ridden AIM.
The ads are part of their business model. If lots of people switch to using open, ad-free clients, they'll eventually just decide to keep those clients from connecting. That's the trouble with using software that relies on proprietary protocols and proprietary servers.
I know it's less convenient, but try to get your friends to use chatting (in particular, video chatting) using open protocols. There are technically perfectly good choices: H.323, Jabber, etc. People just have to use them more. And the longer AIM becomes entrenched, the harder it will get to change.
Just imaging what E-mail would be like if it had started like chatting--with AOL, Microsoft, and a few others controling the servers and the infrastructure. Ultimately, ISPs should provide IM servers just like they provide mail servers.
What gaim-vv aims to provide is voice and video chat with AIM/iChat, MSN, Yahoo, etc, that is, the protocols that people actually _use_.
Those are also the protocols that are under the control of companies with their own financial interests. How long do you think those companies are going to provide access to open source clients when those services don't fit into their business plan and stop looking like attractive business propositions anymore?
GnomeMeeting and H.323 are easy to use. They talk to existing video conferencing hardware, give you full control over how you connect and what directory services you use, and easily run even serverless. If you use AIM/iChat, MSN, Yahoo, or any of the others, it's just stupid.
At the very least, let's hope that GAIM-vv will provide full access to standards-based H.323 video conferencing, in addition to its support for proprietary services. But it really should pop up a big warning dialog every time anybody uses AIM, MSN, or Yahoo!: "This service may be discontinued or become unavailable without warning any day. [OK?]".
GnomeMeeting provides standards-based (H.323 and others) video conferencing, the same protocol that is used by many hardware video conferencing system. There are open server implementations that work with GnomeMeeting (e.g., openh323.org). You get full control over your data, your privacy, your CODECs, and your security. And using GnomeMeeting can be as simple as giving the host name of your counterpart.
The "chat" video conferencing add-ons from AOL, Yahoo!, etc., on the other hand, are tied into a proprietary server infrastructure. Using them means that you are becoming dependent on that server infrastructure and that you let those companies control when and how you can use their chat facilities. For example, AOL could just decide to shut down their servers, exclude you from it, or change the way they encode audio or video.
GAIM is, of course, multi-protocol. So, if the GAIM video chat effort does its job right, you should end up with an application that can subsume GnomeMeeting functionality while also giving you access to the proprietary chat networks. But you should always remember that using AIM or Yahoo! for video (just like for chatting) means that you can lose the service at any time, in particular when you are using an open source client to connect.
except that the LZW patent was valid, as far as I know.
Both LZW and this patent are "valid" patents. Both of them had extensive related prior art at the time of their filing, although the exact method described in each patent may not have been patented before. In both cases, the only reason the patents became valuable was because the companies involved remained silent for a long time, until the patented method had become an integral part of some standard that was erroneously presumed open and freely implementable; if the existence and enforceability of either patent had been known at the time the standards were written, the standards could have trivially avoided causing implementors to infringe on the patents.
While I will grant you that this patent looks even more stupid than LZW, the situations are quite analogous.
Given the amount of software I have on my Linux box, I think a BSD/Gentoo-like build process just wouldn't be practical for me.
The underlying problem is really that C/C++ code has so much information compiled into each object file: even common, minor changes may require huge amounts of recompilation. While we practice abstraction and encapsulation at the source level, at the binary level, it is still mostly lacking.
The choice shouldn't been between huge amounts of recompilation from source (Gentoo, BSD) or laborious hand-packging and version tracking (Debian, RedHat, etc.), this needs to be addressed by changing the underlying software infrastructure. Let's hope we'll move more towards JITs, dynamic binding, dynamic typing, and component-based software. Then we can finally get away from these massive recompilations and version hell.
Obscure? Hardly. I use these features almost all the time.
Ah, well, I guess that settles it then: if a dedicated Mac fanatic like you doesn't find it obscure, then it can't be obscure.
You don't because you can't and are confused by mice with only one button. And what's that prattle about "another two modifier keys"?
The Mac has Fn, Control, Shift, Command, and Alt, and they all are commonly used as mouse modifiers; furthermore, their mappings to mouse buttons and their function is quite inconsistent in different applications.
In contrast, Windows and X11 mainly use Control and Shift as modifiers for the mouse (Alt in some circumstances), and they use left, middle, and right mouse buttons quite consistently, both within each system and between each other.
Have you ever used a Mac?
Yes, I have. In fact, I still do, regularly. But I also use other things, and unlike you, I don't approach the world with Mac-blinders.
Why do I like this? It's a physical authentication system that doesn't require any special reader hardware
I don't see why a microphone is any less special than a USB port or an IR port. If anything, just about any computer these days has a USB port.
And using IR for authentication, many modern phones and almost all modern PDAs will do; all you need to do is plug an IR dongle costing a few dollars (in quantity) into the USB port. And IR can be made interference proof much more easily than sound.
The patent is on run-length coding, a widely used idea even in the 1980's, together with lots of trivial variations on the basic idea. The patent shouldn't have been granted--it's just one of many bogus patents.
However, even more serious is that the company has waited until the last year that the patent is in effect trying to enforce it. Under current regulations, that seems to be possible, but there is no reason why we should not change the laws and regulations.
We really need to arrive at a legal principle that companies need to actively enforce their patents when they become aware of violations, or otherwise lose patent protection altogether. For something of the size and importance of the JPEG standard, the company should have known within a few years of its adoption that it may infringe their patent.
Yeah? Do a non-continous selection with one hand on your three button mouse. Open an URL in a new window/tab while using the opposite of the default behaviour of focusing.
What's your point? That there are obscure key/mouse combos that some small number of people use? What does that prove?
And how does an already unintuitive feature get better by adding another two modifier keys (Fn and Command) to the already confusing set of set of modifier keys (Control, Shift, Alt, AltGr)? Even Windows UI designers had the good taste not to use the extra keys on the Windows keyboard (Windows, Menu) as modifiers for the mouse.
I honestly disagree with this, having had a terrible time using PC laptop pointing devices, and simply a mediocre time using Apple laptop pointing devices.
Which "PC laptop pointing devices" are you talking about? Most PC laptops these days have the same trackpads that Apple popularized. The only other choice that is still commonly available is the nipples, and people either seem to love those or hate those.
My favorite laptop pointing device, a built in trackball, just doesn't get made anymore.
In any case, my point is that I don't think usability matters much in Apple's decision to keep trackpads, no matter what that usability may be: Apple keeps single-button trackpads primarily for branding, cost, and design reasons.
One has to wonder what BayStar is expecting as a reaction to their being so... blunt.
They aren't being blunt in any way that Darl McBride hasn't been blut before. BayStar probably expects that the market takes SCO's intellectual property claims more seriously, thereby boosting the value of their investment. Remember, they don't care about being liked, they care about money.
Whether BayStar knows how unfounded SCO's IP claims actually are and they are just using it, or whether they actually think that SCO really has IP claims is anybody's guess. But, ultimately, it doesn't matter. Either way, I think they miscalculated.
The idea of hard disk video recorders is pretty straightforward. Yes, TiVo was first to market and they make a nice product, but so what? That doesn't make every hard disk video recorder a "TiVo-clone".
The MacOS solution is vastly preferable, for laptops only. Click-hold brings up a context menu.
And it could continue to do that if Apple put three buttons on their laptops. If you don't want to use the three buttons, you can continue to use just the left button with key combinations.
But in real life, just about everybody plugs a three button mouse into their desktop Mac because it is simply more intuitive and usable that way: a button for pointing, a dedicated button for context menus, and a dedicated button for scrolling. Having a one button mouse on the notebooks is just confusing.
You have to tuck your thumb all weird under your hand
No, you don't, since your right hand is already at an angle. But if that were a problem, it could be addressed by moving the buttons slightly to the side.
Unless you're talking about IBM keyboard nipples, PC laptops with multiple buttons are impossible to use quickly and accurately.
Laptops with trackpads are impossible to use quickly and accurately, whether they have one button or three. The reasons why Apple keeps shipping one-button trackpads instead of three button nipples or two button trackballs are simple: appearance, style, cost, and branding. Trackpads are cheap, they don't mar the appearance of the laptops, and Apple considers this particular arrangement part of their brand. Functionality has nothing to do with it.
You seem to fail to understand the difference between a pointing device and a combination of pointing device and keyboard shortcut. Hint: you can operate a three button mouse comfortably with one hand.
Besides, while three mouse buttons do not confuse me, five choices of non-standard function keys combined with a single mouse button definitely do. Talk about counterintuitive.
Control-click may do the same thing as a right click, but it is not a right click.
If you're refering to Davidson, it might interest you that he's actually a fairly recent convert to the Mac. He worked for Sun for quite a while, contributing quite a bit to parts of the J2EE spec and the Tomcat webserver (as well as creating "Ant").
And how does working on Java (whether at Sun or elsewhere) make him a UNIX expert?
Slashdot Mirror
Also, if the developers do change a library that way, it doesn't matter what language it's written in. If the new API isn't compatible with the old one, then all those dependencies will have to be upgraded too.
But the new API is compatible--merely adding a field (or method) does not change any of the semantics of the object. And, in fact, there are many languages in which you don't have to recompile.
That's true if the Gtk+ developers are dipshits. Changing the API in such a way that it breaks previous versions is not only usually not done, but it's big enough to trigger a major version number change when it's done.
The Gtk+ developers are just responding to the irrational limitations of the C language; there is no intrinsic reason why adding a field or method to an existing object is anything to be avoided. Quite to the contrary: the workarounds that are being used with C/C++ in the name of binary compatibility are far worse.
Email did not used to be as open as it is today. Although many academic and business systems were not much different, it was often a hassle to communicate between different systems. Even ten years ago, my college was using a system called "All-In-One", and to send something off campus, you had to prefix the address it with some bizarre code, because for some reason the computer couldn't figure it out otherwise.
What does that have to do with it being open? Yes, we used to have UUCP, Bitnet, DECnet, ARPAnet, and lots more, and, yes, you had to concoct some pretty strange addresses. But most of those implementations were open, and people made at least an effort to keep them interoperable.
I think that some early internet services like compuserve and prodigy were even more disinterested in letting you email with people not on your system.
Of course, they were. But they lost out.
But, somewhat ironically, the ancestors of IM that we used at the time (unix talk and ytalk) were free, sans advertising, and used well-understood communication protocols. So as email has grown more open, chat tools have grown less so. But this is probably just because a lot of IM used in business/school is not officially sanctioned, and also not budgeted, so management is letting their employees pay (by looking at advertising) for an increasingly-important business infrastructure.
No, it has more to do with the technology, and the problem happened earlier. "talk" requires a constant internet presence and a fixed IP address to be useful, "mail" doesn't. In order to make "talk" work otherwise, you need global naming and directory services, but those weren't widely used or standardized by the time commercial ISPs started up. So, ISPs ended up providing mail service but not talk services.
I fail to see how a choice of two (completely different and incompatible) video chat solutions would constitute "too many choices". Once we get to, say, ten, then let's worry about "too many choices".
The situation is similar, and it's a reason to avoid closed-source software, but it's not quite the same. Most closed-source software keeps running even if is discontinued. So, you can keep running WordPerfect on DOS for years if you like, until the hardware breaks or you get tired of it. With a proprietary service, things can stop working without warning from one day to the next.
The problem isn't too many dependencies, the problem is that all current package managers suck. If I'm trying to migrate to the newest GIMP, I must first resolve all the dependencies for the new GIMP.
/usr/local, wouldn't it be better if packages binaries were separated by directory as well as symlinks to library dependencies?
With Debian, you don't have to: apt will do it for you. But that doesn't remove the dependencies--you still pay the price. What's the price? Huge downloads and enormous amounts of human effort going into this.
Instead of lumping everything together in
How does that help? The package specifications already contain the library dependencies and use it to minimize necessary package upgrades.
No, the real problem is that if someone adds a field to the Gtk+ Window structure, every piece of software that included that structure definition (all Gnome applications, etc.) need to be recompiled. If you use a binary distribution, then all binary packages of software using that header file need to be downloaded again. And that's not a packaging problem, it's a problem with the underlying programming language and its implementation.
If you're looking for a power-user Linux with binaries, Debian would probably be a better way to go.
Debian indeed gives you a great selection of packages and does a good job on the dependency management.
But that doesn't mean that the dependency problem has been solved--you are still paying the price for it. To make the Debian magic happen requires an enormous amount of labor and coordination. Even with that, there are dependency problems (fewer than if you try to do the same thing by hand with RedHat or SuSE, but they still occur), and "apt-get upgrade" results in huge downloads with regularity.
I wouldn't advocate the use of Java in OSS because Java is highly proprietary and has many design flaws.
I would advocate the use of Mono/C#, however, since it is open source, non-proprietary, and fixes many of Java's problems. And I don't "disguise" that at all--why should I?
Unfortunately, neither Java nor C# were designed to deal specifically with this problem, so neither of them is a complete solution. But they help, and if you know what you are doing, they can actually help a lot. Another language that is an improvement over C/C++ in this regard and is a bit "closer to the metal" is Objective-C (although, frankly, I wouldn't recommend using Objective-C either at this point).
Have you ever deployed a component solution? I'm all for language agnostic component solutions, but there is tons of version hell in both the .NET and JAVA worlds.
.NET and Java don't solve this problem. That's both because they have many other dependencies between modules and because their byte code format unnecessarily encodes too many dependencies.
Yes, indeed there is.
Nevertheless, JITs are an important part of the solution because they allow you to remove almost all compiled-in dependencies between object files without sacrificing efficiency.
That is, all object file A has to know about structure X in object file B is that structure X contains a field called Q; where that field is located inside the structure doesn't matter, or whether there are other fields. It doesn't even necessarily need to know the exact type of Q. Yet, a JIT can make access to Q as fast as if the structure definition for X had been included in file A as a header file and had been hard-compiled in. That means that with a JIT and good language semantics, the definition and implementation of Q can change in almost arbitrary ways without ever requiring recompilation of A.
So, again, JITs aren't the solution by themselves, but they are an important part of the solution, because, when implemented right, they remove the need to compile in knowledge about data structures and codes in different modules.
if they are going to further fracture the way-too-many-standards-already arena of instant messenger video
That's exactly the trouble: AIM, Yahoo! IM, and MSN Messenger are not "standards", they are commercial services. If they were standards, then implementing them would be much less of a problem.
However, there are standards for audio and video conferencing, and GnomeMeeting implements them, along with NetMeeting, iChat, and lots and lots of other software and hardware. People just need to be smart enough to figure out that they should use it.
Also, I have lots of x86 using friends that hate booting into Windows from Linux just to use advertising-ridden AIM.
The ads are part of their business model. If lots of people switch to using open, ad-free clients, they'll eventually just decide to keep those clients from connecting. That's the trouble with using software that relies on proprietary protocols and proprietary servers.
I know it's less convenient, but try to get your friends to use chatting (in particular, video chatting) using open protocols. There are technically perfectly good choices: H.323, Jabber, etc. People just have to use them more. And the longer AIM becomes entrenched, the harder it will get to change.
Just imaging what E-mail would be like if it had started like chatting--with AOL, Microsoft, and a few others controling the servers and the infrastructure. Ultimately, ISPs should provide IM servers just like they provide mail servers.
What gaim-vv aims to provide is voice and video chat with AIM/iChat, MSN, Yahoo, etc, that is, the protocols that people actually _use_.
Those are also the protocols that are under the control of companies with their own financial interests. How long do you think those companies are going to provide access to open source clients when those services don't fit into their business plan and stop looking like attractive business propositions anymore?
GnomeMeeting and H.323 are easy to use. They talk to existing video conferencing hardware, give you full control over how you connect and what directory services you use, and easily run even serverless. If you use AIM/iChat, MSN, Yahoo, or any of the others, it's just stupid.
At the very least, let's hope that GAIM-vv will provide full access to standards-based H.323 video conferencing, in addition to its support for proprietary services. But it really should pop up a big warning dialog every time anybody uses AIM, MSN, or Yahoo!: "This service may be discontinued or become unavailable without warning any day. [OK?]".
GnomeMeeting provides standards-based (H.323 and others) video conferencing, the same protocol that is used by many hardware video conferencing system. There are open server implementations that work with GnomeMeeting (e.g., openh323.org). You get full control over your data, your privacy, your CODECs, and your security. And using GnomeMeeting can be as simple as giving the host name of your counterpart.
The "chat" video conferencing add-ons from AOL, Yahoo!, etc., on the other hand, are tied into a proprietary server infrastructure. Using them means that you are becoming dependent on that server infrastructure and that you let those companies control when and how you can use their chat facilities. For example, AOL could just decide to shut down their servers, exclude you from it, or change the way they encode audio or video.
GAIM is, of course, multi-protocol. So, if the GAIM video chat effort does its job right, you should end up with an application that can subsume GnomeMeeting functionality while also giving you access to the proprietary chat networks. But you should always remember that using AIM or Yahoo! for video (just like for chatting) means that you can lose the service at any time, in particular when you are using an open source client to connect.
except that the LZW patent was valid, as far as I know.
Both LZW and this patent are "valid" patents. Both of them had extensive related prior art at the time of their filing, although the exact method described in each patent may not have been patented before. In both cases, the only reason the patents became valuable was because the companies involved remained silent for a long time, until the patented method had become an integral part of some standard that was erroneously presumed open and freely implementable; if the existence and enforceability of either patent had been known at the time the standards were written, the standards could have trivially avoided causing implementors to infringe on the patents.
While I will grant you that this patent looks even more stupid than LZW, the situations are quite analogous.
Given the amount of software I have on my Linux box, I think a BSD/Gentoo-like build process just wouldn't be practical for me.
The underlying problem is really that C/C++ code has so much information compiled into each object file: even common, minor changes may require huge amounts of recompilation. While we practice abstraction and encapsulation at the source level, at the binary level, it is still mostly lacking.
The choice shouldn't been between huge amounts of recompilation from source (Gentoo, BSD) or laborious hand-packging and version tracking (Debian, RedHat, etc.), this needs to be addressed by changing the underlying software infrastructure. Let's hope we'll move more towards JITs, dynamic binding, dynamic typing, and component-based software. Then we can finally get away from these massive recompilations and version hell.
Obscure? Hardly. I use these features almost all the time.
Ah, well, I guess that settles it then: if a dedicated Mac fanatic like you doesn't find it obscure, then it can't be obscure.
You don't because you can't and are confused by mice with only one button. And what's that prattle about "another two modifier keys"?
The Mac has Fn, Control, Shift, Command, and Alt, and they all are commonly used as mouse modifiers; furthermore, their mappings to mouse buttons and their function is quite inconsistent in different applications.
In contrast, Windows and X11 mainly use Control and Shift as modifiers for the mouse (Alt in some circumstances), and they use left, middle, and right mouse buttons quite consistently, both within each system and between each other.
Have you ever used a Mac?
Yes, I have. In fact, I still do, regularly. But I also use other things, and unlike you, I don't approach the world with Mac-blinders.
Why do I like this? It's a physical authentication system that doesn't require any special reader hardware
I don't see why a microphone is any less special than a USB port or an IR port. If anything, just about any computer these days has a USB port.
And using IR for authentication, many modern phones and almost all modern PDAs will do; all you need to do is plug an IR dongle costing a few dollars (in quantity) into the USB port. And IR can be made interference proof much more easily than sound.
The patent is on run-length coding, a widely used idea even in the 1980's, together with lots of trivial variations on the basic idea. The patent shouldn't have been granted--it's just one of many bogus patents.
However, even more serious is that the company has waited until the last year that the patent is in effect trying to enforce it. Under current regulations, that seems to be possible, but there is no reason why we should not change the laws and regulations.
We really need to arrive at a legal principle that companies need to actively enforce their patents when they become aware of violations, or otherwise lose patent protection altogether. For something of the size and importance of the JPEG standard, the company should have known within a few years of its adoption that it may infringe their patent.
Yeah? Do a non-continous selection with one hand on your three button mouse. Open an URL in a new window/tab while using the opposite of the default behaviour of focusing.
What's your point? That there are obscure key/mouse combos that some small number of people use? What does that prove?
And how does an already unintuitive feature get better by adding another two modifier keys (Fn and Command) to the already confusing set of set of modifier keys (Control, Shift, Alt, AltGr)? Even Windows UI designers had the good taste not to use the extra keys on the Windows keyboard (Windows, Menu) as modifiers for the mouse.
I honestly disagree with this, having had a terrible time using PC laptop pointing devices, and simply a mediocre time using Apple laptop pointing devices.
Which "PC laptop pointing devices" are you talking about? Most PC laptops these days have the same trackpads that Apple popularized. The only other choice that is still commonly available is the nipples, and people either seem to love those or hate those.
My favorite laptop pointing device, a built in trackball, just doesn't get made anymore.
In any case, my point is that I don't think usability matters much in Apple's decision to keep trackpads, no matter what that usability may be: Apple keeps single-button trackpads primarily for branding, cost, and design reasons.
One has to wonder what BayStar is expecting as a reaction to their being so... blunt.
They aren't being blunt in any way that Darl McBride hasn't been blut before. BayStar probably expects that the market takes SCO's intellectual property claims more seriously, thereby boosting the value of their investment. Remember, they don't care about being liked, they care about money.
Whether BayStar knows how unfounded SCO's IP claims actually are and they are just using it, or whether they actually think that SCO really has IP claims is anybody's guess. But, ultimately, it doesn't matter. Either way, I think they miscalculated.
The idea of hard disk video recorders is pretty straightforward. Yes, TiVo was first to market and they make a nice product, but so what? That doesn't make every hard disk video recorder a "TiVo-clone".
The MacOS solution is vastly preferable, for laptops only. Click-hold brings up a context menu.
And it could continue to do that if Apple put three buttons on their laptops. If you don't want to use the three buttons, you can continue to use just the left button with key combinations.
But in real life, just about everybody plugs a three button mouse into their desktop Mac because it is simply more intuitive and usable that way: a button for pointing, a dedicated button for context menus, and a dedicated button for scrolling. Having a one button mouse on the notebooks is just confusing.
You have to tuck your thumb all weird under your hand
No, you don't, since your right hand is already at an angle. But if that were a problem, it could be addressed by moving the buttons slightly to the side.
Unless you're talking about IBM keyboard nipples, PC laptops with multiple buttons are impossible to use quickly and accurately.
Laptops with trackpads are impossible to use quickly and accurately, whether they have one button or three. The reasons why Apple keeps shipping one-button trackpads instead of three button nipples or two button trackballs are simple: appearance, style, cost, and branding. Trackpads are cheap, they don't mar the appearance of the laptops, and Apple considers this particular arrangement part of their brand. Functionality has nothing to do with it.
You seem to fail to understand the difference between a pointing device and a combination of pointing device and keyboard shortcut. Hint: you can operate a three button mouse comfortably with one hand.
Besides, while three mouse buttons do not confuse me, five choices of non-standard function keys combined with a single mouse button definitely do. Talk about counterintuitive.
Control-click may do the same thing as a right click, but it is not a right click.
Thanks for the useful link; that's good to know. I would still prefer three buttons, but that will make using my PowerBook a lot less painful.
If you're refering to Davidson, it might interest you that he's actually a fairly recent convert to the Mac. He worked for Sun for quite a while, contributing quite a bit to parts of the J2EE spec and the Tomcat webserver (as well as creating "Ant").
And how does working on Java (whether at Sun or elsewhere) make him a UNIX expert?