Why is it that Linux offers pretty much the features of Windows or OS X, or Unix for that matter? What is new and unique to Linux from a usability or UI point of view?
You seem to be suggesting that people should be using new systems only if they offer "new and unique features". Well, why are you using Windows or Macintosh then? Those systems didn't offer "new and unique features" when they came out--most of their interfaces are copycat--derivative from earlier user interfaces of systems like UNIX and X11.
In reality, originality has little to do with commercial success or market share; when it comes to user interfaces, copying someone else and then improving on it is the norm, and there is nothing wrong with that.
And yes, I know about the benefits of free or open source software, but that doesn't explain what I can do in Linux that I can't do in OS X or Windows. [...] If it's just a political statement ("Software should be free!") then that's not much of a benefit for those of us who either don't agree or don't care enough.
Many people who use Linux use it for reasons like better reliability, usability, compatibility, interoperability, lower cost, and higher performance. If you don't care about any of those features, just don't use it--it's a free country.
If I recall correctly, the original code of the machintosh OS came from BSD 3... (Before they modifyed it extensively for commercial release)
No, that's not accurate. The OS X kernel is based on CMU Mach, with some BSD kernel code added to it. The command line utilities come from different sources, including a lot of BSD code. The compiler is GNU. Cocoa was essentially developed by NeXT, borrowing a lot of ideas from Smalltalk.
Now Opensource is taking the apple standard?
Dashboard is mostly web standards anyway (HTML, JavaScript, XML), the software components Apple is using for it are largely open source, and the concept of Dashboard comes from Konfabulator. So, I don't really think it's fair calling it "the apple standard", in particular since it's not a standard.
You'll probably get flamed or modded down for that statement, but I have to agree: while not bad, I think the OS X GUI is overrated. Gnome and KDE both have reached the point where they are more than competitive with any of the commercial GUIs out there.
No, there won't. The headline is misleading. Read carefully:
Read carefully yourself: the statement simply isn't definitive either way. The author will attempt to offer compatibility, but it may not be possible (presumably either for technical or legal reasons).
But even if full compatibility isn't possible, by keeping the systems very similar, many widgets should port very easily.
You can let it decay in a reasonably safe place - just like the fuel was doing before we dug it out of the ground.
No, it's not "just like" that; the stuff that we dig out of the ground has been decaying for billions of years; only the long-lived isotopes and a tiny amount of intermediate decay products are left.
The radiation hazard is inversely proportional to the half life - the isotopes that last for a million years are harmless compared to the ones that last seconds.
Yes, and that's exactly the problem: nuclear power creates large quantities of isotopes with half-lives of the order of millennia--highly radioactive and dangerous isotopes that do not occur naturally and that still require safe and secure long-term storage.
Things would be significantly better if nations built breeder reactors, reducing the amount of highly radioactive waste significantly. But not even that is being done out of concerns over proliferation.
These kinds products are already appearing; the limits right now are cost, standardization, and battery life, not the imagination of designers.
Morville's book is another instance of people without an original idea trying to pass themselves off as innovators, complete with the obligatory buzzwords and neologisms.
Microsoft's TxFS attempts to give full database-like compound transactions on top of the file system--an old idea, but that hasn't stopped Microsoft from patenting it anyway (6,856,993). UNIX does not directly support this in the kernel, although it can be provided through libraries in user code based on the primitives that UNIX already has.
From the application programmer's point of view, such transactions are actually simple to use. The problem with them is that they add a lot of complexity to the kernel for a feature that is rarely needed.
It may exist even if you look through 20 pages and don't find it. In fact, chances are that nearly all questions have an answer in some document on the web--people just can't find it.
More often, I think "Wow, this website is ALMOST what I want, but it's doesn't quite have enough information about topic X."
This may well be an indication that there is too much information and that our technology is not up to handling it: chances are the exact answer you want is actually there, but it has been pushed off the results list by all those ALMOST matches.
Oh really? And who exactly are you to tell me, or anyone else reading this, what a safe language is? Your argument is a common logical fallacy -- a weak appeal to your own authority -- and nothing more.
I'm not telling you anything on my own authority; these terms have specific meanings in computer science. If you don't know what they are, look for "safe language" on Google Scholar.
This is my point: some people focus on GC so much that they forget to address other problems.
There is little point addressing other problems before one addresses runtime safety.
Claiming that any language that provides GC but does not do these things as well could possibly be "safe" is irrational, and believing that your code is safe because you use such a language is delusional.
As I was saying: GC is necessary for safety. The fact that it is not sufficient is so trivial that only someone completely unfamiliar with the subject would find it necessary to point that out.
Neither OS X or Linux have a real transactional FS (Spotlight and Beagle just use a regular FS, and build a separate database), but that's OK because Vista isn't actually going to have it either!
First of all, you're confusing metadata storage with transactioning. Just because both are vaguely related to databases doesn't mean that they are related to each other.
However, Linux does, in fact, support both, through file systems like ReiserFS, XFS, and Ext3.
but for me there is a new networking & audio stacks, XPS & totally cool new printing system, transactional FS, and a lot more interesting stuff
I don't see anything there that doesn't already exist in both OS X and Linux. Care to contrast those features with their equivalent Linux and OS X features and explain where you think there is any innovative functionality in Vista?
I haven't seen a single piece of DTP software on linux that is useful.
I suspect there is more desktop publishing done in TeX/LaTeX than in any other single DTP software. Another widely used DTP software is DocBook.
Maybe you don't mean "DTP software" but "visual page layout software". There is some of that (e.g., Scribus), although that's such a specialized piece of software that there just isn't much demand for it.
I think we probably have quite different experiences here. Certainly your world, where a query-driven application like Tomcat is "high performance", is very different to mine, where things like 3D modelling, photorealistic rendering, and large scale simulations are bread and butter. Does anyone write CAD programs or supercomputer-based weather modellers using Java
Java is rarely used for numerical applications because Java's support for numerics is poor; some problems with Java are lack of overloading, lack of multidimensional arrays, inefficient generics, and lack of value classes. Those are specific shortcomings of the Java language.
Garbage collection and runtime safety are very valuable for 3D modeling, photorealistic rendering, and large scale simulations and do not cost you anything in terms of performance.
At the end of the day, GC is a useful tool for many programming jobs, but it's only a tool, not a silver bullet. It's no substitute for a good programmer who knows what he's doing.
Perhaps your problem is that you don't understand what a "safe language" is. A safe language is a language that makes guarantees about type errors, error detection, and fault isolation. A language with dynamic memory allocation needs to have a GC in order to be safe. A safe language does not make guarantees about security or parallelism or race conditions, it doesn't necessarily make programming any easier, and it doesn't necessarily help the programmer avoid errors.
And I make this case without, until now, mentioning the IME very real problem that a lot of cheaposoft programmers who grow up relying on GC don't have the same appreciation of low level mechanics as those who don't,
No, the problem is that there are too many people like you in this industry, people who don't even understand what a basic concept like a "safe language" means.
So what does that mean? It means Microsoft and Mac OS X are the ONLY operating systems with more than.005% of the market share.
That's a popular misconception. At this point, there are probably more Linux users out there than OS X users, and both Linux and OS X have at least several percent market share.
Modern unmanaged C++ is fine (STL containers instead of arrays, RAII, etc.),
Modern unmanaged C++ is NOT fine; STL permits many kinds of bugs that are analogous to buffer overflows. Furthermore, modern software systems are composed of many different modules, and just because you happen to be careful in your modules doesn't mean others are careful in theirs. Finally, without full garbage collection, you cannot have full runtime safety.
but I often wonder why people still write in C at all, particularly when it comes to Open Source software.
People prefer C to C++ because for the small increase in safety that C++ gives, it's far too complicated and complex a language. People don't use languages other than C/C++ because those languages interoperate poorly with existing C/C++-based libraries (this is C/C++'s fault), tend to have bloated runtimes, and have only a tiny user community. And, yes, many people don't even realize that there is a problem.
We are not the bearded heroes of the 70s - it's time to write in a modern language.
The bearded heroes of the 70s actually knew better. Back in the 1970's and 1980's, C was of no significance. When people were using HLLs back then, those languages were generally a lot safer than C. The rise of C was a historical accident, related to the rise of BSD UNIX and microcomputers.
But, yes, I share your sentiment: it would be good to see security bugs by language choice. And I'll give you this much: C++ is an improvement over C, but it's not a solution.
If we listened to just the media you would have thought Windows has thousands and the others only had a few dozen. I promise I'm not trolling, but do those numbers stop and make anyone on the site re-think stances?
No, it doesn't. First of all, there are a dozen different versions of UNIX and Linux, each with their own set of flaws. MacOS is an almost entirely different system except for a kernel compatibility module and a bunch of command line utilities. Second, the number of bugs discovered or number of bugs fixed tells you little about the security of an operating system. Individual bugs have very different consequences for system security.
I find myself defending MS allot on this site, and it's nice to have some numbers from a respected neutral organization to debate some of you guys with. I'm sure after this piece they will be re-classified as MS zealots, but what can ya do.
If you are using numbers like these to make an argument that MS products are "more secure", the zealot is you. But, then, you already admitted as much.
It's stuff like this that makes the big software corporations invest in patents.
No, it's not. Your own patent portfolio makes very little difference when you are being sued by an IP holding company--they aren't interested in cross-licensing, and they aren't infringing any of your patents.
Companies like google and microsoft don't draw significant revenue from patents and actually invest heavily in research. But having patents guarantees that they won't end up sueing each other.
That is true, and it's what makes the patent system so evil: patents and patent cross licensing is being used to create barriers to entry for new, innovative, small players.
Big companies have been able to avoid feeling the pain resulting from the current software patent system for too long. IP holding companies are changing that. As far as I'm concerned, that's a good thing. Give it another decade of big lawsuits by companies with nothing to lose and a lot to gain, and companies like Microsoft, IBM, Nokia, and Google may be begging for the elimination of software patents.
Many video blogs aren't talking heads, they are people recording video on the go and in nice locations. Others are more lecture style, with slides and voice.
And as usual, Nielsen overinterprets the data. Eye tracking data mainly just tells you about what people don't look at at all; most other interpretations beyond that are handwaving.
I think that characterization is wrong. Some experimental physicists may be content with building devices, but most physicists do want to understand this sort of thing--there are whole volumes of collected papers devoted to this--they simply haven't been able to come up with a good answer.
I think the main difference between philosophers and physicists is that philosophers are willing to deliberately write up and publish silly, partially formed ideas, while physicists will try to avoid doing so knowingly.
Followed by your statement "The restrictions in Java and C# are decidedly non-object-oriented, inherited from C++." That's what I took issue with.
The source of the problem is that the term "object-oriented" has changed its meaning. Object-oriented-1980 isn't the same as object-oriented-2005. The term object-oriented-2005 includes C++ and Simula, object-oriented-1980 does not. Object-oriented-2005 is a much less interesting term because it includes languages (like C++ and Simula) that lack important functionality that object-oriented-1980 languages have. I leave it to you to assign the correct values of object-oriented-1980 and object-oriented-2005 to the various statements in this discussion.
Those were actually the intentions of its creator; I guess he got them correct. Sometimes the purist's idea of "better" does match the constraints the realists are looking for.
Again, you're confusing the same term at different times. C++-1986 and C++-2005 are not the same language. Just because C++-1986 was a good design doesn't mean C++-2005 is. C++-1986 was good because it helped people cope better with mountains of existing C code, because of the computing environment at the time, and because the language was simple; that's why I chose it, for example. None of those constraints apply anymore. C++-2005 is only successful still because vendors and users have invested so much in it already. If C++-1986 or C++-2005 came onto the scene today as a new language, people would have a good laugh and not look twice.
"C++ is great for highly experienced teams developing certain kinds of high performance software, or for academics."
How ironic it is then that C++ enjoys much wider-spread usage than Smalltalk (primarily used by academics) and Obj-C (primarily used by acamedics and MacOS X developers).;)
Academics don't use either Smalltalk or Objective-C, and I wouldn't recommend you do either. Smalltalk simply illustrates a bunch of features that modern general purpose programming languages should have and that C++ lacks.
And, no, the widespread usage of C++ isn't "ironic", it's sad. Using C++ for desktop and server applications is the reason we have so many programs with buffer overflows, security holes, and delayed ship dates. It's responsible for easily avoidable crashes and corrupt data. It makes software hard to change, hard to use, and hard to extend.
Slashdot Mirror
Why is it that Linux offers pretty much the features of Windows or OS X, or Unix for that matter? What is new and unique to Linux from a usability or UI point of view?
You seem to be suggesting that people should be using new systems only if they offer "new and unique features". Well, why are you using Windows or Macintosh then? Those systems didn't offer "new and unique features" when they came out--most of their interfaces are copycat--derivative from earlier user interfaces of systems like UNIX and X11.
In reality, originality has little to do with commercial success or market share; when it comes to user interfaces, copying someone else and then improving on it is the norm, and there is nothing wrong with that.
And yes, I know about the benefits of free or open source software, but that doesn't explain what I can do in Linux that I can't do in OS X or Windows. [...] If it's just a political statement ("Software should be free!") then that's not much of a benefit for those of us who either don't agree or don't care enough.
Many people who use Linux use it for reasons like better reliability, usability, compatibility, interoperability, lower cost, and higher performance. If you don't care about any of those features, just don't use it--it's a free country.
If I recall correctly, the original code of the machintosh OS came from BSD 3... (Before they modifyed it extensively for commercial release)
No, that's not accurate. The OS X kernel is based on CMU Mach, with some BSD kernel code added to it. The command line utilities come from different sources, including a lot of BSD code. The compiler is GNU. Cocoa was essentially developed by NeXT, borrowing a lot of ideas from Smalltalk.
Now Opensource is taking the apple standard?
Dashboard is mostly web standards anyway (HTML, JavaScript, XML), the software components Apple is using for it are largely open source, and the concept of Dashboard comes from Konfabulator. So, I don't really think it's fair calling it "the apple standard", in particular since it's not a standard.
You'll probably get flamed or modded down for that statement, but I have to agree: while not bad, I think the OS X GUI is overrated. Gnome and KDE both have reached the point where they are more than competitive with any of the commercial GUIs out there.
No, there won't. The headline is misleading. Read carefully:
Read carefully yourself: the statement simply isn't definitive either way. The author will attempt to offer compatibility, but it may not be possible (presumably either for technical or legal reasons).
But even if full compatibility isn't possible, by keeping the systems very similar, many widgets should port very easily.
You can let it decay in a reasonably safe place - just like the fuel was doing before we dug it out of the ground.
No, it's not "just like" that; the stuff that we dig out of the ground has been decaying for billions of years; only the long-lived isotopes and a tiny amount of intermediate decay products are left.
The radiation hazard is inversely proportional to the half life - the isotopes that last for a million years are harmless compared to the ones that last seconds.
Yes, and that's exactly the problem: nuclear power creates large quantities of isotopes with half-lives of the order of millennia--highly radioactive and dangerous isotopes that do not occur naturally and that still require safe and secure long-term storage.
Things would be significantly better if nations built breeder reactors, reducing the amount of highly radioactive waste significantly. But not even that is being done out of concerns over proliferation.
These kinds products are already appearing; the limits right now are cost, standardization, and battery life, not the imagination of designers.
Morville's book is another instance of people without an original idea trying to pass themselves off as innovators, complete with the obligatory buzzwords and neologisms.
That's because there still is no long term storage solution for nuclear fuel; and once it's been created, you can't get rid of it.
Microsoft's TxFS attempts to give full database-like compound transactions on top of the file system--an old idea, but that hasn't stopped Microsoft from patenting it anyway (6,856,993). UNIX does not directly support this in the kernel, although it can be provided through libraries in user code based on the primitives that UNIX already has.
From the application programmer's point of view, such transactions are actually simple to use. The problem with them is that they add a lot of complexity to the kernel for a feature that is rarely needed.
It may exist even if you look through 20 pages and don't find it. In fact, chances are that nearly all questions have an answer in some document on the web--people just can't find it.
More often, I think "Wow, this website is ALMOST what I want, but it's doesn't quite have enough information about topic X."
This may well be an indication that there is too much information and that our technology is not up to handling it: chances are the exact answer you want is actually there, but it has been pushed off the results list by all those ALMOST matches.
Oh really? And who exactly are you to tell me, or anyone else reading this, what a safe language is? Your argument is a common logical fallacy -- a weak appeal to your own authority -- and nothing more.
I'm not telling you anything on my own authority; these terms have specific meanings in computer science. If you don't know what they are, look for "safe language" on Google Scholar.
This is my point: some people focus on GC so much that they forget to address other problems.
There is little point addressing other problems before one addresses runtime safety.
Claiming that any language that provides GC but does not do these things as well could possibly be "safe" is irrational, and believing that your code is safe because you use such a language is delusional.
As I was saying: GC is necessary for safety. The fact that it is not sufficient is so trivial that only someone completely unfamiliar with the subject would find it necessary to point that out.
Neither OS X or Linux have a real transactional FS (Spotlight and Beagle just use a regular FS, and build a separate database), but that's OK because Vista isn't actually going to have it either!
First of all, you're confusing metadata storage with transactioning. Just because both are vaguely related to databases doesn't mean that they are related to each other.
However, Linux does, in fact, support both, through file systems like ReiserFS, XFS, and Ext3.
but for me there is a new networking & audio stacks, XPS & totally cool new printing system, transactional FS, and a lot more interesting stuff
I don't see anything there that doesn't already exist in both OS X and Linux. Care to contrast those features with their equivalent Linux and OS X features and explain where you think there is any innovative functionality in Vista?
I haven't seen a single piece of DTP software on linux that is useful.
I suspect there is more desktop publishing done in TeX/LaTeX than in any other single DTP software. Another widely used DTP software is DocBook.
Maybe you don't mean "DTP software" but "visual page layout software". There is some of that (e.g., Scribus), although that's such a specialized piece of software that there just isn't much demand for it.
I think we probably have quite different experiences here. Certainly your world, where a query-driven application like Tomcat is "high performance", is very different to mine, where things like 3D modelling, photorealistic rendering, and large scale simulations are bread and butter. Does anyone write CAD programs or supercomputer-based weather modellers using Java
Java is rarely used for numerical applications because Java's support for numerics is poor; some problems with Java are lack of overloading, lack of multidimensional arrays, inefficient generics, and lack of value classes. Those are specific shortcomings of the Java language.
Garbage collection and runtime safety are very valuable for 3D modeling, photorealistic rendering, and large scale simulations and do not cost you anything in terms of performance.
Can it use SQLite as a backend? Running MySQL or PostgreSQL is overkill and unwarranted for these kinds of applications.
At the end of the day, GC is a useful tool for many programming jobs, but it's only a tool, not a silver bullet. It's no substitute for a good programmer who knows what he's doing.
Perhaps your problem is that you don't understand what a "safe language" is. A safe language is a language that makes guarantees about type errors, error detection, and fault isolation. A language with dynamic memory allocation needs to have a GC in order to be safe. A safe language does not make guarantees about security or parallelism or race conditions, it doesn't necessarily make programming any easier, and it doesn't necessarily help the programmer avoid errors.
And I make this case without, until now, mentioning the IME very real problem that a lot of cheaposoft programmers who grow up relying on GC don't have the same appreciation of low level mechanics as those who don't,
No, the problem is that there are too many people like you in this industry, people who don't even understand what a basic concept like a "safe language" means.
So what does that mean? It means Microsoft and Mac OS X are the ONLY operating systems with more than .005% of the market share.
That's a popular misconception. At this point, there are probably more Linux users out there than OS X users, and both Linux and OS X have at least several percent market share.
Modern unmanaged C++ is fine (STL containers instead of arrays, RAII, etc.),
Modern unmanaged C++ is NOT fine; STL permits many kinds of bugs that are analogous to buffer overflows. Furthermore, modern software systems are composed of many different modules, and just because you happen to be careful in your modules doesn't mean others are careful in theirs. Finally, without full garbage collection, you cannot have full runtime safety.
but I often wonder why people still write in C at all, particularly when it comes to Open Source software.
People prefer C to C++ because for the small increase in safety that C++ gives, it's far too complicated and complex a language. People don't use languages other than C/C++ because those languages interoperate poorly with existing C/C++-based libraries (this is C/C++'s fault), tend to have bloated runtimes, and have only a tiny user community. And, yes, many people don't even realize that there is a problem.
We are not the bearded heroes of the 70s - it's time to write in a modern language.
The bearded heroes of the 70s actually knew better. Back in the 1970's and 1980's, C was of no significance. When people were using HLLs back then, those languages were generally a lot safer than C. The rise of C was a historical accident, related to the rise of BSD UNIX and microcomputers.
But, yes, I share your sentiment: it would be good to see security bugs by language choice. And I'll give you this much: C++ is an improvement over C, but it's not a solution.
If we listened to just the media you would have thought Windows has thousands and the others only had a few dozen. I promise I'm not trolling, but do those numbers stop and make anyone on the site re-think stances?
No, it doesn't. First of all, there are a dozen different versions of UNIX and Linux, each with their own set of flaws. MacOS is an almost entirely different system except for a kernel compatibility module and a bunch of command line utilities. Second, the number of bugs discovered or number of bugs fixed tells you little about the security of an operating system. Individual bugs have very different consequences for system security.
I find myself defending MS allot on this site, and it's nice to have some numbers from a respected neutral organization to debate some of you guys with. I'm sure after this piece they will be re-classified as MS zealots, but what can ya do.
If you are using numbers like these to make an argument that MS products are "more secure", the zealot is you. But, then, you already admitted as much.
It's stuff like this that makes the big software corporations invest in patents.
No, it's not. Your own patent portfolio makes very little difference when you are being sued by an IP holding company--they aren't interested in cross-licensing, and they aren't infringing any of your patents.
Companies like google and microsoft don't draw significant revenue from patents and actually invest heavily in research. But having patents guarantees that they won't end up sueing each other.
That is true, and it's what makes the patent system so evil: patents and patent cross licensing is being used to create barriers to entry for new, innovative, small players.
Big companies have been able to avoid feeling the pain resulting from the current software patent system for too long. IP holding companies are changing that. As far as I'm concerned, that's a good thing. Give it another decade of big lawsuits by companies with nothing to lose and a lot to gain, and companies like Microsoft, IBM, Nokia, and Google may be begging for the elimination of software patents.
It may have been done before countless times, but it's just not innovation until Apple does it.
Many video blogs aren't talking heads, they are people recording video on the go and in nice locations. Others are more lecture style, with slides and voice.
And as usual, Nielsen overinterprets the data. Eye tracking data mainly just tells you about what people don't look at at all; most other interpretations beyond that are handwaving.
I think that characterization is wrong. Some experimental physicists may be content with building devices, but most physicists do want to understand this sort of thing--there are whole volumes of collected papers devoted to this--they simply haven't been able to come up with a good answer.
I think the main difference between philosophers and physicists is that philosophers are willing to deliberately write up and publish silly, partially formed ideas, while physicists will try to avoid doing so knowingly.
Followed by your statement "The restrictions in Java and C# are decidedly non-object-oriented, inherited from C++." That's what I took issue with.
;)
The source of the problem is that the term "object-oriented" has changed its meaning. Object-oriented-1980 isn't the same as object-oriented-2005. The term object-oriented-2005 includes C++ and Simula, object-oriented-1980 does not. Object-oriented-2005 is a much less interesting term because it includes languages (like C++ and Simula) that lack important functionality that object-oriented-1980 languages have. I leave it to you to assign the correct values of object-oriented-1980 and object-oriented-2005 to the various statements in this discussion.
Those were actually the intentions of its creator; I guess he got them correct. Sometimes the purist's idea of "better" does match the constraints the realists are looking for.
Again, you're confusing the same term at different times. C++-1986 and C++-2005 are not the same language. Just because C++-1986 was a good design doesn't mean C++-2005 is. C++-1986 was good because it helped people cope better with mountains of existing C code, because of the computing environment at the time, and because the language was simple; that's why I chose it, for example. None of those constraints apply anymore. C++-2005 is only successful still because vendors and users have invested so much in it already. If C++-1986 or C++-2005 came onto the scene today as a new language, people would have a good laugh and not look twice.
"C++ is great for highly experienced teams developing certain kinds of high performance software, or for academics."
How ironic it is then that C++ enjoys much wider-spread usage than Smalltalk (primarily used by academics) and Obj-C (primarily used by acamedics and MacOS X developers).
Academics don't use either Smalltalk or Objective-C, and I wouldn't recommend you do either. Smalltalk simply illustrates a bunch of features that modern general purpose programming languages should have and that C++ lacks.
And, no, the widespread usage of C++ isn't "ironic", it's sad. Using C++ for desktop and server applications is the reason we have so many programs with buffer overflows, security holes, and delayed ship dates. It's responsible for easily avoidable crashes and corrupt data. It makes software hard to change, hard to use, and hard to extend.