Yes, that was my experience as well. I tried building a Cocoa app using only a text editor and a Makefile, and it was a lot of trouble, especially tracking down all the libraries that need to be linked.
Qt "by hand" isn't perfect, but it's better than Cocoa.
How long before AT&T makes a statement of being the "real" owner of Unix?
Why stop there?
According to SCO's response, "SCO has the contractual right to prevent improper donations of UNIX code, methods or concepts into Linux by any UNIX vendor."
Protecting their code is understandable, but "methods and concepts" is dangerous ground. If a court interprets this the way SCO hopes they do, then the owners of Multics IP could turn around and sue SCO. This could work all the way back to the guy who first came up with the idea of binary representation for instructions and data in digital computer systems, at which point no-one can write a simple "hello world" program without violating someone's IP.
And all of this comes to us via a system that supposed to foster innovation. It's not hard to see that something is seriously messed up.
Are you sure about glibc 2.3? I think I remember seeing 2.9.x in Rawhide about a month ago, which lead me to believe that the next major release of glibc would be 3.0.
A few day ago, Linux Today posters on various Mono-related articles were insisting, apparently in all seriousness, that Miguel de Icaza is a Microsoft mole, and speculating that Richard Stallman is, as well. Almost every discussion there involves accusations of astroturfing, with Joe Barr, who seems to be involved here, leading the pack.
Yeah, there were a few comments along those lines, but I don't think it was all astroturfing -- some people really do believe Miguel is a MSFT mole, as irrational as that may sound. And I wouldn't be too quick to dismiss something that Joe Barr wrote and Nick Petreley published -- they both have reputations to maintain, and I'm sure they wouldn't have gone out on a limb without being very sure of their evidence. It seems likely that the evidence came from an LT insider, but that's just speculation on my part.
I torqued my back cranking a 2000 lb. boat onto a dry bunk trailer at a bad ramp. I found that sitting hunched over a keyboard to be good physical therapy. Repeat at 12 hour intervals as needed.
PS. This worked for me, but it might cripple you for life. I recommend consulting your physician before engaging in physically demanding activites such as hacking in 12 hour stints.
Academics have spent years devising the correct way to design software:
1. Research the problem.
2. Design the software.
3. Implement the software, according to the design.
4. Test software, adjust design if necessary, return to 3.
This is the correct way to design mediocre software, the kind no-one wants to use. Following this plan restricts you to working with the knowledge, understanding, and insight that you had when you started the project. Changing the last point to "return to 1" improves this process to the point where its at least useable.
There is no definite line where you can seperate feature creep from inspiration, which is why software deadlines are best expressed in vague terms...
So then your talking about the case where the interface was not designed properly which is just crappy software and not worth talking about.
This would eliminate about 90% of the software in use today, open source or otherwise.
Theoretical computer science makes three assumption about components: [1] the implementation is perfect, [2] the public interface is 100% documented and correct, and [3] users of the component follow the interface 100%. In the Real World, things don't work this way.
I think with a little thought and a little more hands on with something OO and you would sway the other direction.
I went through the 'everything is an object' phase in 1994. I got over it.
Well, lets take a look at your stack example in more detail. In theory, everything works peachy _if_ the stack was implemented without error. If, on the other hand, it is used by several projects before a subtle bug is discovered and corrected, then there could be problems if one or more of the applications are depending on behavior that changed when the bug was fixed. This happens a lot -- with each new version of most libraries, applications start to break. The problem is, for which application do you fix the behavior? There is a stated interface for your stack, but what about behavior that is not guaranteed by your interface, yet exists? This is where the finger pointing starts, with users of the stack blaming the implementor, and the implementor saying things like 'you're relying on behavior thats not guaranteed by the interface'.
This isn't to say that code reuse is a bad idea; some good examples are malloc() and gets().:-) This sounds trivial, and we take these fucntions for granted, but how much harder would it be to write even a simple program if the programmer had to deal with raw i/o and memory allocation. I'm all for software reuse, but at a very fine-grained level.
I really can't find much here that I can agree with.
Code Reuse was the mantra in the eighties, not the Next Big Thing for the year 2000. There are obviously some cases where it makes sense, but its not a cure-all for derailed software projects. Code reuse is well suited to projects with a short development cycle, a short life cycle, and a small user base. Most internal IT applications fall in this category. But it doesn't make much sense for projects with ongoing, constant development, long life cycles, and millions of users. This is where fine-tuning "custom" code makes sense, despite the current aversion to hand-written code by people who consider themselves to be knowledgeable about such things. Every re-write is an opportunity to improve the code. Software reuse effectively eliminates this opportunity, and in time leads to an obsolete and brittle code base. Code reuse is a part of effective software development, but it shouldn't be the central tenant around which it revolves. That distinction
belongs to good design and well-written code.
The 'no policy' policy of X is a Good Thing, in my opinion. There are some advantages to having a consistent UI, but they are outweighed by the disadvantages. A certain amount of chaos always accompanies innovation, but chaos is better than being subjugated to an inflexible policy. There are always going to be people who want to force their ways of doing things upon others, and UI policies are a great way for them to accomplish this. The best policies are the ones that are voluntarily adopted by large numbers of users over time. If it works for that many people, then there's probably something good about it. But if there isn't consensus in a particular area, trying to enforce policy is not going to meet with much success. MSFT gets away with this because they have a more or less captive user base.
Miguel has a few good points here, but overall this article could be more appropriately titled "Let's make UNIX suck like Windows".
I used KDE as my main desktop for about 15 months before switching to GNOME last week. My initial impression is that GNOME is indead slower than KDE on similar hardware, but it still runs ok on what I've got (P2-300, 128 MB RAM, RIVA TNT). Its also not as far along as KDE as far as features go, but the "October" release seems to be much more stable than the version that shipped with RH 6.1 (1.0.39, I think).
So far I have to say that I like GNOME better than KDE, despite some of its shortcomings. The default E theme that RH uses is very clean, and I like the look of the GTK+ widgets. I'm not sure that there will be a clear winner here; both KDE and GNOME are miles ahead of the Windows UI. I'm looking forward to GNOME 1.2 and the stuff eazel is working on, but KDE 2.0 looks like its going to be great too.
BTW, this is the first time I've been out here in about six months, and I was dismayed to discover what a cesspool/. has become.:-(
My personal view is that the number one way to improve any piece of software is to make it smaller. Removing stuff you're not using is a good place to start.
Your comment about using the BIOS to boot Linux reminded me of sonething else: that 4 partition limit on hard drives should be retired as well. Staying with my theme of nice round binary numbers - 1, a 255 partition limit would be nice. BTW, I'm referring to "real" partitions, not an extended paritition with a linked-list of logical drives.
Do you really want to add 64 wires to the PCI bus?
No, I want 255!:-)
The important thing is to start with an architecture that has more headroom than you might possibly ever need. Apparently IBM felt in 1981 that 8 IRQs were more than enough, which is why they ended up cascading to a second interrupt controller 4 just years later.
Rather than getting rid of IRQs, what you really want to do is increase the number of available IRQs [snip]
Agreed. In particular, the "cascade from IRQ 2 to IRQ 9" hack that the IBM/AT used should be layed to rest. A single interrupt controller with IRQs from 0-63, or even 0-255, would be fine.
Cleaning out the BIOS would be nice too. Linux doesn't use it much, and I suspect that Windows doesn't use it much either. For one thing, most of its a bunch of obsolete real-mode rountines, and you can never count on them working anyway. Nobody wants to spend time patching around BIOS related bugs in their software; its easier to write your own routines than try to deal with several hundred different implementations in BIOS, some of them almost certain to be incorrect and buggy. IMO a minimalist BIOS would be best: just find the hardware and inititialize and test it.
So this situation can probably be avoided entirely by avoiding virtual functions, overloaded operators, multiple inheritance, and anything else that requires late binding.
Pure OO programmers would find this unacceptable, but since I tend to view C++ as a better C, the idea appeals to me. I can happily get by with just classes (for better interfaces between parts of a system), inline functions (pre-processor macros are evil!), and stronger type checking.
Examples of proprietary extensions in COL 2.3: Partition Magic and Lizard(QPL==proprietary)
I don't want to start up yet license flame war, but even RMS has admitted that the QPL is an acceptable free software license. He didn't sound too happy about it, but he did make that admission.
Hope someone will tell me more about caldera, if it's really cool i'll buy one to every newbie who badge me:)
I've been using COL since version 1.1 (with brief detours to RH, SuSE, and Linux-Mandrake), and I like it a lot. One of the reasons I use it is that I provide Linux tech support to a few friends. Its easier for them to use than some other distros, and its easier for me to troubleshoot problems if I'm running the same distro.
The other reason is that Caldera tends to hold back on stuff until its stable. For example, RH 6.1 uses a RH-patched 2.2.12 kernel, and Linux-Mandrake 6.1 uses a pre-patched 2.2.13 kernel, while Caldera held back and used 2.2.10, which was the last stable kernel in the so-called stable tree until 2.2.13 was released a few days ago.
Then you will have tons of remote vtable lookups all throughout the code, causing really poor cache efficiency and potentially a lot page thrashing when memory is tight.
I was under the impression that the vtable was used for virtual functions, and didn't have anyting to do with classes. Is this related to the C++ inheritance mechanism, and would this still be an issue if new classes were derived using composition instead of inheritance?
Ah, well... I was assuming that we were talking about new projects; its sort of obvious that you can't forget about code that someone else has already written and needs to be maintained.
I can't think of a good reason to use C for anything new, now that there is an ISO standard for C++, but sometimes I do it anyway.:-|
The press likes to make a big deal about fragmentation, but its not a real issue.
Back in the early 90's, there was almost non-stop talk about how fragmentation was going to kill UNIX. ZD pronounced UNIX dead at least a dozen times. But when UNIX vendors began to cooperate, all of a sudden they dropped it. POSIX wasn't interesting news, so they moved on to something else. UNIX still isn't dead, and MS is still trying to produce an OS capable of competing with it.
A code fork will never kill Linux; in the end, it can only improve it.
ISO C isn't perfect by a long shot, but those who claim that using C effectively in a large project isn't a realistic thing to do are simply wrong.
While one can use C for large projects, using even a very restricted subset of C++ is probably a better solution. For example, if the only C++ feature you use is classes, you can design a much cleaner interface between different parts of a large software system.
A lot of people take the "all or nothing" approach to C++, but it wasn't designed to be used that way. Use what you need, and forget about the rest.
Slashdot Mirror
Yes, that was my experience as well. I tried building a Cocoa app using only a text editor and a Makefile, and it was a lot of trouble, especially tracking down all the libraries that need to be linked.
Qt "by hand" isn't perfect, but it's better than Cocoa.
Peanut butter and silkworm sandwiches!
I think I'll stay with grape.
I was hopeful that www.tiobe.com would do a "Programming Community Index for April 1, 2008" page, but it didn't happen.
...
...
Something like this:
1. Rebol
2. Eiffel
3. Dylan
4. Caml
5. Objective-C
6. Forth
7. ML
8. Haskell
9. Smalltalk
51. Cobol
52. RPG
101. Visual Basic
Darl's hidden card: he plans to plead insanity.
Why stop there?
According to SCO's response, "SCO has the contractual right to prevent improper donations of UNIX code, methods or concepts into Linux by any UNIX vendor."
Protecting their code is understandable, but "methods and concepts" is dangerous ground. If a court interprets this the way SCO hopes they do, then the owners of Multics IP could turn around and sue SCO. This could work all the way back to the guy who first came up with the idea of binary representation for instructions and data in digital computer systems, at which point no-one can write a simple "hello world" program without violating someone's IP.
And all of this comes to us via a system that supposed to foster innovation. It's not hard to see that something is seriously messed up.
Are you sure about glibc 2.3? I think I remember seeing 2.9.x in Rawhide about a month ago, which lead me to believe that the next major release of glibc would be 3.0.
Yeah, there were a few comments along those lines, but I don't think it was all astroturfing -- some people really do believe Miguel is a MSFT mole, as irrational as that may sound. And I wouldn't be too quick to dismiss something that Joe Barr wrote and Nick Petreley published -- they both have reputations to maintain, and I'm sure they wouldn't have gone out on a limb without being very sure of their evidence. It seems likely that the evidence came from an LT insider, but that's just speculation on my part.
PS. This worked for me, but it might cripple you for life. I recommend consulting your physician before engaging in physically demanding activites such as hacking in 12 hour stints.
1. Research the problem.
2. Design the software.
3. Implement the software, according to the design.
4. Test software, adjust design if necessary, return to 3.
This is the correct way to design mediocre software, the kind no-one wants to use. Following this plan restricts you to working with the knowledge, understanding, and insight that you had when you started the project. Changing the last point to "return to 1" improves this process to the point where its at least useable.
There is no definite line where you can seperate feature creep from inspiration, which is why software deadlines are best expressed in vague terms...
That was no joke -- its an embarassing mistake! Thanks for pointing out my error. Ok, version 1.0.1: malloc and fgets. :-)
This would eliminate about 90% of the software in use today, open source or otherwise.
Theoretical computer science makes three assumption about components: [1] the implementation is perfect, [2] the public interface is 100% documented and correct, and [3] users of the component follow the interface 100%. In the Real World, things don't work this way.
I think with a little thought and a little more hands on with something OO and you would sway the other direction.
I went through the 'everything is an object' phase in 1994. I got over it.
This isn't to say that code reuse is a bad idea; some good examples are malloc() and gets(). :-) This sounds trivial, and we take these fucntions for granted, but how much harder would it be to write even a simple program if the programmer had to deal with raw i/o and memory allocation. I'm all for software reuse, but at a very fine-grained level.
Code Reuse was the mantra in the eighties, not the Next Big Thing for the year 2000. There are obviously some cases where it makes sense, but its not a cure-all for derailed software projects. Code reuse is well suited to projects with a short development cycle, a short life cycle, and a small user base. Most internal IT applications fall in this category. But it doesn't make much sense for projects with ongoing, constant development, long life cycles, and millions of users. This is where fine-tuning "custom" code makes sense, despite the current aversion to hand-written code by people who consider themselves to be knowledgeable about such things. Every re-write is an opportunity to improve the code. Software reuse effectively eliminates this opportunity, and in time leads to an obsolete and brittle code base. Code reuse is a part of effective software development, but it shouldn't be the central tenant around which it revolves. That distinction belongs to good design and well-written code.
The 'no policy' policy of X is a Good Thing, in my opinion. There are some advantages to having a consistent UI, but they are outweighed by the disadvantages. A certain amount of chaos always accompanies innovation, but chaos is better than being subjugated to an inflexible policy. There are always going to be people who want to force their ways of doing things upon others, and UI policies are a great way for them to accomplish this. The best policies are the ones that are voluntarily adopted by large numbers of users over time. If it works for that many people, then there's probably something good about it. But if there isn't consensus in a particular area, trying to enforce policy is not going to meet with much success. MSFT gets away with this because they have a more or less captive user base.
Miguel has a few good points here, but overall this article could be more appropriately titled "Let's make UNIX suck like Windows".
So far I have to say that I like GNOME better than KDE, despite some of its shortcomings. The default E theme that RH uses is very clean, and I like the look of the GTK+ widgets. I'm not sure that there will be a clear winner here; both KDE and GNOME are miles ahead of the Windows UI. I'm looking forward to GNOME 1.2 and the stuff eazel is working on, but KDE 2.0 looks like its going to be great too.
BTW, this is the first time I've been out here in about six months, and I was dismayed to discover what a cesspool /. has become. :-(
My personal view is that the number one way to improve any piece of software is to make it smaller. Removing stuff you're not using is a good place to start.
Your comment about using the BIOS to boot Linux reminded me of sonething else: that 4 partition limit on hard drives should be retired as well. Staying with my theme of nice round binary numbers - 1, a 255 partition limit would be nice. BTW, I'm referring to "real" partitions, not an extended paritition with a linked-list of logical drives.
TedC
No, I want 255! :-)
The important thing is to start with an architecture that has more headroom than you might possibly ever need. Apparently IBM felt in 1981 that 8 IRQs were more than enough, which is why they ended up cascading to a second interrupt controller 4 just years later.
TedC
Agreed. In particular, the "cascade from IRQ 2 to IRQ 9" hack that the IBM/AT used should be layed to rest. A single interrupt controller with IRQs from 0-63, or even 0-255, would be fine.
Cleaning out the BIOS would be nice too. Linux doesn't use it much, and I suspect that Windows doesn't use it much either. For one thing, most of its a bunch of obsolete real-mode rountines, and you can never count on them working anyway. Nobody wants to spend time patching around BIOS related bugs in their software; its easier to write your own routines than try to deal with several hundred different implementations in BIOS, some of them almost certain to be incorrect and buggy. IMO a minimalist BIOS would be best: just find the hardware and inititialize and test it.
TedC
http://lwn.net/1998/1203/a/rms-qpl.html
Pure OO programmers would find this unacceptable, but since I tend to view C++ as a better C, the idea appeals to me. I can happily get by with just classes (for better interfaces between parts of a system), inline functions (pre-processor macros are evil!), and stronger type checking.
TedC
I don't want to start up yet license flame war, but even RMS has admitted that the QPL is an acceptable free software license. He didn't sound too happy about it, but he did make that admission.
TedC
I've been using COL since version 1.1 (with brief detours to RH, SuSE, and Linux-Mandrake), and I like it a lot. One of the reasons I use it is that I provide Linux tech support to a few friends. Its easier for them to use than some other distros, and its easier for me to troubleshoot problems if I'm running the same distro.
The other reason is that Caldera tends to hold back on stuff until its stable. For example, RH 6.1 uses a RH-patched 2.2.12 kernel, and Linux-Mandrake 6.1 uses a pre-patched 2.2.13 kernel, while Caldera held back and used 2.2.10, which was the last stable kernel in the so-called stable tree until 2.2.13 was released a few days ago.
TedC
I was under the impression that the vtable was used for virtual functions, and didn't have anyting to do with classes. Is this related to the C++ inheritance mechanism, and would this still be an issue if new classes were derived using composition instead of inheritance?
TedC
I can't think of a good reason to use C for anything new, now that there is an ISO standard for C++, but sometimes I do it anyway. :-|
TedC
Back in the early 90's, there was almost non-stop talk about how fragmentation was going to kill UNIX. ZD pronounced UNIX dead at least a dozen times. But when UNIX vendors began to cooperate, all of a sudden they dropped it. POSIX wasn't interesting news, so they moved on to something else. UNIX still isn't dead, and MS is still trying to produce an OS capable of competing with it.
A code fork will never kill Linux; in the end, it can only improve it.
TedC
While one can use C for large projects, using even a very restricted subset of C++ is probably a better solution. For example, if the only C++ feature you use is classes, you can design a much cleaner interface between different parts of a large software system.
A lot of people take the "all or nothing" approach to C++, but it wasn't designed to be used that way. Use what you need, and forget about the rest.
TedC