Depends on whose definition you follow. While I agree that the words alone mean no more than that, practically when talking about "open source" people mean something akin to the Open Source definition by OSI, which is closer to free software. A license prohibiting commercial use is also not open source according to that kind of a definition for the term.
One of the biggest problems with applications "ported" with Wine is that even if they work, their integration tends to suffer. At least decently made GTK applications integrate well with the rest of the Gnome desktop, unlike most applications under Wine that I've seen. The integration of GTK applications is reasonably good even under KDE with a suitable GTK theme applied (making the applications look more or less like Qt ones) and freedesktop.org standards (so drag'n'drop, notification area icons and other fancy stuff generally works).
Still, a Wine port might be a better option simply because it might actually be feasible, unlike a truely native port which could, depending on the code base, be a vast effort. I imagine that the code base shouldn't be that terrible with regard to cross-platform portability considering that it already runs on Macs and Windows, but who knows.
What most people forget, though, is that putting together a half-hearted port isn't enough. If you sell something, you have to support it, and supporting something running e.g. on top of Wine probably requires that you have a number of good Wine hackers employed. Supporting an extra platform can be a lot more expensive than the initial porting.
The orginal AT ran at 6Mhz and then was upgraded to 8Mhz soon after it was found that you could just put in a new crystal and get 8Mhz. Your way faster PC was only two to four Mhz faster. Gee that isn't even enough difference to spit at...
Just something like 25 to 50 percent.
Well, I'm not an expert, but with more advanced CPU generations you often also get more work done per clock cycle. The clock rate isn't the whole thing.
The 80286's performance was more than twice that of its predecessors (the Intel 8086 and Intel 8088) per clock cycle. In fact, the performance increase per clock cycle may be the largest among the generations of x86 processors. Calculation of the more complex addressing modes (such as base+index) had less clock penalty because it was performed by a special circuit in the 286; the 8086, its predecessor, had to perform effective address calculation in the general ALU, taking many cycles. Also, complex mathematical operations (such as MUL/DIV) took fewer clock cycles compared to the 8086.
Of course it may be that some of the improvements will only give a good performance boost with something bigger than the average real-mode DOS application, but it's still not quite right to look at just the clock rate.
I was able to watch one with Firefox and the Totem/Xine browser plugin on Gutsy with no problems. Not that I gained anything by watching. Anyway, VLC also seems to play the file.
On the other hand, I do have a custom-compiled install of ffmpeg on my system, but I'm not sure if the Xine libraries or VLC use it.
The discussion was about DRM, which is (an attempt at) a technical means to make it more difficult to do unwanted things with data -- unwanted by the party providing the data anyway. That is the technical side and has to do with what should be technically possible (with reasonable effort anyway) and what shouldn't. In the end, that has little to do with what you bring up: the social side, i.e. legislation and other non-technical ways of limiting what is allowed.
I'm not against people providing me data having some power regarding what I'm allowed to do with that data, yet I believe DRM is both bad and mostly going to fail, save for certain specific cases perhaps. I also want there to be limits as to what is allowed to be done with my private data, but I'm not suggesting that it should be technically limited by some sort of DRM. The two are completely unrelated.
With that definition of "basic functionality" I think I was able to get that and more on my work laptop in less than an hour. That included wireless networking and other stuff.
It really depends on the hardware, and will continue to do so until you get the OS officially supported by the manufacturer of the computer. That usually happens when the OS gets shipped with the hardware. Until then, comparing any pre-installed OS to any other OS will be comparing, well, apples to canonicals, or something.
The format also sucks compared to most everything else.
Which format? The Ogg container? The Theora video stream format? The Vorbis audio stream format? It's hard to give any credit to that statement when it's both inaccurate and given no arguments in support whatsoever.
I don't know why the container format would "suck compared to most everything else". Of course there may be something better (such as Matroska, perhaps), but "most everything else" includes obsolete things such as AVI and various other formats that really aren't that fancy. Ogg certainly beats those as a container. Just for the record, it is possible to put stream formats other than Theora and Vorbis within an Ogg container, but of course embedding formats that are clearly patent-encumbered within the container would sort of defeat the purpose.
Vorbis audio produces pretty nice results even with the current encoders, and that is no small feat considering that it has probably got much less attention than various MPEG audio formats. With regard to encoding quality and size even the current Vorbis encoders are among the best in the field of lossless audio encoding, at least if we consider only formats and encoders that are actually used somewhere outside of a lab. With more effort put into Vorbis encoding it might well prove to be pretty damn good.
In Theora you have a point -- the current quality is not particularly good -- but I don't think it's completely clear whether that's due to the current encoder implementations or limitations of the video stream format itself.
Haha, those ones are great in the Open Source world, specially when talking about bugs. Open source developers usually are like "there are no bugs! no no noallaalalalla no bugs in my program no, the bug does not exsist, no memory leak no you are dreaming"... and suddenly, after someone *fixes* the bug they say "Oh yeah, remember that memory bug you disliked a lot?, well I have fixed it in this new version". Funny.
Of course you'll find all kinds of people, including developers, in the F/OSS world. That should come as no surprise, and neither should the fact that the same applies to developers of proprietary software, both freelancers writing and maintaining their own small applications and those working for larger companies. What makes you think it's somehow exclusive to or particularly common in the F/OSS world is beyond me.
My few contributions to open source have been pretty much trivial fixes or minor improvements, and they've always been acknowledged, even on a level I consider undeserved. I've always appeared in the package changelog or release notes if I've fixed something (and once even when I just reported the (trivially fixable) problem and suggested a change).
This is obviously anecdotal, but my experience in both this regard and from my other understanding of various projects speaks against the kind of prevalence of such behaviuour that you suggest.
Flexibility is many times the opposite of easy-to-use.
I'm not sure you understand how widely Linux is used outside of the traditional "install Linux yourself on your own desktop" scenario.
End-users are not the only player in the market. Flexibility of the platform means that various other parties can prepare systems that suit the specific needs of the end-users better. Flexibility doesn't mean that the end-user has to bother with all its implications -- instead, the flexibility can also benefit end-users even if the only party directly exploiting the flexibility is someone providing the system.
As an example, having multiple virtualization models doesn't mean that you have to bother the end-user with all of them. A Linux distributor can choose one that suits their vision, and perhaps offer the other ones as options if users want them. That doesn't have to make the default setup of the main model chosen by the distributor any more complex for the end-user.
Flexibility can make things more complex but there's no reason why that would have to be directly exposed to uninterested parties if things are done right.
It's used by people who can respect and work around and with it's security. If it hits the mass market you can bet it'll be as helpful as the UAC on vista. That inherent security is dependent on the users.
That's true partially but not entirely. This topic has been beaten to death, but let me say this just once again: The security of Linux is partially due to more knowledgeable users, but also partially due to a saner design that eliminates some of the historical burden that plagues Windows.
A lot of problems on Windows are caused by ignorant users who will just click on whatever appears in their displays. The only way to stop Trojan horses is to educate people since the only difference between a legitimate third-party application and a Trojan is that the latter one does damage (and is generally distinguishable from the former by someone who knows what they're doing), and people will need to install applications anyway.
This is one good side of the distribution model in many Linux systems: most applications are installable through the tools of the Linux distributor from the software repositories of the same distributor. If you trust your OS provider, there's probably also reason to have some faith that packages that come from their repository and are signed by them are legitimate. And if you can't trust the OS provider, you're pretty much screwed anyway.
Another thing is that not only are the privileges of the normal user account traditionally limited (sort of like in UAC), the privileges of most daemons/services on the system are also limited because they run under a separate, non-root user account. Even if one of those daemons gets uninvited guests through a security hole, they won't be able to do harm to user files (because user x generally cannot access the files of user y unless user x is root, which it generally isn't) or read sensitive data, assuming that the system and applications are correctly configured.
Also, many systems such as Ubuntu don't have a bunch of ports open to the whole world by default, so exploiting one of these holes would be more difficult in any case. Even if Linux were more popular also among the masses, it would be less likely to see something like the Blaster or Sasser worms on Linux, and even if we saw one, it probably wouldn't be able to do much more than spreading. While it might be possible to exploit a local hole to get elevated privileges after breaking in to a restricted account, that would require the attacker to take advantage of more than one weakness. That would occasionally be possible, but the heterogenous environment where different distributions have different configurations would make such complex exploits more difficult and prone to error.
These are just examples. The fact that Unix/Linux traditionally has been built to contain things at least a little unlike early versions of Windows gives these operating systems an edge in security. Even if modern versions of Windows do something similar, the benefits can't be fully harvested due to legacy applications -- and even many modern ones -- not being compatible with the new development. The culture would need to change as well. Perhaps it is changing, but that is by no means a quick process.
Sure, now that the vulnerability is known, the likelihood of it being exploited just went through the roof. From TFA (the one that isn't slashdotted):
"The security researcher said he would not release code that shows how this attack works until Adobe provided a patch for the problem"
The Ubuntu numbers are the year and month of release.
I said:
"I know pretty well that the numbering is based on the release dates and I can infer either the release date from the version number or vice versa"
The release is every six months, so the second number is always.04 or.10
Except when an exception is made in the schedule, such as in the case of 6.06 whose release was delayed to June.
Again, I know fully well how the release numbers are derived, and I can easily cite the version numbers (and also the codenames) for all Ubuntu releases so far. I also realise that I'm probably not where a large part of the growth potential is -- after all, I had already been using Linux for years before the dawn of Ubuntu. For many other people the code names may be more convenient.
Actually, I believe most people use code names because they're easier than the version numbers are quite hard to remember and potentially confusing to people outside the geek circles.
People can remember 2.0, or 5.1, or even 10.4, but 6.06 or 7.04 (or 7.10) is a little too much. Many people probably don't even know whether the dots are supposed to be interpreted as decimal separators (which they are not) or just separators of otherwise independent numbers (which they are), causing them to think that 7.10 == 7.1 (not true in case of version numbers) while others will think 7.04 == 7.4 (which is correct in a sense). Whoopsie, the releases not only have confusing version numbers, they actually changed their mutual order just by simple confusion!
That's just one example of how the version numbering scheme in Ubuntu is confusing. I know pretty well that the numbering is based on the release dates and I can infer either the release date from the version number or vice versa, but frankly, most people who aren't especially enthusiastic about their computing platform don't care which month their OS was released, and to them the meaning in the version numbering scheme is lost and replaced with just overly complex numbers that nobody wants to use. That's certainly one reason why people call it "dapper" rather than 6.06.
Barring honeypots and routers with a hardened attack surface, I don't understand why anyone would connect any machine directly to the Internet without some type of hardware firewall.
(Current) hardware firewalls aren't exactly grandma compatible. The practical difference in effectiveness between software and hardware firewalls on Joe Common's machine probably isn't great enough to justify the extra hassle of a hardware firewall unless Joe has a tendency to run everything he gets by e-mail with administrator privileges -- in which case his system is pretty much doomed anyway.
One idea that would solve the problem for everybody involved would be having Lund offer NAT-ready firewalling routers with their Internet offerings
... thus breaking things even more by endorsing the use of NAT. If they wanted to do that for the sake of firewalling, that could easily be done without NAT. Sure, it wouldn't solve the DHCP problem, but the DHCP problem shouldn't exist in the first place. Besides, it's equally possible for a semi-broken DHCP implementation in some new OS release to fail to communicate with the DHCP server in the ISP-provided NAT box, thus only moving the problem to a slightly different component. Granted, offering such boxes might still solve the problem temporarily.
If the version numbering were better, I don't think the code names would matter so much. The numbering based on release dates is only useful for those who know when the releases were done in the first place, and for most other people version numbers like 6.06 are only confusing -- not to mention that some people will take the liberty to consider 7.04 equal to 7.4 and others, a lot more erringly, consider 7.10 the same as 7.1. Whoops, the releases just changed their mutual order. Version numbers like 2.0 would be a lot easier to remember as well.
The code names could be whatever if they weren't actually used practically every time versions or releases are discussed. People might opt for using the version numbers instead if they weren't so damn complex.
Let me add that some of those people may be more or less forced to use Vista, too. This may be due to work or because it can be difficult to get a new computer with an XP license instead of Vista.
There are lots of geeks who use Windows and who care about the problems they face. Not everyone who is proficient in the IT field never touches Windows. (Personally, I rarely do, and I probably wouldn't even notice the problem in the rare cases when I do.)
Slashdot Mirror
Perhaps a 99.9% free system is still better than a fully proprietary one.
Depends on whose definition you follow. While I agree that the words alone mean no more than that, practically when talking about "open source" people mean something akin to the Open Source definition by OSI, which is closer to free software. A license prohibiting commercial use is also not open source according to that kind of a definition for the term.
One of the biggest problems with applications "ported" with Wine is that even if they work, their integration tends to suffer. At least decently made GTK applications integrate well with the rest of the Gnome desktop, unlike most applications under Wine that I've seen. The integration of GTK applications is reasonably good even under KDE with a suitable GTK theme applied (making the applications look more or less like Qt ones) and freedesktop.org standards (so drag'n'drop, notification area icons and other fancy stuff generally works).
Still, a Wine port might be a better option simply because it might actually be feasible, unlike a truely native port which could, depending on the code base, be a vast effort. I imagine that the code base shouldn't be that terrible with regard to cross-platform portability considering that it already runs on Macs and Windows, but who knows.
What most people forget, though, is that putting together a half-hearted port isn't enough. If you sell something, you have to support it, and supporting something running e.g. on top of Wine probably requires that you have a number of good Wine hackers employed. Supporting an extra platform can be a lot more expensive than the initial porting.
Ah, that's correct -- it was the "original PC-AT" that was mentioned. My bad.
Well, I'm not an expert, but with more advanced CPU generations you often also get more work done per clock cycle. The clock rate isn't the whole thing.
Thus says Wikipedia:
The 80286's performance was more than twice that of its predecessors (the Intel 8086 and Intel 8088) per clock cycle. In fact, the performance increase per clock cycle may be the largest among the generations of x86 processors. Calculation of the more complex addressing modes (such as base+index) had less clock penalty because it was performed by a special circuit in the 286; the 8086, its predecessor, had to perform effective address calculation in the general ALU, taking many cycles. Also, complex mathematical operations (such as MUL/DIV) took fewer clock cycles compared to the 8086.Of course it may be that some of the improvements will only give a good performance boost with something bigger than the average real-mode DOS application, but it's still not quite right to look at just the clock rate.
I was able to watch one with Firefox and the Totem/Xine browser plugin on Gutsy with no problems. Not that I gained anything by watching. Anyway, VLC also seems to play the file.
On the other hand, I do have a custom-compiled install of ffmpeg on my system, but I'm not sure if the Xine libraries or VLC use it.
The discussion was about DRM, which is (an attempt at) a technical means to make it more difficult to do unwanted things with data -- unwanted by the party providing the data anyway. That is the technical side and has to do with what should be technically possible (with reasonable effort anyway) and what shouldn't. In the end, that has little to do with what you bring up: the social side, i.e. legislation and other non-technical ways of limiting what is allowed.
I'm not against people providing me data having some power regarding what I'm allowed to do with that data, yet I believe DRM is both bad and mostly going to fail, save for certain specific cases perhaps. I also want there to be limits as to what is allowed to be done with my private data, but I'm not suggesting that it should be technically limited by some sort of DRM. The two are completely unrelated.
With that definition of "basic functionality" I think I was able to get that and more on my work laptop in less than an hour. That included wireless networking and other stuff.
It really depends on the hardware, and will continue to do so until you get the OS officially supported by the manufacturer of the computer. That usually happens when the OS gets shipped with the hardware. Until then, comparing any pre-installed OS to any other OS will be comparing, well, apples to canonicals, or something.
If they're really advanced, they might actually be able to figure out how to use Evolution, and even not to crash it.
Meaning "lossy audio encoding", obviously.
Which format? The Ogg container? The Theora video stream format? The Vorbis audio stream format? It's hard to give any credit to that statement when it's both inaccurate and given no arguments in support whatsoever.
I don't know why the container format would "suck compared to most everything else". Of course there may be something better (such as Matroska, perhaps), but "most everything else" includes obsolete things such as AVI and various other formats that really aren't that fancy. Ogg certainly beats those as a container. Just for the record, it is possible to put stream formats other than Theora and Vorbis within an Ogg container, but of course embedding formats that are clearly patent-encumbered within the container would sort of defeat the purpose.
Vorbis audio produces pretty nice results even with the current encoders, and that is no small feat considering that it has probably got much less attention than various MPEG audio formats. With regard to encoding quality and size even the current Vorbis encoders are among the best in the field of lossless audio encoding, at least if we consider only formats and encoders that are actually used somewhere outside of a lab. With more effort put into Vorbis encoding it might well prove to be pretty damn good.
In Theora you have a point -- the current quality is not particularly good -- but I don't think it's completely clear whether that's due to the current encoder implementations or limitations of the video stream format itself.
Of course you'll find all kinds of people, including developers, in the F/OSS world. That should come as no surprise, and neither should the fact that the same applies to developers of proprietary software, both freelancers writing and maintaining their own small applications and those working for larger companies. What makes you think it's somehow exclusive to or particularly common in the F/OSS world is beyond me.
My few contributions to open source have been pretty much trivial fixes or minor improvements, and they've always been acknowledged, even on a level I consider undeserved. I've always appeared in the package changelog or release notes if I've fixed something (and once even when I just reported the (trivially fixable) problem and suggested a change).
This is obviously anecdotal, but my experience in both this regard and from my other understanding of various projects speaks against the kind of prevalence of such behaviuour that you suggest.
I'm not sure you understand how widely Linux is used outside of the traditional "install Linux yourself on your own desktop" scenario.
End-users are not the only player in the market. Flexibility of the platform means that various other parties can prepare systems that suit the specific needs of the end-users better. Flexibility doesn't mean that the end-user has to bother with all its implications -- instead, the flexibility can also benefit end-users even if the only party directly exploiting the flexibility is someone providing the system.
As an example, having multiple virtualization models doesn't mean that you have to bother the end-user with all of them. A Linux distributor can choose one that suits their vision, and perhaps offer the other ones as options if users want them. That doesn't have to make the default setup of the main model chosen by the distributor any more complex for the end-user.
Flexibility can make things more complex but there's no reason why that would have to be directly exposed to uninterested parties if things are done right.
The first thought to cross my mind when I read the summary was that this gives a whole new meaning to the word "propeller head".
That's true partially but not entirely. This topic has been beaten to death, but let me say this just once again: The security of Linux is partially due to more knowledgeable users, but also partially due to a saner design that eliminates some of the historical burden that plagues Windows.
A lot of problems on Windows are caused by ignorant users who will just click on whatever appears in their displays. The only way to stop Trojan horses is to educate people since the only difference between a legitimate third-party application and a Trojan is that the latter one does damage (and is generally distinguishable from the former by someone who knows what they're doing), and people will need to install applications anyway.
This is one good side of the distribution model in many Linux systems: most applications are installable through the tools of the Linux distributor from the software repositories of the same distributor. If you trust your OS provider, there's probably also reason to have some faith that packages that come from their repository and are signed by them are legitimate. And if you can't trust the OS provider, you're pretty much screwed anyway.
Another thing is that not only are the privileges of the normal user account traditionally limited (sort of like in UAC), the privileges of most daemons/services on the system are also limited because they run under a separate, non-root user account. Even if one of those daemons gets uninvited guests through a security hole, they won't be able to do harm to user files (because user x generally cannot access the files of user y unless user x is root, which it generally isn't) or read sensitive data, assuming that the system and applications are correctly configured.
Also, many systems such as Ubuntu don't have a bunch of ports open to the whole world by default, so exploiting one of these holes would be more difficult in any case. Even if Linux were more popular also among the masses, it would be less likely to see something like the Blaster or Sasser worms on Linux, and even if we saw one, it probably wouldn't be able to do much more than spreading. While it might be possible to exploit a local hole to get elevated privileges after breaking in to a restricted account, that would require the attacker to take advantage of more than one weakness. That would occasionally be possible, but the heterogenous environment where different distributions have different configurations would make such complex exploits more difficult and prone to error.
These are just examples. The fact that Unix/Linux traditionally has been built to contain things at least a little unlike early versions of Windows gives these operating systems an edge in security. Even if modern versions of Windows do something similar, the benefits can't be fully harvested due to legacy applications -- and even many modern ones -- not being compatible with the new development. The culture would need to change as well. Perhaps it is changing, but that is by no means a quick process.
I said:
"I know pretty well that the numbering is based on the release dates and I can infer either the release date from the version number or vice versa" The release is every six months, so the second number is alwaysExcept when an exception is made in the schedule, such as in the case of 6.06 whose release was delayed to June.
Again, I know fully well how the release numbers are derived, and I can easily cite the version numbers (and also the codenames) for all Ubuntu releases so far. I also realise that I'm probably not where a large part of the growth potential is -- after all, I had already been using Linux for years before the dawn of Ubuntu. For many other people the code names may be more convenient.
Actually, I believe most people use code names because they're easier than the version numbers are quite hard to remember and potentially confusing to people outside the geek circles.
People can remember 2.0, or 5.1, or even 10.4, but 6.06 or 7.04 (or 7.10) is a little too much. Many people probably don't even know whether the dots are supposed to be interpreted as decimal separators (which they are not) or just separators of otherwise independent numbers (which they are), causing them to think that 7.10 == 7.1 (not true in case of version numbers) while others will think 7.04 == 7.4 (which is correct in a sense). Whoopsie, the releases not only have confusing version numbers, they actually changed their mutual order just by simple confusion!
That's just one example of how the version numbering scheme in Ubuntu is confusing. I know pretty well that the numbering is based on the release dates and I can infer either the release date from the version number or vice versa, but frankly, most people who aren't especially enthusiastic about their computing platform don't care which month their OS was released, and to them the meaning in the version numbering scheme is lost and replaced with just overly complex numbers that nobody wants to use. That's certainly one reason why people call it "dapper" rather than 6.06.
You're completely right, but I'm still a little baffled -- what do you get when you divide WMA by MP3 and then re-assign the result to WMA? ;-)
Maybe they don't owe you anything (actually I think they do but that's another story), but most companies want you to buy their next product, too.
Poor you. It must be very dull without unicode support.
(Current) hardware firewalls aren't exactly grandma compatible. The practical difference in effectiveness between software and hardware firewalls on Joe Common's machine probably isn't great enough to justify the extra hassle of a hardware firewall unless Joe has a tendency to run everything he gets by e-mail with administrator privileges -- in which case his system is pretty much doomed anyway.
One idea that would solve the problem for everybody involved would be having Lund offer NAT-ready firewalling routers with their Internet offerings... thus breaking things even more by endorsing the use of NAT. If they wanted to do that for the sake of firewalling, that could easily be done without NAT. Sure, it wouldn't solve the DHCP problem, but the DHCP problem shouldn't exist in the first place. Besides, it's equally possible for a semi-broken DHCP implementation in some new OS release to fail to communicate with the DHCP server in the ISP-provided NAT box, thus only moving the problem to a slightly different component. Granted, offering such boxes might still solve the problem temporarily.
If the version numbering were better, I don't think the code names would matter so much. The numbering based on release dates is only useful for those who know when the releases were done in the first place, and for most other people version numbers like 6.06 are only confusing -- not to mention that some people will take the liberty to consider 7.04 equal to 7.4 and others, a lot more erringly, consider 7.10 the same as 7.1. Whoops, the releases just changed their mutual order. Version numbers like 2.0 would be a lot easier to remember as well.
The code names could be whatever if they weren't actually used practically every time versions or releases are discussed. People might opt for using the version numbers instead if they weren't so damn complex.
Let me add that some of those people may be more or less forced to use Vista, too. This may be due to work or because it can be difficult to get a new computer with an XP license instead of Vista.
There are lots of geeks who use Windows and who care about the problems they face. Not everyone who is proficient in the IT field never touches Windows. (Personally, I rarely do, and I probably wouldn't even notice the problem in the rare cases when I do.)