Microsoft will claim, based on current market penetration, that the end user will most likely install Windows anyway so the OEM's must include it in order to protect their customers from being charged with piracy.
This used to be true, but isn't (or shouldn't be, very soon), for two reasons:
Top-tier computer vendors like Dell and HP sell non-Windows OSes openly, so the argument that Windows will be installed is not entirely convincing.
Microsoft has been getting very good at fighting piracy (with little regard for consumer convenience, but that isn't their priority, is it). WGA in its current incarnation appears to do a very good job of preventing piracy of Vista. So if Microsoft can prevent pirated installations of their OS by itself, there is no need to help it.
How is it relevant as a comparison of backwards compatibility? Directly: something that is older, more stable, and has far more users is less likely to change, hence less at risk for backward compatibility issues.
Your second point is correct, Google did act suspiciously in that instance. They do not have a perfect track record. Still, given the overall situation, I would use Google's web APIs instead of Microsoft's - at this point in time. Perhaps in a few years Microsoft's offerings will mature well, who knows.
It took me 4 hours to port our software to Vista [...] The trick to MS backwards compatibility is to not use the undocumented shit.
That might be true, but how is it relevant as a comparison to Google?
The issue isn't Microsoft's desktop backwards compatibility issues (which is debatable in itself). Thing is, Windows and MSN/Live/etc. just happen to exist in the same company, otherwise, nothing is really shared between them. When you compare Microsoft to Google with respect to maps APIs, you need to compare Google to MSN/Live/etc., which has seen many name and strategy changes and is far less mature than Google's offerings. Google APIs are consequently more stable and less likely to change.
A conservative approach will therefore recommend Google APIs. They are more seasoned, more tested, work on more browsers, and used successfully by far more organizations and businesses.
Its an invisible beam and it leaves no evidence. No one ever has to justify using it, because they can instead just deny using it any time that the use is controversial. This weapon is a terrible, terrible idea. But actually I seriously doubt that it leaves no evidence. Sure, it may not leave any at the proximal nerves (which it stimulates to cause pain), but the fact is, it causes immense pain to the subject, which implies extreme stimulation of certain areas of their brain. This may be detectable later on, perhaps by fMRI or other brain scans, or perhaps behaviorally - I presume that such intense pain will cause hypersensitivity at the location where it was applied (or hyposensitivity, actually - hard to tell).
In addition, they have not tested it on volunteers for long periods (and, by the description, 'long periods' may well be as short as 30 seconds!) - simply because who would volunteer for it? Even hardened marines apparently flee within seconds. We have no idea what will happen to people that suffer this ray for more than a fleeting instant - for all we know it might lead to an epileptic seizure or brain damage. It might also cause local damage to the nerves - overstimulation of nerves can lead to their death; this is called excitotoxicity.
Sadly, I am sure that the developers of this weapon have barbarically tested it on animals for 'long periods'. This is still not enough to convince me that it does not permanent damage; human brains are not identical to animal ones. In addition there is a tremendous psychological element to torture - the belief that the pain will continue; this is less of an issue for some animals.
Sorry for the long rant, but this weapon is a horrible idea. It is like the nuclear bomb of supposedly nonlethal weapons - too powerful for anyone to have. It should be outlawed by international convention IMHO. Let's develop nonlethal methods that incapacitate, etc., not that can be used to bring torture to new levels.
However, Python will likely remain "the scripting language that you write add-ons in", not a mainstream language for core desktop component development. There are a bunch of reasons for that, related to packaging, error checking, development environments, object model, and raw performance. I don't see those getting fixed in P3K either. Hmm, Python+PyGtk seems a great platform to develop applications on; I use it myself:
Regarding packaging, distutils and Eggs are very useful. But even without them the process seems reasonable to me (no less than for C/C++). Regarding error checking, you do lack compile-time checking, as a dynamic language - but the runtime checking is extremely convenient. Bug reports that include the crash output can lead to quite solutions in my experience, far more than for C/C++ (and you don't have any of the memory management errors). Regarding development environment, I use Gedit, so I guess you are referring to more 'complete' IDEs;) (personally I don't like an IDE that does too much for me). Regarding performance, Python is very suitable for desktop applications - startup performance is reasonable (unlike Java), and execution speed is fast enough. Sure, I wouldn't run a ray-tracing app in Python, but for many (most?) desktop tools it seems good enough to me.
I'm not great at this, so perhaps because of that I couldn't find the bug for the issue you mentioned. Can you post a link to it, so we can see what progress (if any) is being made on this matter?
A project as big as a desktop environment that needs to be extremely consistent throughout, needs a Linus. It needs one guy to be the benevolent dictator, because right now it looks like anyone can get any old thing in there. Tomboy a C# app? wtf? It's not complicated, it's an applet, a couple borderless windows, and a simple WebDAV client, all of which I'd bet lots of money Gnome already has libraries for. It could be just as easily implemented in C, and a halfway experienced Gnome developer could implement it, with all of its current features, in probably a week or less. I'm halfway tempted to take a week of vacation and do it myself just to prove a point.
I disagree. Why should all GNOME (or all KDE) apps be written in the same language? Sure, perhaps Tomboy could be written in C in a few weeks (say a few months to get all the bugs out), but it has already been written in C#, and works fine. I see no issue with this. Different languages have different advantages, and different programmers like different languages, which is perhaps even more important in a volunteer project like GNOME. Make GNOME C-only and you might lose out on a lot of developer mindshare.
What we need is to allow multiple languages to work together; we don't want a situation where special 'bindings' need to be written on a per-language basis. As long as that is taken care of (by running on a VM like Mono, or automated bindings generation, etc.), then I see no issue.
(Resource-wise there is some penalty to this, yes, and that does annoy me.)
Because they realize that Gnome can't survive as a desktop that's being hacked in C/C++.
I really don't know whether the Mono VM is the future for the Gnome desktop. But I do know this much: C, C++, and Python are not the future of desktops.
I was with you until the bold part (my emphasis). Yes, modern desktops (and all complex modern software) should probably be written in modern high-level languages. But why not Python? Python is exactly a good example of a modern language, I would think...
Sure, it's possible, but we all know that most people will do whatever is most convenient. If a single click buys them the tracks in iTunes, but it takes in the competitors' systems a click + some fiddling around with copying the files to the right place (using 2 different programs while doing so) - then I think iTunes will end up with most of the business.
Most geeks wouldn't mind the extra work, and might even do it on principle (I would). But the bulk of the market would use the simplest solution, and Apple is trying to make sure that iTunes is that solution, by making it harder for competitors to interface with their hardware.
I really don't see how this improves the bottom line. Does it hurt Apple for people to be using something other than their media player (which is free to obtain) to put songs on their iPod?
This might seem surprising, but really it isn't if you think about it a bit. The issue is Apple's market share and the recent sale of DRM-free tracks.
If you are a small player in the market, it is in your best interest to get as many people as possible to buy your hardware. Letting them use whatever software they want is a plus. But,
If you already have most of the market, and expect to easily keep it, then you might consider ways to exploit that position. Microsoft has been doing this with Windows, for example; apparently Apple are trying to do the same. The issue is that DRM-free song sales have become a reality, which opens the possibility for Microsoft, Real, MTV etc. to sell you tracks and place them on your iPod. When the music labels only sold DRMed tracks, and the iPod only played Apple DRM, Apple wasn't worried. But now they are.
So, this is an expected business tactic. Consumer-friendly, though it is not. Consequently, I know I (a Linux user) won't be buying any iPods.
The Hurd is slow in coming due to the extreme lack of developers.
By the way, why doesn't the GNU project just fork a *BSD kernel and forget all about Hurd? After adding their own code, they can relicense the entire thing as GPL3 and have a 'pure' kernel. Or am I missing something?
In fact there is already a version of Debian running on a BSD kernel, IIRC. So really most of the work has already been done. Is Hurd really that important to them, to continue working on it despite alternatives?
as far as I know, we already _have_ interoperable virtualization
Of course we do (several varieties of it, even), but Microsoft doesn't. They see that virtualizing Linux is going to be big business; their goal is make SUSE on Windows using Microsoft's virtualization solution the 'premiere' way to do that.
My theory at least. Anyhow, I don't expect anything good to come out of this 'interoperable virtualization' issue except for Microsoft (and possibly Novell).
Define 'appropriate', and you will have your answer immediately.
If you want to maximize immediate profits at all costs, use the most powerful copy-protection you can - phoning home, disabling suspect keys even at the cost of inconveniencing paying users, etc. etc.
If you believe the project has long-term possibilities, then you need to start worrying about pissing people off. Don't phone home. Minimal product activation once at installation.
If you believe the product has world-domination possibilities (i.e., that every product manager or whatever in the world will use it) then remove all copy protection. People pirating your software are part of your market share. Also, consider opening the source in an appropriate manner.
And if you are asking about 'appropriate' as in ethics, then certainly open-source the app. Note that this does not mean abandoning copy-protection! GPL (even GPL3) apps can have copy protection... it is just possible to remove it. 90% of users won't care about removing it (or know how); 10% of them might. Not a big loss considering the advantages.
Is that why the vast majority of people do their best and most well known work before 30.
Most people become far less productive in their jobs as they become parents. The drive to put in endless time and effort is no longer a real option when you need to get the kids to the doctor, pick them up from school, etc. etc.
OpenOffice.org itself doesn't lack assistive technologies. OOo on Windows lacks assistive technologies. OOo with GNOME or KDE integration gets the accessibility technologies of GNOME or KDE, respectively.
That is a fair and accurate point to make. I do see a lot of value to this move, however, beyond just improving accessibility for Windows users. On the one hand, this may make accessibility more cross-platform, so it will be easier to migrate from one OS to another; with OO.org already cross-platform, making its accessibility features the same is a good idea. In addition, although this last bit is arguable, OO.org-specific accessibility may be better-integrated than general desktop accessibility features in GNOME/KDE/etc. So this may give us better features in that area for OO.org.
(However, there is also something to be said against this, in that we might want to not have separate accessibility frameworks for each app. That's true, however, for an office suite - sometimes the only app besides a web browser used on some PCs - it might make sense to customize it that way.)
I know from experience that people are just as likely to write nasty Perl, Ruby or ASP as they are nasty PHP.
Ah, but what about Python? With enforced whitespace and a mob of Pythonistas ready to flame you for improper style, all Python code turns out nice and elegant;)
(Seriously, though, Python is the only language where it is even remotely convenient to read other people's code.)
Ok, intelligence doesn't equal survivability or fitness. But they didn't say it does. Just that a singularity machine will be able to design more machines better than it at various tasks, including making more such machines, etc. In theory this is possible.
However, in practice, the singularity, if we will ever reach it, is very far away in the future. I work in the neural computation / statistical learning / AI fields, and I must say, they are nowhere near any singularity of any sort.
Basically the most successful achievements in this area are (1) computers that can beat people at chess/checkers/etc., and (2) systems that can identify handwriting/faces/fingerprints/other patterns. These successes are impressive, but bring us nowhere near anything like 'general intelligence' of the kind that humans (and other animals) have.
Software costs nothing.... Compared to the cost of supporting it.
Don't forget the hardware cost involved. If you pick an OS that requires twice the amount of servers, then your hardware costs - and other related maintenance costs, like technicians, electricity, etc. - go up very significantly.
In addition more hardware can mean more potential security breaches, and so forth.
Thanks to this incident, it is highly improbable that Apple will ever be able to come out with something innovative and new that is a success ever again... because if they try to, a lot of people will hesitate to buy it right away, thinking that perhaps Apple might lower their price in the not-too-distant future. The result will virtually inevitably be a marketing failure.
Given the latest development under discussion here (the $100 credit), in fact people will be motivated to be early adopters, because they see that even if prices drop later on, they get compensated to a significant degree.
And anyhow, we all knew this stuff before, early adopters pay through the nose, etc. etc. I am willing to agree that the price drop was a tad sudden in this particular case, so yes, it might deter future early adopters, however, generally speaking the motivation to own a shiny new toy will win over any fear of several months later being able to buy it cheaper. These are, after all, toys, not long-term investments that you are willing to buy whenever it is most profitable. With toys you want instant gratification.
Slashdot Mirror
How is it relevant as a comparison of backwards compatibility? Directly: something that is older, more stable, and has far more users is less likely to change, hence less at risk for backward compatibility issues.
Your second point is correct, Google did act suspiciously in that instance. They do not have a perfect track record. Still, given the overall situation, I would use Google's web APIs instead of Microsoft's - at this point in time. Perhaps in a few years Microsoft's offerings will mature well, who knows.
The issue isn't Microsoft's desktop backwards compatibility issues (which is debatable in itself). Thing is, Windows and MSN/Live/etc. just happen to exist in the same company, otherwise, nothing is really shared between them. When you compare Microsoft to Google with respect to maps APIs, you need to compare Google to MSN/Live/etc., which has seen many name and strategy changes and is far less mature than Google's offerings. Google APIs are consequently more stable and less likely to change.
A conservative approach will therefore recommend Google APIs. They are more seasoned, more tested, work on more browsers, and used successfully by far more organizations and businesses.
Both, I think. When FOSS software is used according to the licenses, it is a win for all parties involved.
The only possible losers are those with competing proprietary software.
In addition, they have not tested it on volunteers for long periods (and, by the description, 'long periods' may well be as short as 30 seconds!) - simply because who would volunteer for it? Even hardened marines apparently flee within seconds. We have no idea what will happen to people that suffer this ray for more than a fleeting instant - for all we know it might lead to an epileptic seizure or brain damage. It might also cause local damage to the nerves - overstimulation of nerves can lead to their death; this is called excitotoxicity.
Sadly, I am sure that the developers of this weapon have barbarically tested it on animals for 'long periods'. This is still not enough to convince me that it does not permanent damage; human brains are not identical to animal ones. In addition there is a tremendous psychological element to torture - the belief that the pain will continue; this is less of an issue for some animals.
Sorry for the long rant, but this weapon is a horrible idea. It is like the nuclear bomb of supposedly nonlethal weapons - too powerful for anyone to have. It should be outlawed by international convention IMHO. Let's develop nonlethal methods that incapacitate, etc., not that can be used to bring torture to new levels.
Regarding packaging, distutils and Eggs are very useful. But even without them the process seems reasonable to me (no less than for C/C++). Regarding error checking, you do lack compile-time checking, as a dynamic language - but the runtime checking is extremely convenient. Bug reports that include the crash output can lead to quite solutions in my experience, far more than for C/C++ (and you don't have any of the memory management errors). Regarding development environment, I use Gedit, so I guess you are referring to more 'complete' IDEs
I'm not great at this, so perhaps because of that I couldn't find the bug for the issue you mentioned. Can you post a link to it, so we can see what progress (if any) is being made on this matter?
A project as big as a desktop environment that needs to be extremely consistent throughout, needs a Linus. It needs one guy to be the benevolent dictator, because right now it looks like anyone can get any old thing in there. Tomboy a C# app? wtf? It's not complicated, it's an applet, a couple borderless windows, and a simple WebDAV client, all of which I'd bet lots of money Gnome already has libraries for. It could be just as easily implemented in C, and a halfway experienced Gnome developer could implement it, with all of its current features, in probably a week or less. I'm halfway tempted to take a week of vacation and do it myself just to prove a point.
I disagree. Why should all GNOME (or all KDE) apps be written in the same language? Sure, perhaps Tomboy could be written in C in a few weeks (say a few months to get all the bugs out), but it has already been written in C#, and works fine. I see no issue with this. Different languages have different advantages, and different programmers like different languages, which is perhaps even more important in a volunteer project like GNOME. Make GNOME C-only and you might lose out on a lot of developer mindshare.What we need is to allow multiple languages to work together; we don't want a situation where special 'bindings' need to be written on a per-language basis. As long as that is taken care of (by running on a VM like Mono, or automated bindings generation, etc.), then I see no issue.
(Resource-wise there is some penalty to this, yes, and that does annoy me.)
I was with you until the bold part (my emphasis). Yes, modern desktops (and all complex modern software) should probably be written in modern high-level languages. But why not Python? Python is exactly a good example of a modern language, I would think...
Sure, it's possible, but we all know that most people will do whatever is most convenient. If a single click buys them the tracks in iTunes, but it takes in the competitors' systems a click + some fiddling around with copying the files to the right place (using 2 different programs while doing so) - then I think iTunes will end up with most of the business.
Most geeks wouldn't mind the extra work, and might even do it on principle (I would). But the bulk of the market would use the simplest solution, and Apple is trying to make sure that iTunes is that solution, by making it harder for competitors to interface with their hardware.
-
If you are a small player in the market, it is in your best interest to get as many people as possible to buy your hardware. Letting them use whatever software they want is a plus. But,
-
If you already have most of the market, and expect to easily keep it, then you might consider ways to exploit that position. Microsoft has been doing this with Windows, for example; apparently Apple are trying to do the same. The issue is that DRM-free song sales have become a reality, which opens the possibility for Microsoft, Real, MTV etc. to sell you tracks and place them on your iPod. When the music labels only sold DRMed tracks, and the iPod only played Apple DRM, Apple wasn't worried. But now they are.
So, this is an expected business tactic. Consumer-friendly, though it is not. Consequently, I know I (a Linux user) won't be buying any iPods.Well actually SCO does 'own' UNIX... except for copyrights and trademarks. That's what their agreement with Novell said - literally.
I read TFAs, and they didn't calm me down at all. If you have any further information, please post it.
In fact there is already a version of Debian running on a BSD kernel, IIRC. So really most of the work has already been done. Is Hurd really that important to them, to continue working on it despite alternatives?
My theory at least. Anyhow, I don't expect anything good to come out of this 'interoperable virtualization' issue except for Microsoft (and possibly Novell).
Define 'appropriate', and you will have your answer immediately.
If you want to maximize immediate profits at all costs, use the most powerful copy-protection you can - phoning home, disabling suspect keys even at the cost of inconveniencing paying users, etc. etc.
If you believe the project has long-term possibilities, then you need to start worrying about pissing people off. Don't phone home. Minimal product activation once at installation.
If you believe the product has world-domination possibilities (i.e., that every product manager or whatever in the world will use it) then remove all copy protection. People pirating your software are part of your market share. Also, consider opening the source in an appropriate manner.
And if you are asking about 'appropriate' as in ethics, then certainly open-source the app. Note that this does not mean abandoning copy-protection! GPL (even GPL3) apps can have copy protection... it is just possible to remove it. 90% of users won't care about removing it (or know how); 10% of them might. Not a big loss considering the advantages.
C'mon, every decent editor has indentation shortcuts... :)
(Just one factor here.)
(However, there is also something to be said against this, in that we might want to not have separate accessibility frameworks for each app. That's true, however, for an office suite - sometimes the only app besides a web browser used on some PCs - it might make sense to customize it that way.)
(Seriously, though, Python is the only language where it is even remotely convenient to read other people's code.)
Ok, intelligence doesn't equal survivability or fitness. But they didn't say it does. Just that a singularity machine will be able to design more machines better than it at various tasks, including making more such machines, etc. In theory this is possible.
However, in practice, the singularity, if we will ever reach it, is very far away in the future. I work in the neural computation / statistical learning / AI fields, and I must say, they are nowhere near any singularity of any sort.
Basically the most successful achievements in this area are (1) computers that can beat people at chess/checkers/etc., and (2) systems that can identify handwriting/faces/fingerprints/other patterns. These successes are impressive, but bring us nowhere near anything like 'general intelligence' of the kind that humans (and other animals) have.
In addition more hardware can mean more potential security breaches, and so forth.
Yeah, you are right, I didn't think that part all the way through...
Speaking of Digg's sucky comment system, it is one of the reasons I don't use Digg anymore (the other being their deal with Microsoft).