One cannot compare GCC and Emacs to KOffice and say that it's all bloated software.
GCC and Emacs do so much because they are literally decades old! When they first were developed, they were small, useful tools. Noone sat down and said, "Let's write a compiler to work on fifty million platforms." It just grew to be that way since it was founded on a great architecture (Yes, besides being an asshole, RMS is also a great programmer).
There's a reason XEmacs and GNU Emacs split. Lot's of Emacs folks didn't want a more bloated Emacs.
Mozilla is a special case. The reason it is so bloated is simply because of the nature of what it's trying to do. HTML is so obsfucated that it takes an aweful lot to handle it well. Remember too that Mozilla grew out of Netscape which is a pretty well established code base.
I'm all for developing good architectures, but goals have to be realistic or software just fails.
It's about accountability. When the government acquires COTS software, the provider has to sign a nice little thing saying if this software contains a virus or backdoor, we're gonna storm your corporate offices and arrest you.
Obviously, Free Software presents a problem because there is no one to be accountable for it.
I wonder if this is for the Virginia Class of mini-subs. These things are just so freaking cool. I'd give my right leg to have one of these things to ride around the Jersey shore in:)
I actually have had to deal with this an the GPL really isn't your biggest concern, but first, let me address that.
The GPL is a set of licensing terms between the author and whomever he distributes the code to. If you are working directly with the Navy (unlikely) then writing and consuming the GPL code would pose no problem since your not distributing to anyone.
If you are working for a contractor, then it is a bit more hairy. You can still write the code GPL and distribute it to the Navy under the GPL. This of course gives the Navy whatever rights to the code so that they could redistribute it if they choose. It does not allow some guy in Florida to obtain secret info though. You would have to first give him a binary for him to have grounds to ask for the source and of course, classified source code produces classified binaries so this isn't an issue.
The real issue is QA. There are all sorts of processes (I know at least for Surface Systems) covering COTS verses in house software. Now, I spent a great deal of time working things out with QA and this is what we came up with when I first asked to use an OS library in a tactical program:
First, I had to vouch for the code. That meant I literally had to go through it line by line and make sure there were no possible backdoors in it. Also, if I modified more than a certain percentage of the library, then I was responsible for bringing that library up to in-house standards (which I'm sure you know is a real pain in the ass).
Don't worry about the licensing terms, they aren't going to be a sticking point likely. QA is what is going to kill you... (and it will only get worse if your program carries a higher classification).
The Free Software community is more than capable of delivering an office suite. 4-6 individuals in not a bad team, but they should be focusing on a specific component instead of trying to do it all at once.
Abiword is an excellent word processor and Gnumeric is a great spreadsheet program. Gnome's figured it out. No one wants to work on a large, bloated project for free. Break it up into littl projects and you'll get a couple 4-6 individual teams.
Of course, the article is/.'d already so I am only guessing...
I'd be interested in hearing your reasoning behind this. I believe that heap compaction helps especially in cases of long running programs that do infrequent allocation but have long-lived data (the common case for long-running programs).
In practice, that data is usually either large quanities of initialization data though. Or, it's a bunch of small allocations that are likely continuous.
Most long running programs are daemons, and essentially start up, initialize data, and then enter a repeative state loop. There isn't really that much fragmentation in the initial data so compaction doesn't really buy much.
Compaction is only useful when a program is generally allocating small bits of memory where most - but not all of it - is freed after being used. Most programmers go to great lengths to avoid frequent allocations so this is why this behavior does occur frequently.
Now, in a language like Java where memory is allocated far more often then it should, you run in to a circumstance where compaction is required.
Much more important is correctness, and as we see time and time again, even "good programmers" make mistakes that can sometimes be devastating.
I don't think you see my point. Most objects simply belong on the stack. That doesn't happen in Java. In fact, that is exactly why there is a stack, to provide automatic memory management.
As for a tree example, that's what containers are for. One can build a tree in C++ without ever calling an allocation function.
It is possible to prevent new from being called on an object, and it is also possible to disable the global new. A programmer could conceivably disable these things and thereby never have to worry about memory leaks. Allocating dynamic memory is not always the answer and is much, much slower than just using the heap.
My point is not just that C++ is good for good programmers, but a good C++ architecture can prevent bad programmers from doing bad things. The only difference between C++ and other high level languages is that it gives you the option to do dangerous things. It's really a matter of programmers not knowing their limitations.
Heap compaction is not nearly that important unless there is a great deal of allocation. For most long running programs, allocation is rarely continuous. Usually, it is periodic, in which, heap compaction does very little.
And working for the government, I can say that there are many folks who could be making a lot more working in the commerical sector. Fortunately, these individuals absolutely love their job. The emphasis on quality and reliability is very attractive for many hard core programmers.
Money doesn't always solve problems and it obviously wouldn't solve the problem here.
What would you do if everyone at your work made the same amount (even if it was high) and while you worked 50 hour weeks to get the job done, everyone else only worked a 30 hour week? Would you work a 30 hour week too? Would you look for another job? Yet, we ask good teachers to go the extra mile without any kind of reward. Worst of all, we ask them to do this while also not punishing teachers who slack off.
It's not about the money. It's about the grave abuse by the teachers union. Have you ever been in a district where a teachers strike happened? Happens all the time out here. Do you know that teachers in New Jersey have to receive a 40 minute lunch no matter what? When I was in High School, we had a few fire alarms go off at just the wrong time and even though most of the school day was completed, since forty minutes of time was lost during the time when teachers had lunch, the day had to be made up in the summer.
The best part was that teachers could not be asked to work past like the 21st of June under any circumstance one year, the school had to resort to Saturday classes. It's absolutely insane. I am not even mentioning the incredibly political glout of the teachers organizations. In jersey, it is an absolute requirement that the teachers union supports a candidate in order for him to be elected. There is absolutely no integrity.
This may sound crass but guess what? its the real world. People who stay an extra 2 years and get a masters will get paid more then me, and phd's will be paid better yet.
The brighest tech minds are those who enjoy technology. Many folks are good at technology, but to teach someone, one has to be more than just good at it. A teacher should be passionate about what they are teaching. It's one thing to simply show a student how to do something, but so much more meaningful to inspire them.
To be honest, many good programmers would probably teachers as such a profession would allow for a large amount of time to pursue side projects (such as Free Software). The summer break makes it even better. The lack of money isn't really an issue if you love what your doing.
The simply fact of the matter though is that no self respecting tech person is going to teach somewhere when a) they are not rewarded for doing their job well b) they are forced to adhere to an absurd curriculm. To work in an environment where one is not respected for doing a good job is incredibly demeaning. It doesn't matter if you only make 25.5K over another making 25K. It just matters that your being recognized for doing a good job.
While you may have suffered through school, many folks - including me - absolutely loved it. You probably make a great employee granted you made it through the program, but you likely lack the passion to be an inspiring teacher.
One positive is that it provides hard evidence with which administrators may weed out the "bad teachers". And there are bad teachers, no doubt about it.
You are obviously basing this statement on political rhetoric and not on experience. Inquire at your local high school on the difficulty to remove a teacher who has tenure based on poor performance.
To say that teachers as a whole take the brunt of failure in standardized testing may be true, but individual teachers do not suffer if their students perform worse than the rest of the school. Such programs have been proposed but the teachers union has kept them from happening to the best of my knowledge.
I have been told that it would literally take a year worth of paper work to remove a teacher with tenure. It is tedious and dangerous as the adminstration tends to get hammered by the teachers union.
I don't think standardizes tests really fit into this argument as they do not effect individual teachers.
The worst thing that can ever happen is to finish a project early and under budget. I worked on a small four man team that finished early and under budget (and it actually worked). Worst thing we could have done! Team blows up to a 12+ (all entry level), best guy gets moved off, more is expected, and expected in the same amount of time, and with a smaller budget then normal since we did so well the first time.
If your project isn't having a crunch time, then it's only a matter of time before it has one. In reality, management's job is to push programmers as far as humanly possible. If they aren't failing, then they aren't being pushed hard enough, and the company is losing money. At least, this appears to be managements mentality, as sad as that may seem...
If only they got paid more, maybe there would be more quality applicants across all subjects.
It amazes me that people actually believe this. It's sort of like all those folks who believed that one could throw a bunch of VC at a bad idea and all the sudden get a great product (And now we observe the fallout).
The problem with education is not that teachers do not get paid enough, but that the entire education system is geared to mediocrity. Students are not encouraged to excel, but encourage to simply complete the assigned work.
Likewise, teachers are held down tightly by the government and their own union so that they simply could not teach students well.
To speak strictly of the relation between money and quality, the best means to increase the quality of teachers would be to eliminate the teachers union and allow teachers to be paid according to merit. Why should a teacher strive to do their job well when they get paid the same either way? Teaching is one of the few professions were there is absolutely no accountability.
Even if schools were de-unionized, that would not solve the problem. The students who could truely excel are constantly discouraged, the students who do not belong in school are forced to remain in it, and then the rest of the students simply learn to perform the kind of mondane work that will be a part of the rest of their lives.
If we really care about educating youth, then lets actually educate them. I, for one, would absolutely engage in the equivalent of a start-up school. Unfortunately, there is no way to do such a thing since the name of a school more important than the school itself so the students who attended would have no chance of getting into a decent college.
I almost participated in that some years ago but didn't because they only taught Scheme whereas I was coding pretty hard core at the time in C. Scheme didn't really seem like a useful language to me and I couldn't justify spending so much time (especially in a course tailored to non-programmers) to learn a language that a) I could learn on my own b) didn't seem really useful.
In retrospect, I wish I would have taken as I didn't understand at the time how important connections are but perhaps if you have any say in the program you may consider adjusting the program to suit the desires of those who truely want to learn. Understand that my choice was spending a few weeks writing scheme or spending a few weeks writing C. Being the geek that I am, I choose C.
I do know someone who took the course and they still couldn't code their way out of a paper bag so I definitely felt vindicated.
Please. Interfaces couldnt be any simpler or easier to use. Lack of MI might be incredible painful to the.01% of people who need it. The other 100% dont care because interfaces provide what you need. Is it perfect? No but its hardly what you make it out to be.
Interfaces are a poor excuse for MI and are misused in Java. The fact that interfaces can't have a default implementation (or that certain aspects of an interface can't be option) is why interfaces stink. GCC has an extension to C++ called signatures which are much more useful than Java interfaces especially since they can be applied to a class post-compilation.
Java doesn't pass by reference. It passes reference by value. Your mistake is a common one.
If Java does indeed pass value by reference, then surely I can pass reference by reference then perhaps? Or maybe dereference the reference and pass by value directly?
No, you can't. Java doesn't give you the option. It does not have a 'robust' passing mechanism. Encouraging objects to be passed around by reference (making them writable) is very bad programming practice. Strict use of const (or final in Java) makes programming much safer. There is no reason why drawString should be able to modify the String object that is passed in.
Java does have input from people other than the engineers at Sun.
Is there a non-partial committee that oversees the development of the Java language? or do a bunch of suits at Sun determine what is in the language?
They may be open to suggestions, but I would equate that more to stealing ideas.
JVM bytecode *is* robust enough to be useful for other languages.
So then it supports MI? Or referencing objects? Or passing objects by value? It supports operating overloading? Come on now. JVM bytecode is only useful to languages which only contain identical functionality to Java.
The thing I wonder about though is why does that even make a difference?
Because then Java could be used (practically) with other languages. The C-to-Java wrappers are a joke. If a language cannot be mixed with other languages, then it is useless in the real world and useless for most production programs where legacy libraries are a reality.
Is it really true that malloc and free are not used in the kernel? I thought there was like kmalloc and kfree that acted just like those, and I would assume they are implemented in a similar way. I don't know, I've never actually worked on the linux kernel, but when I did my own kernel in school I had stuff like that.
kmalloc/kfree are much like their malloc/free counter parts. kmalloc/kfree return pointers to logical kernel memory. Logical kernel memory is usually directly accessable but not always. It usually corresponds directly to hardware memory (usually differing only by an offset). There are other functions (vmalloc, etc.) that return virtual kernel memory which is more like the memory returned by malloc. Virtual memory cannot usually be accessed directly.
The memory model in the kernel is much different in that it allows both fragmented allocation and page allocation. O'Reilly has a great book Linux Device Drivers that is actually under the GNU FDL and is available online at O'Reilly's homepage. There is a chapter devoted to kernel memory in it.
Garbage collection doesn't solve "poor programming"; it's a feature that a language offers that makes it easier to write programs. Of course, you can write poor programs in a language with any set of features.
If good programmers weren't penalized by it, then I would full heartily support garbage collection. Languages should not sacrifice in order to support user-error. The fact that it doesn't eliminate error only helps my point. Take the following:
In Java:
{
String a = new String("test");
String b = new String("test2");
a = b; }
In C++:
{
String a = "test";
String b = "test2";
a = b; }
Neither piece of code has a memory leak. Used properly, C++ is just as easy to use as Java. You have to _try_ and leak memory in C++, it doesn't happen automatically. Java prevents this by penalizing good programmers. That's my problem with it.
It is NOT a buffer overflow. Every is happy that your karma whoring because you know what a 'buffer overflow' is but your also helping spread this FUD.
The problem in zlib is a double free. It is only, and I repeat, only theoritically possible to exploit this in the same way that it is theoritically possible to exploit any undefined behavior.
Please don't counter with a traceroute exploit being an example of a double free because it wasn't. That was an example of free a garbage random data. There is quite a difference.
At any rate, please think before you post. I cannot believe everyone is making such a fuss over this. It's funny because XP's whole TCP/IP had a remote root hole in it and less noise was made here then is being made now over something that is only theoritically possible to exploit and also not yet proven to be reproducable.
Right now, this 'security issue' is entirely theoritical.
That being said, Java is a more complete language for handling networking, i/o, threading, enterprise components, directory services, database access, etc. than any scripting language I know.
My biggest problem with Java is how horribly ugly it is. Interfaces are a joke and the lack of MI is incredibly painful. It's collections are utterly uselessly and adapter classes are almost as painful as functors in C++ although the lack of any binder functions make them much less useful.
Java is, at best, an academic language. Very little useful things can be done with it other then a 20 line hello world program. It has some good ideas (Inner Classes) but they are poorly implemented and the memory model absolutely sucks.
Passing by reference encourages sloppy programming as the use of final is not encouraged as it should. A well written C++ framework is a thousand times more robust then Java. Well written C++ classes can literally be safe even with monkeys smacking the keyboard in Emacs.
Java would be better if 1) it was an open language and allowed input from people other than Sun engineers 2) it was organized by a company looking to create a good platform and not by a company looking to exploit every buzz phrase in the world 3) the JVM bytecode was robust enough to be useful for other languages (and not bastardized versions of languages such as Mangled C++).
Actually, there are several real-time garbage collectors around. It's not at all impossible to have a real-time one with low overhead (lower than certain mallocs), and still win in terms of ease of use, correctness, and heap compaction. Don't forget that malloc implementations also need to do things like coalescing that can cause an alloc or free to "sleep" (that is, take a while) too!
malloc/free are _not_ used in the kernel. The kernel doesn't really have VM in the traditional sense. Garbage collection works when you have an underlying VM because unused memory is swapped to disk and therefore has no real performance penality. So, if a GC holds on to 50MB of unused memory, so what? It will get swapped to disk.
No so in the kernel though. It is vitally important that memory be free'd as soon as it can so that more RAM is available to applications. Now, having a VM in the kernel would not solve the problem because there would be a performance nightmare if kernel code had to be swapped in from disk.
I'm suggesting that we use high level languages where possible
The only area I disagree with you is on whether it is possible to use a high level language in the kernel. I do not believe it is. Now, with a microkernel, things are a bit different because there is a much more vague line between what is and isn't the kernel so there may be room for arguement there, but for the standard monolithic kernel, high level code just has to much overhead to be effective.
But either way, I don't think any "tradeoff" that sacrifices correctness for speed is really a "tradeoff", it's just a mistake.
What is truely needed is a mechanism to perform allocation/deallocation during compile time instead of run time. A mechanism to determine when a pointer is no longer valid and then inserts a deallocation within the code at that point. Solving poor programming during run-time is just a bad idea.
Why do you think this is hard? There are plenty of user-level single-threaded garbage collectors, even real-time ones. I don't think it would be hard to do, and would even have some benefits, like heap compaction, that are important for long-running programs like an OS kernel.
Step back and think a moment about what you just said. Garbage collection makes no guarentees about when GC will actually occurs. That means every time kalloc was called, there would be the potential for it to sleep while the GC searched the reference tree. This is absolutely no good for the kernel. Not to mention the fact that there are three distinct types of memory within the kernel so three GC would be required.
Garbage collection is not the end all solution to memory mangagement _especially_ when you have to make guarentees about performance. Reference counting is being slowly implemented within the kernel and this is likely to be the best mechanism to solve memory issues.
Not to mention the fact that most kernel data structures simply cannot afford the overhead required by a garbage collector (since kernel memory constantly occupies RAM and therefore eats away at the available amount of system memory).
Garbage collection works for large programs that don't really have speed considerations. It does not work in every situation though.
OK, so perhaps if libz is necessary in the kernel, then we have no choice but to write it in C. I am kind of surprised that libz is linked in there, actually. How does it call malloc()/free() if it's in the kernel?
The zlib_inflate and zlib_deflate routines do not call malloc()/free(). Instead, they take in memory from the caller that is usually allocated with valloc or kalloc. It's important to note that the zlib is not linked against the kernel, but a portion of zlib exists within the kernel as a derivative.
Compression/Decompression is inherently a costly operation. It fortunately though is not one that requires a great deal of allocation/deallocation. Therefore, there is no justification for adding the overhead of a complex memory tracking system.
Besides, as many posters pointed out, there is a mechanism in LIBC to allow memory to be tracked dynamically. The performance trade off is just not exceptable though. So called high level languages are not the solution to every problem.
All computer programs are essentially complete solutions to a problem. The difference between math and computer science is that computer science involves not only math, but logical deductions from math.
Computer science is the only discipline that actually teachs how to think. Most other disciplines just spoon feed meaningless garbage down childrens throats.
Slashdot Mirror
One cannot compare GCC and Emacs to KOffice and say that it's all bloated software.
GCC and Emacs do so much because they are literally decades old! When they first were developed, they were small, useful tools. Noone sat down and said, "Let's write a compiler to work on fifty million platforms." It just grew to be that way since it was founded on a great architecture (Yes, besides being an asshole, RMS is also a great programmer).
There's a reason XEmacs and GNU Emacs split. Lot's of Emacs folks didn't want a more bloated Emacs.
Mozilla is a special case. The reason it is so bloated is simply because of the nature of what it's trying to do. HTML is so obsfucated that it takes an aweful lot to handle it well. Remember too that Mozilla grew out of Netscape which is a pretty well established code base.
I'm all for developing good architectures, but goals have to be realistic or software just fails.
It's about accountability. When the government acquires COTS software, the provider has to sign a nice little thing saying if this software contains a virus or backdoor, we're gonna storm your corporate offices and arrest you.
Obviously, Free Software presents a problem because there is no one to be accountable for it.
Ha, the mini-subs are for Navy Seal deployment.
:)
I think I have a better chance of trading the Navy my right leg then of becoming a Navy Seal
No, there's a mini-sub (ASDS) in the Virginia class. It's a Seal Transport vehicle that's only about 65ft long.
:)
Need a pretty big slip, but it would be worth it
I wonder if this is for the Virginia Class of mini-subs. These things are just so freaking cool. I'd give my right leg to have one of these things to ride around the Jersey shore in :)
That's why ICBMs carry such devistating payloads, if it misses the target, ah, oh well, the whole country's blown to bits anyway :)
I actually have had to deal with this an the GPL really isn't your biggest concern, but first, let me address that.
The GPL is a set of licensing terms between the author and whomever he distributes the code to. If you are working directly with the Navy (unlikely) then writing and consuming the GPL code would pose no problem since your not distributing to anyone.
If you are working for a contractor, then it is a bit more hairy. You can still write the code GPL and distribute it to the Navy under the GPL. This of course gives the Navy whatever rights to the code so that they could redistribute it if they choose. It does not allow some guy in Florida to obtain secret info though. You would have to first give him a binary for him to have grounds to ask for the source and of course, classified source code produces classified binaries so this isn't an issue.
The real issue is QA. There are all sorts of processes (I know at least for Surface Systems) covering COTS verses in house software. Now, I spent a great deal of time working things out with QA and this is what we came up with when I first asked to use an OS library in a tactical program:
First, I had to vouch for the code. That meant I literally had to go through it line by line and make sure there were no possible backdoors in it. Also, if I modified more than a certain percentage of the library, then I was responsible for bringing that library up to in-house standards (which I'm sure you know is a real pain in the ass).
Don't worry about the licensing terms, they aren't going to be a sticking point likely. QA is what is going to kill you... (and it will only get worse if your program carries a higher classification).
The Free Software community is more than capable of delivering an office suite. 4-6 individuals in not a bad team, but they should be focusing on a specific component instead of trying to do it all at once.
/.'d already so I am only guessing...
Abiword is an excellent word processor and Gnumeric is a great spreadsheet program. Gnome's figured it out. No one wants to work on a large, bloated project for free. Break it up into littl projects and you'll get a couple 4-6 individual teams.
Of course, the article is
I'd be interested in hearing your reasoning behind this. I believe that heap compaction helps especially in cases of long running programs that do infrequent allocation but have long-lived data (the common case for long-running programs).
In practice, that data is usually either large quanities of initialization data though. Or, it's a bunch of small allocations that are likely continuous.
Most long running programs are daemons, and essentially start up, initialize data, and then enter a repeative state loop. There isn't really that much fragmentation in the initial data so compaction doesn't really buy much.
Compaction is only useful when a program is generally allocating small bits of memory where most - but not all of it - is freed after being used. Most programmers go to great lengths to avoid frequent allocations so this is why this behavior does occur frequently.
Now, in a language like Java where memory is allocated far more often then it should, you run in to a circumstance where compaction is required.
Much more important is correctness, and as we see time and time again, even "good programmers" make mistakes that can sometimes be devastating.
I don't think you see my point. Most objects simply belong on the stack. That doesn't happen in Java. In fact, that is exactly why there is a stack, to provide automatic memory management.
As for a tree example, that's what containers are for. One can build a tree in C++ without ever calling an allocation function.
It is possible to prevent new from being called on an object, and it is also possible to disable the global new. A programmer could conceivably disable these things and thereby never have to worry about memory leaks. Allocating dynamic memory is not always the answer and is much, much slower than just using the heap.
My point is not just that C++ is good for good programmers, but a good C++ architecture can prevent bad programmers from doing bad things. The only difference between C++ and other high level languages is that it gives you the option to do dangerous things. It's really a matter of programmers not knowing their limitations.
Heap compaction is not nearly that important unless there is a great deal of allocation. For most long running programs, allocation is rarely continuous. Usually, it is periodic, in which, heap compaction does very little.
And working for the government, I can say that there are many folks who could be making a lot more working in the commerical sector. Fortunately, these individuals absolutely love their job. The emphasis on quality and reliability is very attractive for many hard core programmers.
Money doesn't always solve problems and it obviously wouldn't solve the problem here.
What would you do if everyone at your work made the same amount (even if it was high) and while you worked 50 hour weeks to get the job done, everyone else only worked a 30 hour week? Would you work a 30 hour week too? Would you look for another job? Yet, we ask good teachers to go the extra mile without any kind of reward. Worst of all, we ask them to do this while also not punishing teachers who slack off.
It's not about the money. It's about the grave abuse by the teachers union. Have you ever been in a district where a teachers strike happened? Happens all the time out here. Do you know that teachers in New Jersey have to receive a 40 minute lunch no matter what? When I was in High School, we had a few fire alarms go off at just the wrong time and even though most of the school day was completed, since forty minutes of time was lost during the time when teachers had lunch, the day had to be made up in the summer.
The best part was that teachers could not be asked to work past like the 21st of June under any circumstance one year, the school had to resort to Saturday classes. It's absolutely insane. I am not even mentioning the incredibly political glout of the teachers organizations. In jersey, it is an absolute requirement that the teachers union supports a candidate in order for him to be elected. There is absolutely no integrity.
This may sound crass but guess what? its the real world. People who stay an extra 2 years and get a masters will get paid more then me, and phd's will be paid better yet.
The brighest tech minds are those who enjoy technology. Many folks are good at technology, but to teach someone, one has to be more than just good at it. A teacher should be passionate about what they are teaching. It's one thing to simply show a student how to do something, but so much more meaningful to inspire them.
To be honest, many good programmers would probably teachers as such a profession would allow for a large amount of time to pursue side projects (such as Free Software). The summer break makes it even better. The lack of money isn't really an issue if you love what your doing.
The simply fact of the matter though is that no self respecting tech person is going to teach somewhere when a) they are not rewarded for doing their job well b) they are forced to adhere to an absurd curriculm. To work in an environment where one is not respected for doing a good job is incredibly demeaning. It doesn't matter if you only make 25.5K over another making 25K. It just matters that your being recognized for doing a good job.
While you may have suffered through school, many folks - including me - absolutely loved it. You probably make a great employee granted you made it through the program, but you likely lack the passion to be an inspiring teacher.
One positive is that it provides hard evidence with which administrators may weed out the "bad teachers". And there are bad teachers, no doubt about it.
You are obviously basing this statement on political rhetoric and not on experience. Inquire at your local high school on the difficulty to remove a teacher who has tenure based on poor performance.
To say that teachers as a whole take the brunt of failure in standardized testing may be true, but individual teachers do not suffer if their students perform worse than the rest of the school. Such programs have been proposed but the teachers union has kept them from happening to the best of my knowledge.
I have been told that it would literally take a year worth of paper work to remove a teacher with tenure. It is tedious and dangerous as the adminstration tends to get hammered by the teachers union.
I don't think standardizes tests really fit into this argument as they do not effect individual teachers.
Ya, right. Such things don't really exist :)
The worst thing that can ever happen is to finish a project early and under budget. I worked on a small four man team that finished early and under budget (and it actually worked). Worst thing we could have done! Team blows up to a 12+ (all entry level), best guy gets moved off, more is expected, and expected in the same amount of time, and with a smaller budget then normal since we did so well the first time.
If your project isn't having a crunch time, then it's only a matter of time before it has one. In reality, management's job is to push programmers as far as humanly possible. If they aren't failing, then they aren't being pushed hard enough, and the company is losing money. At least, this appears to be managements mentality, as sad as that may seem...
If only they got paid more, maybe there would be more quality applicants across all subjects.
It amazes me that people actually believe this. It's sort of like all those folks who believed that one could throw a bunch of VC at a bad idea and all the sudden get a great product (And now we observe the fallout).
The problem with education is not that teachers do not get paid enough, but that the entire education system is geared to mediocrity. Students are not encouraged to excel, but encourage to simply complete the assigned work.
Likewise, teachers are held down tightly by the government and their own union so that they simply could not teach students well.
To speak strictly of the relation between money and quality, the best means to increase the quality of teachers would be to eliminate the teachers union and allow teachers to be paid according to merit. Why should a teacher strive to do their job well when they get paid the same either way? Teaching is one of the few professions were there is absolutely no accountability.
Even if schools were de-unionized, that would not solve the problem. The students who could truely excel are constantly discouraged, the students who do not belong in school are forced to remain in it, and then the rest of the students simply learn to perform the kind of mondane work that will be a part of the rest of their lives.
If we really care about educating youth, then lets actually educate them. I, for one, would absolutely engage in the equivalent of a start-up school. Unfortunately, there is no way to do such a thing since the name of a school more important than the school itself so the students who attended would have no chance of getting into a decent college.
I almost participated in that some years ago but didn't because they only taught Scheme whereas I was coding pretty hard core at the time in C. Scheme didn't really seem like a useful language to me and I couldn't justify spending so much time (especially in a course tailored to non-programmers) to learn a language that a) I could learn on my own b) didn't seem really useful.
In retrospect, I wish I would have taken as I didn't understand at the time how important connections are but perhaps if you have any say in the program you may consider adjusting the program to suit the desires of those who truely want to learn. Understand that my choice was spending a few weeks writing scheme or spending a few weeks writing C. Being the geek that I am, I choose C.
I do know someone who took the course and they still couldn't code their way out of a paper bag so I definitely felt vindicated.
Please. Interfaces couldnt be any simpler or easier to use. Lack of MI might be incredible painful to the .01% of people who need it. The other 100% dont care because interfaces provide what you need. Is it perfect? No but its hardly what you make it out to be.
Interfaces are a poor excuse for MI and are misused in Java. The fact that interfaces can't have a default implementation (or that certain aspects of an interface can't be option) is why interfaces stink. GCC has an extension to C++ called signatures which are much more useful than Java interfaces especially since they can be applied to a class post-compilation.
Java doesn't pass by reference. It passes reference by value. Your mistake is a common one.
If Java does indeed pass value by reference, then surely I can pass reference by reference then perhaps? Or maybe dereference the reference and pass by value directly?
No, you can't. Java doesn't give you the option. It does not have a 'robust' passing mechanism. Encouraging objects to be passed around by reference (making them writable) is very bad programming practice. Strict use of const (or final in Java) makes programming much safer. There is no reason why drawString should be able to modify the String object that is passed in.
Java does have input from people other than the engineers at Sun.
Is there a non-partial committee that oversees the development of the Java language? or do a bunch of suits at Sun determine what is in the language?
They may be open to suggestions, but I would equate that more to stealing ideas.
JVM bytecode *is* robust enough to be useful for other languages.
So then it supports MI? Or referencing objects? Or passing objects by value? It supports operating overloading? Come on now. JVM bytecode is only useful to languages which only contain identical functionality to Java.
The thing I wonder about though is why does that even make a difference?
Because then Java could be used (practically) with other languages. The C-to-Java wrappers are a joke. If a language cannot be mixed with other languages, then it is useless in the real world and useless for most production programs where legacy libraries are a reality.
Is it really true that malloc and free are not used in the kernel? I thought there was like kmalloc and kfree that acted just like those, and I would assume they are implemented in a similar way. I don't know, I've never actually worked on the linux kernel, but when I did my own kernel in school I had stuff like that.
kmalloc/kfree are much like their malloc/free counter parts. kmalloc/kfree return pointers to logical kernel memory. Logical kernel memory is usually directly accessable but not always. It usually corresponds directly to hardware memory (usually differing only by an offset). There are other functions (vmalloc, etc.) that return virtual kernel memory which is more like the memory returned by malloc. Virtual memory cannot usually be accessed directly.
The memory model in the kernel is much different in that it allows both fragmented allocation and page allocation. O'Reilly has a great book Linux Device Drivers that is actually under the GNU FDL and is available online at O'Reilly's homepage. There is a chapter devoted to kernel memory in it.
Garbage collection doesn't solve "poor programming"; it's a feature that a language offers that makes it easier to write programs. Of course, you can write poor programs in a language with any set of features.
If good programmers weren't penalized by it, then I would full heartily support garbage collection. Languages should not sacrifice in order to support user-error. The fact that it doesn't eliminate error only helps my point. Take the following:
In Java:
{
String a = new String("test");
String b = new String("test2");
a = b;
}
In C++:
{
String a = "test";
String b = "test2";
a = b;
}
Neither piece of code has a memory leak. Used properly, C++ is just as easy to use as Java. You have to _try_ and leak memory in C++, it doesn't happen automatically. Java prevents this by penalizing good programmers. That's my problem with it.
It is NOT a buffer overflow. Every is happy that your karma whoring because you know what a 'buffer overflow' is but your also helping spread this FUD.
The problem in zlib is a double free. It is only, and I repeat, only theoritically possible to exploit this in the same way that it is theoritically possible to exploit any undefined behavior.
Please don't counter with a traceroute exploit being an example of a double free because it wasn't. That was an example of free a garbage random data. There is quite a difference.
At any rate, please think before you post. I cannot believe everyone is making such a fuss over this. It's funny because XP's whole TCP/IP had a remote root hole in it and less noise was made here then is being made now over something that is only theoritically possible to exploit and also not yet proven to be reproducable.
Right now, this 'security issue' is entirely theoritical.
That being said, Java is a more complete language for handling networking, i/o, threading, enterprise components, directory services, database access, etc. than any scripting language I know.
My biggest problem with Java is how horribly ugly it is. Interfaces are a joke and the lack of MI is incredibly painful. It's collections are utterly uselessly and adapter classes are almost as painful as functors in C++ although the lack of any binder functions make them much less useful.
Java is, at best, an academic language. Very little useful things can be done with it other then a 20 line hello world program. It has some good ideas (Inner Classes) but they are poorly implemented and the memory model absolutely sucks.
Passing by reference encourages sloppy programming as the use of final is not encouraged as it should. A well written C++ framework is a thousand times more robust then Java. Well written C++ classes can literally be safe even with monkeys smacking the keyboard in Emacs.
Java would be better if 1) it was an open language and allowed input from people other than Sun engineers 2) it was organized by a company looking to create a good platform and not by a company looking to exploit every buzz phrase in the world 3) the JVM bytecode was robust enough to be useful for other languages (and not bastardized versions of languages such as Mangled C++).
Actually, there are several real-time garbage collectors around. It's not at all impossible to have a real-time one with low overhead (lower than certain mallocs), and still win in terms of ease of use, correctness, and heap compaction. Don't forget that malloc implementations also need to do things like coalescing that can cause an alloc or free to "sleep" (that is, take a while) too!
malloc/free are _not_ used in the kernel. The kernel doesn't really have VM in the traditional sense. Garbage collection works when you have an underlying VM because unused memory is swapped to disk and therefore has no real performance penality. So, if a GC holds on to 50MB of unused memory, so what? It will get swapped to disk.
No so in the kernel though. It is vitally important that memory be free'd as soon as it can so that more RAM is available to applications. Now, having a VM in the kernel would not solve the problem because there would be a performance nightmare if kernel code had to be swapped in from disk.
I'm suggesting that we use high level languages where possible
The only area I disagree with you is on whether it is possible to use a high level language in the kernel. I do not believe it is. Now, with a microkernel, things are a bit different because there is a much more vague line between what is and isn't the kernel so there may be room for arguement there, but for the standard monolithic kernel, high level code just has to much overhead to be effective.
But either way, I don't think any "tradeoff" that sacrifices correctness for speed is really a "tradeoff", it's just a mistake.
What is truely needed is a mechanism to perform allocation/deallocation during compile time instead of run time. A mechanism to determine when a pointer is no longer valid and then inserts a deallocation within the code at that point. Solving poor programming during run-time is just a bad idea.
Why do you think this is hard? There are plenty of user-level single-threaded garbage collectors, even real-time ones. I don't think it would be hard to do, and would even have some benefits, like heap compaction, that are important for long-running programs like an OS kernel.
Step back and think a moment about what you just said. Garbage collection makes no guarentees about when GC will actually occurs. That means every time kalloc was called, there would be the potential for it to sleep while the GC searched the reference tree. This is absolutely no good for the kernel. Not to mention the fact that there are three distinct types of memory within the kernel so three GC would be required.
Garbage collection is not the end all solution to memory mangagement _especially_ when you have to make guarentees about performance. Reference counting is being slowly implemented within the kernel and this is likely to be the best mechanism to solve memory issues.
Not to mention the fact that most kernel data structures simply cannot afford the overhead required by a garbage collector (since kernel memory constantly occupies RAM and therefore eats away at the available amount of system memory).
Garbage collection works for large programs that don't really have speed considerations. It does not work in every situation though.
OK, so perhaps if libz is necessary in the kernel, then we have no choice but to write it in C. I am kind of surprised that libz is linked in there, actually. How does it call malloc()/free() if it's in the kernel?
The zlib_inflate and zlib_deflate routines do not call malloc()/free(). Instead, they take in memory from the caller that is usually allocated with valloc or kalloc. It's important to note that the zlib is not linked against the kernel, but a portion of zlib exists within the kernel as a derivative.
Compression/Decompression is inherently a costly operation. It fortunately though is not one that requires a great deal of allocation/deallocation. Therefore, there is no justification for adding the overhead of a complex memory tracking system.
Besides, as many posters pointed out, there is a mechanism in LIBC to allow memory to be tracked dynamically. The performance trade off is just not exceptable though. So called high level languages are not the solution to every problem.
All computer programs are essentially complete solutions to a problem. The difference between math and computer science is that computer science involves not only math, but logical deductions from math.
Computer science is the only discipline that actually teachs how to think. Most other disciplines just spoon feed meaningless garbage down childrens throats.
There's also no reason that the six people who live in a cave and prefer Netscape 4.76 have to switch either.
:)
Yeah, you'd think they would upgrade to Netscape 4.78 like the rest of us
Ok, explain to me how one is going to implement a Garbage Collector in the kernel?
If libz was written in anything other than C, it could not be used in nearly as many applications as it is currently.