1) circular references aren't terribly common to begin with and can be avoided.
2) this is true, but I assume that if one requires GC than there will be a significant amount of garbage. It's simply, relatively painless, and is used quite frequently in C++. Therefore, for a production environment, using reference counting may not be as efficent, but it is more likely to be effective as it is maintainable.
Unless there is a readily available GC for C++ that works really well and is Free as in speech and beer? If there is, then use it, but I don't know of one.
Of course, one would imagine that one would use factories instead and make things a whole lot cleaner. That is the basic gist of it. It's not about _never_ using new, but making sure that only a single class (the parameterized RCPointer class or factory classes) ever actually calls it.
With factories, it would be as simply as this:
typedef RCFactory VehicleFactory;
VehicleFactory a = VehicleFactory::create();
I have a bit of a problem with your assertion that operating overloading isn't useful.
In fact, if you take a look at java, they go to great lengths to implement comparision interfaces when overloading comparision functions makes much more sense.
Streaming is a great use of operator overloading too. Most importantly, implementing primative replacements absolutely requires operating overloading. Take for instance the lowly bit mask. Many circumstances requires a generic bit mask that will handle more than 32 flags. This is a perfect place to use operator overloading because all your doing is designing a class to take the place of a primative and behave in the same way as a primative.
Also, complex math using vectors, matrices, and complex numbers most certainly require the use of operating overloading to be intuitive. You cannot tell me that using the + operator on two matrices to obtain their summation is not more intuitive than having some silly method especially since it would have to be a static method anything.
Matrix a, b, c;
a = b + c;
verses:
a = Matrix.add(b, c);
Now, explain to someone with their math degree (not CS degree) why they are using infix operators for primative math but prefix operators for math with complex types and they'll look at you like your crazy.
Infix is more intuitive. That's why people use C/C++/Java and not LISP (not that LISP's a bad language...)
From a design standpoint, sometimes MI is required. Sometimes an object does need to be two separate things. I am not a Java expert, but I assume a member of an interface cannot be overridden (if it could, than interfaces are just classes that support MI). So, what happens when you have an object that needs to be treated as two entirely separate objects in different places in your code?
Lets say for example you have a class representing humans, well, you may want to have humans be both a Mammal and an Earthling. Let's assume that there is no interconnection between mammals and earthlings (I couldn't think of a better generic example). You may want to treat a human object as an earthling in one spot of the code, and as a mammal in another spot of the code.
Assume that each of these have virtual functions that are overridden by the human class.
If you use interfaces to solve this problem, then that may work, but it's fundamentally wrong because one should treat an interface as a generic object that implements these functions verses an object that actually is this thing.
MI has pitfalls and can be used very incorrectly, but that doesn't mean that it isn't needed in a good number of circumstances.
I think the real problem with C++ is that it doesn't have interfaces (or signatures as G++ has done). That makes it necessary to have a great number of abstract base classes that really should just be interfaces.
To me, the obvious solution seems to write the backend stuff in C++ and the GUI stuff in Java. Java has a great GUI library and while it can't provide all the requirements, C++ can satisify the rest of the requirements. I imagine you are not looking to use MI in a GUI... That would be quite strange... I also imagine you are not looking to use operator overloading in a GUI either (although sadly enough I've seen it done).
So, here's my list:)
intuitive and easy to use IDE Does such a thing exist??? Every language has an IDE. Visual Studios, JBuilder, Emacs, KDevelopers, etc.
simplified GUI design and event handling Well, this really depends on the operating system. Java's the good place to go here. If that can't be done, GTK and Qt are good libraries and they use the standard X style callback mechanism which is so much nicer than message based systems. What your really looking though is for a WYSIWYG GUI designer so I'd recommend Glade or whatever comes with the IDE you go with.
advanced error handling Such a buzz word... Java and C++ both use exceptions. Good error handling has more to do with a projects design though and not really the particular language...
advanced object oriented design including multiple inheritance, abstract classes, and garbage collection Lets get our terminology right:) GC is not an OO feature. GC is a generic programming concept and it is by no way the only way to avoid memory leaks. In C++, reference counting is much preferred over GC and it's probably the better choice since C++ programs tend to not use enough memory for GC to really be effective. Check out boost for some good reference counting classes.
IMHO, MI is necessary for advanced projects but Java interfaces _almost_ make MI unnecessary. You may do well to evaluate whether you truly need MI. What really matters, is how good your development team is.
full support for operator and function overloading This really should be in Java if you ask me but it isn't. You really don't need it. You could use interfaces instead. Of course, C++ support for operator overloading is great. Again though, you should really evaluate if you truly need such an advanced feature. If you just going to use it to concat strings then you don't need it.
and portable (at compile-time) across various platforms Java or GCC. C++ is portable as long as it's GCC on both platforms:) Don't expect C++ to be very portable across different compilers though...
I think I'd have to agree with the general sentiment that you really need to evaluate your requirements because they are extremely unjustified and appear to be either (1) a bad manager, (2) pressure from employees to obtain "resume builder" skills, or (3) a very complicated project which you are not providing very much required information for:)
No language can satisify all your requirements perfectly. C++ comes closest. A combiniation of C++ and Java would do the job nicely.
That said, C++ does not have any built-in garbage collection which is in my opinion a shame. Still, you can plug in garbage collection if you want, though the URLs escape me. In my experience, this has slowed down the execution of my C++ applications considerably but that said, my applications tend to allocate and deallocate memory quite frequently.
Garbage collection is highly overrated. GC is useful for systems that make use of a great deal of non-stack memory (such as Java) but for low-profile processes, reference counting is much more useful. In fact, overall memory use will be significantly lower.
STL has auto_ptr which sucks. Writing a reference counted class is rather easy but it's been done so why not benefit from it? Take a look at Boost for a bunch of neat reference couting classes or for a fully reference counted object library, OPP.
The idea is to essentially not use the new operator at all. Instead of deleted new objects with no references when memory is needed, reference counting deletes an object as soon as the last reference goes away. With STL containers, there is really no justification for having any new's anywhere in a C++ program.
Check out More Effective C++ for ways on making it illegal to even call the new operator in your program. That should ensure no memory leaks...
I keep track of all the EULAs I've agreed to. Fortunately, none of them have been provided by MS. That is why I do not run Windows, I do not agree with MS's licensing terms.
lol! Well, that's the first person I've ever heard use the term "unix-y" in a negative way.
I have to admit, I was on a bit of a tangent when I wrote that response, but I stand by my intention that one who has learned to use Emacs properly would never switch to something else.
Perhaps you should try XEmacs? XEmacs has a toolbar and the more familiar point-and-click interface along with the powerful lisp backend. GNU Emacs does not have such an interface because it needs to work in both GUI and console mode.
Emacs isn't good for writing formatted documents, but as far as programming is concerned (or working with plain text), emacs just is so useful.
Before entirely giving up on Emacs, I suggest checking out XEmacs and reading the Emacs tutorial. Give it a chance and you'll find it so much more useful.
Emacs is not just a better editor, but it has features that no other editor has. So people often come off of the Windows world use to Word and Notepad and never really understand what an editor is capable of.
Either way, atleast your not abandoning Emacs for vi;-)
I used the words user mode and kernel mode not to mean protected and real mode (as often thought in the x86 world) but to define different execution states.
There is no protection mechanism for any of the kernel data in Win9x. Every process has read/write access to all resources. So, a lot of the aspects of the kernel that normally would run only in kernel mode (real mode), are actually running in user mode (protected mode) such as WinSock.
There is no clear definition between user mode verses kernel mode in Win32. All processes are _essentially_ running in kernel mode.
First of all, a qubit box does not classify as a computer. If I hooked up a couple logical gateways together that does not classify as a computer. A computer must have input, output, and be capable of being programmed in some way.
There is no fundamental theory of quantum computing. As mentioned in another response, there is no boolean algebra equivalent for quantum computing.
Computers are based in absolute truth. Quantum computing relies on probability. That is where my question of praticality comes in.
I do not doubt that the NSA is more technologically advanced but don't give them too much credit...
I get sick of people spouting about how quantum computing is so great because it doesn't even exist yet. This may sound ironic seeing how everyone responded to my post, but it pisses me off when people who have no understanding of quantum mechanics start saying, "Quantum computing means you can executed all your code all at the same time" and stuff like that.
The problem with/. is that there are too many smart people on it. Can't get pissed off at anything without getting mod'd as a troll...
1) Pre-emptive
The operating system can interrupt the currently running process to allow another process to run
2) Co-operative multi-tasking
A task gives control back to the operating system in order to let more programs run.
3) User Mode
On most platforms, an execution state with limited hardware and memory access.
4) Kernel Mode
On most platforms, an execution state with direct access to all system resources including page tables and hardware.
Win3.1 runs entirely in Kernel Mode and uses co-operative multi-tasking.
Win9x runs entirely in Kernel Mode and uses pre-emptive multi-tasking.
WinNT based systems (including Win2k) uses pre-emptive multi-tasking and supports both user mode and kernel mode.
Linux uses pre-emptive multi-tasking and supports both user mode and kernel mode.
Now, a system that has pre-emptive multi-tasking can either only allow pre-emption to occur in user mode, or in both user mode and kernel mode.
Theoritically, something should not be in kernel mode for a very long period of time and what's being done in kernel mode tends to be very important.
So, Linus never really was very concerned about kernel mode pre-emptiveness because it's not terribly useful unless you have a horribly inefficent kernel or you require absolute real-time operations. Instead, he wanted to focus on making sure the kernel was as efficent as possible.
This patch allows one to enable kernel pre-emption, but be forewarned, that it will only increase the total time spent in kernel mode (doing the necessary checks) and it will not have a noticable effect unless you are running very real-time applications. That is why it's disabled by default.
It's a good thing to have for a kernel, but it's not very useful for the average user. That's why it's a configuration option. The big performance increase people are referring to is because of the new scheduler... That's a different thread though.
The fact that WinNT has a pre-emptive kernel is not necessarily a good thing. They are undoubtly taking a performance hit for it and since one can't disable it, there is no way to not have it if one doesn't need it.
I think Linus made a good decision about letting it into the kernel mainline, but I think he also made a good decision about keeping it as a configuration option and not integrating by default.
Oh wait, that name's already taken as it's been a part of XFree86 by default since the 4.0 release!
Man, people piss me off sometimes... I wish people would actually read something about X before bitching about it on/.
I don't know why people think X is so horrible. X just destroys Windows as a windowing system. The only plus Windows has it that it has better hardware support. Other than that, X blows Windows away.
GNU was meant to be an operating system. An operating system is composed of a kernel, and then supporting software.
What you are using is most likely some distribution that includes the GNU binutils, libc, and tons of other GNU tools. It also contains the Linux kernel. All together, there is likely more code on your PC that belongs to the GNU project than to the Linux project. Therefore, it only makes sense to call the operating system you use, GNU/Linux. No one is making the argument that Linux should be referred to as GNU/Linux, just that the operating system which is composed chiefly of the Linux kernel and GNU utilites should properly be referred to as GNU/Linux.
Linux wouldn't compile with Intel c++ and it surely would not be 30% faster. The linux kernel hackers choose GCC because they knew exactly how it produced code. Linux is highly optimized to produce the best possible code from GCC, and in spots where performance is key, the code is written in assembly.
Porting Linux to Intel c++ would do nothing, especially since Linux is written in C and the 30% figure comes from many of the patented optimizations that Intel owns for C++. Has nothing to do with C.
If you went from Emacs to KWrite, you obviously never knew how to use Emacs properly because no one in their right mind would switch from Emacs to KWrite.
The fact of the matter is that Linux as you know it is more of a GNU project than a Linux project. The kernel is not terribly big or important and it no where near independent of the GNU system.
Oh, BTW, you criticism RMS because he's written Emacs, GCC, GDB, Guile, etc and you've written???
I do not need to have reiterated the reasons why I _don't_ use MS products every two seconds on/.
Yes. MS is bad. We've all figured that out. If the battle is going to be fought though, make it a battle fought on the grounds of content and stability, don't just complain about a EULA.
No one has a right to complain about what MS puts in their EULA because if you don't like it, don't agree to it!
ummm.... Let me make a slight correction. No one has ever used a quantum computer before. Quantum computers do not physically, or theoritically exist. Right now, it is just the buzz word of the moment.
I have yet to hear a single person explain how quantum computing is effective for doing anything pratical. IMHO, the Heisenberg Uncertainity Principle kind of makes quantum computing very not useful... The only real thing that can be done is based on statistics and quantum mechanics has this nice little habit of not following the traditional laws of statistics.
I have to say that I agree with 90% of what you say but I strongly disagree with the other 10%.
The key word is responsibility. If a programmer is able to get their stuff done and work well within an environment, then there is no sense making waves if he keeps odd hours.
It's one thing to work 1400-2100 but don't hassle someone because their coming in at 1000 instead of 0800 when they are putting in 16 hour days.
As for a dress code, most programmers don't directly interact with the customer. If they do, then they should present a good image of the company. If a guy comes in with a T-Shirt because he is going to put in a 20 hour day and wants to be comfortable at 2AM, well, let it be.
Bitching about management is always going to happen. Playing video games should be dealt with in the harshest of ways.
A few hours of meetings a week can be really damaging to productivity if they are spread out all through the week so that the programmer only has like 2-3 hour stretchs to do real work. Programming requires long durations of uninterrupted time to be effective.
1) Adding more people (especially entry level) to a project does not get it done quicker.
2) Most of the time, one cannot justify reducing the schedule of a project by equally reducing the requirements as requirements are often interdependent.
3) Every moment a programmer spends filling out paper work, attending training, or attending meetings goes against productivity by a factor of 2. Productive programming requires long uninterrupted durations of time. If these things are required, block them together to maximize programming durations.
4) Some problems just can't be solved by throwing money at them. Therefore it is important to have a knowledgable person within each team to determine whether something is technically feasible. Essentially, management should generally not try to determine the technically feasibility of a task.
5) Large teams are not more productive. While it's tempting to float unproductive people on productive teams, the team will take a huge productivity hit. It makes more sense to have some projects fail and other succeed rather than having everything delivered half-ass.
I partially agree with some of the things expressed about not given in to the dot-com type attitude. Managers really have to crack down on people that goof off too much. Goofing off too much should be judged by the individuals productivity and how their goofing off effects others productivity.
If you have a guy that helps everyone and is 3 or 4 times more productive than everyone else, then if he is surfing the net, leave it be. On the other hand, if you have an individual who hasn't written a working line of code in a month and sits around chatting all day, well, then a manager needs to step in.
The flexibility of a programmers work habits should be a priviledge, not a right.
I don't know what the use is in responding to an AC, but this seems to be the best expression of the general misconception.
The issue isn't whether 20K is a reasonable travel buy but rather whether is makes sense to just award him 20K as a travel budget when we will be forced to pay taxes on it reducing it to like 13K when assuming Perl Foundation is a non-profit, they could take him on the payroll and avoid the 7K in taxes.
That's what my concern is... I personally don't think 20K is an unusually large amount for travel expenses. Perl has a ton of developers, but having someone to represent perl is terribly important for the growth of the language.
I'm assuming you have first hand experience with this issue because I honestly have never heard anyone argue this point. I've also worked on a number of open source projects and have never known anyone to take a significant amount of time away from their professional career working on free software.
I do know individuals who may have missed certain oppertunities to excel at their jobs but that was only because they did not invest the overtime as they had prior obligations with the open source projects.
I have to say though that I understand your point and agree with you from a philosophical stand point, but I don't know if I concur with your call to action of FS leaders since I really don't know/think the problem is as wide spread as you seem to feel it is.
What exactly did you feel supported your claim in the presentation? I know there was a bit on people who do FS at their work but I was under the impression that it was _part_ of their work, not replacing their work. I know many individuals (including myself) who have worked on FS projects as part of their job - usually to adopt a FS project to be used in a production environment.
I'm actually interested to hear if this is really a widespread problem, because if it is, then I would definitely to my part do improve integrity with the FS world. It's been my experience though that most FS programmers have a pretty high degree of integrity as it is already though...
I must go to the book store atleast once a week and spend quite a bit of money on books.
I go so often because there are so few good computer books out there. So many books are published that are oriented towards beginner programmers. Very few are really oriented towards hardcore programmers.
The thing is, I buy almost all the really good books I can find because even if they contain a bit of duplicate info, those one or two articles can be so valuable.
Some good examples are the (More)? Effective C++ and Effective STL series by Scott Myers and the O'Reilly book on Linux Device drivers (both editions).
Some topics that I would like to see covered:
STL and STL-extensions (in depth including performance analysis data).
Hard statistics about various algorithms performance in various languages
Degrees of support of the ANSI/ISO C++ among leading compilers
A cleaned-up version of the ANSI/ISO C++ spec (that was annotated to expand on how most compiler actually implement things)
Portability considerations between various flavors of Unix
Various methods of distributing Unix software packages (autoconf, apt-get, RPMS) with detailed descriptions of each of the individual package creation languages.
I'd say the last one is probably the most realistic and I am pretty sure that it is something that a lot of Unix programmers would really like to see.
The real key is having a great deal of content. Every book doesn't have to have an overview of computer architecture...
programmer A has 30% downtime (from the employer's perspective) and spends all of it goofing off. Programmer B has 40% downtime, which could also be spent goofing off, but FS work cuts into the goof-off time so that it's only 20%.
I don't think it's fair to assume that the FS programmer will have more downtime. Any activity that improves one's skills also is semi-productive too so even if there is a slightly greater down time, the gain in productivity from expanding one's skill set should offset that.
Now, programming is an odd thing too that I think managers have a hard time understand unless they have a very techinical background. Sometimes productivity is not just code, but thoroughly analyzing a design or pondering a certain issue. I heard a few managers rationalize downtime in this way since goofing off is really just multi-tasking.
While I recognize the fundamental principle that working on non-work related material is not a Good Thing (tm), I have to disagree that individual who work on FS projects are likely to be less productive than those who don't. I wouldn't say that FS is a virus that is destroying corporate productivity. In fact, I would imagine that it only improves corporate productive as it improves an employee's skill set.
Your comments on the 'dark side' of learning how to manage time are very true. Alot of more experience programmers do get stuck in the cube farm mainly because they've learned how to play management just right to get away with the least amount of work possible.
I would not draw the conclusion though that the cost of free software rides on corporations though. I definitely am of the opinion that free software costs no more to a corporation than any other hobby would. It also seems reasonable that since FS improves an employee's skill set, it is lesser of an evil than any other hobby.
I think the biggest fears management have towards FS is that they see it as competition. I don't think they have an easy time understanding the fundamental difference between work related programming (which can be stressly and tedious) verses FS programming (which is stimulating and for lack of a better term, fun).
So, I do understand how a manager may have greater reservations about an Employee working on a FS project verses just joking around at the water cooler, but I think these fears have no justification.
The intellectual-property contamination is definitely a whole different issue. I have always atleast been of the opinion that any FS I work on has to be entirely unrelated to what I do at work in order to avoid conflict of interest.
Well, I'm basing my logic on the fact that FS is what most FS programmer do in their downtime. While they also may have some pure goof-off time, my point is that the FS would likely seem to cut into the goof-time and not the productive time since one has to assume that if most FS programmers have 11+ years experience, they have learned by know how to manage their time at work.
Slashdot Mirror
1) circular references aren't terribly common to begin with and can be avoided.
2) this is true, but I assume that if one requires GC than there will be a significant amount of garbage. It's simply, relatively painless, and is used quite frequently in C++. Therefore, for a production environment, using reference counting may not be as efficent, but it is more likely to be effective as it is maintainable.
Unless there is a readily available GC for C++ that works really well and is Free as in speech and beer? If there is, then use it, but I don't know of one.
grrrr, forgot the < & >
typedef RCFactory<Vehicle> VehicleFactory;
class Vehicle : public ReferenceCounted { virtual void drive()=0; };
class Car : public ReferenceCounted { virtual void drive() {} };
vector<RCPtr<Vehicle> > vehicles;
vehicles.push_back(RCPtr<Vehicle>().set(dyna mic_cast<Vehicle *>(RCPtr<Car>().get()));
Of course, one would imagine that one would use factories instead and make things a whole lot cleaner. That is the basic gist of it. It's not about _never_ using new, but making sure that only a single class (the parameterized RCPointer class or factory classes) ever actually calls it.
With factories, it would be as simply as this:
typedef RCFactory VehicleFactory;
VehicleFactory a = VehicleFactory::create();
vehicles.push_back(a());
I have a bit of a problem with your assertion that operating overloading isn't useful.
In fact, if you take a look at java, they go to great lengths to implement comparision interfaces when overloading comparision functions makes much more sense.
Streaming is a great use of operator overloading too. Most importantly, implementing primative replacements absolutely requires operating overloading. Take for instance the lowly bit mask. Many circumstances requires a generic bit mask that will handle more than 32 flags. This is a perfect place to use operator overloading because all your doing is designing a class to take the place of a primative and behave in the same way as a primative.
Also, complex math using vectors, matrices, and complex numbers most certainly require the use of operating overloading to be intuitive. You cannot tell me that using the + operator on two matrices to obtain their summation is not more intuitive than having some silly method especially since it would have to be a static method anything.
Matrix a, b, c;
a = b + c;
verses:
a = Matrix.add(b, c);
Now, explain to someone with their math degree (not CS degree) why they are using infix operators for primative math but prefix operators for math with complex types and they'll look at you like your crazy.
Infix is more intuitive. That's why people use C/C++/Java and not LISP (not that LISP's a bad language...)
From a design standpoint, sometimes MI is required. Sometimes an object does need to be two separate things. I am not a Java expert, but I assume a member of an interface cannot be overridden (if it could, than interfaces are just classes that support MI). So, what happens when you have an object that needs to be treated as two entirely separate objects in different places in your code?
Lets say for example you have a class representing humans, well, you may want to have humans be both a Mammal and an Earthling. Let's assume that there is no interconnection between mammals and earthlings (I couldn't think of a better generic example). You may want to treat a human object as an earthling in one spot of the code, and as a mammal in another spot of the code.
Assume that each of these have virtual functions that are overridden by the human class.
If you use interfaces to solve this problem, then that may work, but it's fundamentally wrong because one should treat an interface as a generic object that implements these functions verses an object that actually is this thing.
MI has pitfalls and can be used very incorrectly, but that doesn't mean that it isn't needed in a good number of circumstances.
I think the real problem with C++ is that it doesn't have interfaces (or signatures as G++ has done). That makes it necessary to have a great number of abstract base classes that really should just be interfaces.
That's a whole other issue though...
So, here's my list
Does such a thing exist??? Every language has an IDE. Visual Studios, JBuilder, Emacs, KDevelopers, etc.
Well, this really depends on the operating system. Java's the good place to go here. If that can't be done, GTK and Qt are good libraries and they use the standard X style callback mechanism which is so much nicer than message based systems. What your really looking though is for a WYSIWYG GUI designer so I'd recommend Glade or whatever comes with the IDE you go with.
Such a buzz word... Java and C++ both use exceptions. Good error handling has more to do with a projects design though and not really the particular language...
Lets get our terminology right
IMHO, MI is necessary for advanced projects but Java interfaces _almost_ make MI unnecessary. You may do well to evaluate whether you truly need MI. What really matters, is how good your development team is.
This really should be in Java if you ask me but it isn't. You really don't need it. You could use interfaces instead. Of course, C++ support for operator overloading is great. Again though, you should really evaluate if you truly need such an advanced feature. If you just going to use it to concat strings then you don't need it.
Java or GCC. C++ is portable as long as it's GCC on both platforms
I think I'd have to agree with the general sentiment that you really need to evaluate your requirements because they are extremely unjustified and appear to be either (1) a bad manager, (2) pressure from employees to obtain "resume builder" skills, or (3) a very complicated project which you are not providing very much required information for
No language can satisify all your requirements perfectly. C++ comes closest. A combiniation of C++ and Java would do the job nicely.
That said, C++ does not have any built-in garbage collection which is in my opinion a shame. Still, you can plug in garbage collection if you want, though the URLs escape me. In my experience, this has slowed down the execution of my C++ applications considerably but that said, my applications tend to allocate and deallocate memory quite frequently.
Garbage collection is highly overrated. GC is useful for systems that make use of a great deal of non-stack memory (such as Java) but for low-profile processes, reference counting is much more useful. In fact, overall memory use will be significantly lower.
STL has auto_ptr which sucks. Writing a reference counted class is rather easy but it's been done so why not benefit from it? Take a look at Boost for a bunch of neat reference couting classes or for a fully reference counted object library, OPP.
The idea is to essentially not use the new operator at all. Instead of deleted new objects with no references when memory is needed, reference counting deletes an object as soon as the last reference goes away. With STL containers, there is really no justification for having any new's anywhere in a C++ program.
Check out More Effective C++ for ways on making it illegal to even call the new operator in your program. That should ensure no memory leaks...
I keep track of all the EULAs I've agreed to. Fortunately, none of them have been provided by MS. That is why I do not run Windows, I do not agree with MS's licensing terms.
lol! Well, that's the first person I've ever heard use the term "unix-y" in a negative way.
;-)
I have to admit, I was on a bit of a tangent when I wrote that response, but I stand by my intention that one who has learned to use Emacs properly would never switch to something else.
Perhaps you should try XEmacs? XEmacs has a toolbar and the more familiar point-and-click interface along with the powerful lisp backend. GNU Emacs does not have such an interface because it needs to work in both GUI and console mode.
Emacs isn't good for writing formatted documents, but as far as programming is concerned (or working with plain text), emacs just is so useful.
Before entirely giving up on Emacs, I suggest checking out XEmacs and reading the Emacs tutorial. Give it a chance and you'll find it so much more useful.
Emacs is not just a better editor, but it has features that no other editor has. So people often come off of the Windows world use to Word and Notepad and never really understand what an editor is capable of.
Either way, atleast your not abandoning Emacs for vi
Too many bad words...
:)
I used real mode but that was not correct. I am not familiar with the CRn concept having only worked with the Linux kernel...
long day i guess
I knew this would happen :)
:)
I should have clarified.
I used the words user mode and kernel mode not to mean protected and real mode (as often thought in the x86 world) but to define different execution states.
There is no protection mechanism for any of the kernel data in Win9x. Every process has read/write access to all resources. So, a lot of the aspects of the kernel that normally would run only in kernel mode (real mode), are actually running in user mode (protected mode) such as WinSock.
There is no clear definition between user mode verses kernel mode in Win32. All processes are _essentially_ running in kernel mode.
The nominative word is essentially though
First of all, a qubit box does not classify as a computer. If I hooked up a couple logical gateways together that does not classify as a computer. A computer must have input, output, and be capable of being programmed in some way.
/. is that there are too many smart people on it. Can't get pissed off at anything without getting mod'd as a troll...
There is no fundamental theory of quantum computing. As mentioned in another response, there is no boolean algebra equivalent for quantum computing.
Computers are based in absolute truth. Quantum computing relies on probability. That is where my question of praticality comes in.
I do not doubt that the NSA is more technologically advanced but don't give them too much credit...
I get sick of people spouting about how quantum computing is so great because it doesn't even exist yet. This may sound ironic seeing how everyone responded to my post, but it pisses me off when people who have no understanding of quantum mechanics start saying, "Quantum computing means you can executed all your code all at the same time" and stuff like that.
The problem with
Four keys terms to know:
1) Pre-emptive
The operating system can interrupt the currently running process to allow another process to run
2) Co-operative multi-tasking
A task gives control back to the operating system in order to let more programs run.
3) User Mode
On most platforms, an execution state with limited hardware and memory access.
4) Kernel Mode
On most platforms, an execution state with direct access to all system resources including page tables and hardware.
Win3.1 runs entirely in Kernel Mode and uses co-operative multi-tasking.
Win9x runs entirely in Kernel Mode and uses pre-emptive multi-tasking.
WinNT based systems (including Win2k) uses pre-emptive multi-tasking and supports both user mode and kernel mode.
Linux uses pre-emptive multi-tasking and supports both user mode and kernel mode.
Now, a system that has pre-emptive multi-tasking can either only allow pre-emption to occur in user mode, or in both user mode and kernel mode.
Theoritically, something should not be in kernel mode for a very long period of time and what's being done in kernel mode tends to be very important.
So, Linus never really was very concerned about kernel mode pre-emptiveness because it's not terribly useful unless you have a horribly inefficent kernel or you require absolute real-time operations. Instead, he wanted to focus on making sure the kernel was as efficent as possible.
This patch allows one to enable kernel pre-emption, but be forewarned, that it will only increase the total time spent in kernel mode (doing the necessary checks) and it will not have a noticable effect unless you are running very real-time applications. That is why it's disabled by default.
It's a good thing to have for a kernel, but it's not very useful for the average user. That's why it's a configuration option. The big performance increase people are referring to is because of the new scheduler... That's a different thread though.
The fact that WinNT has a pre-emptive kernel is not necessarily a good thing. They are undoubtly taking a performance hit for it and since one can't disable it, there is no way to not have it if one doesn't need it.
I think Linus made a good decision about letting it into the kernel mainline, but I think he also made a good decision about keeping it as a configuration option and not integrating by default.
Oh wait, that name's already taken as it's been a part of XFree86 by default since the 4.0 release!
/.
Man, people piss me off sometimes... I wish people would actually read something about X before bitching about it on
I don't know why people think X is so horrible. X just destroys Windows as a windowing system. The only plus Windows has it that it has better hardware support. Other than that, X blows Windows away.
And this got mod'd up to 4... Sheeesh
GNU was meant to be an operating system. An operating system is composed of a kernel, and then supporting software.
What you are using is most likely some distribution that includes the GNU binutils, libc, and tons of other GNU tools. It also contains the Linux kernel. All together, there is likely more code on your PC that belongs to the GNU project than to the Linux project. Therefore, it only makes sense to call the operating system you use, GNU/Linux. No one is making the argument that Linux should be referred to as GNU/Linux, just that the operating system which is composed chiefly of the Linux kernel and GNU utilites should properly be referred to as GNU/Linux.
Linux wouldn't compile with Intel c++ and it surely would not be 30% faster. The linux kernel hackers choose GCC because they knew exactly how it produced code. Linux is highly optimized to produce the best possible code from GCC, and in spots where performance is key, the code is written in assembly.
Porting Linux to Intel c++ would do nothing, especially since Linux is written in C and the 30% figure comes from many of the patented optimizations that Intel owns for C++. Has nothing to do with C.
If you went from Emacs to KWrite, you obviously never knew how to use Emacs properly because no one in their right mind would switch from Emacs to KWrite.
The fact of the matter is that Linux as you know it is more of a GNU project than a Linux project. The kernel is not terribly big or important and it no where near independent of the GNU system.
Oh, BTW, you criticism RMS because he's written Emacs, GCC, GDB, Guile, etc and you've written???
Who cares what's in an MS EULA.
/.
I do not need to have reiterated the reasons why I _don't_ use MS products every two seconds on
Yes. MS is bad. We've all figured that out. If the battle is going to be fought though, make it a battle fought on the grounds of content and stability, don't just complain about a EULA.
No one has a right to complain about what MS puts in their EULA because if you don't like it, don't agree to it!
ummm.... Let me make a slight correction. No one has ever used a quantum computer before. Quantum computers do not physically, or theoritically exist. Right now, it is just the buzz word of the moment.
I have yet to hear a single person explain how quantum computing is effective for doing anything pratical. IMHO, the Heisenberg Uncertainity Principle kind of makes quantum computing very not useful... The only real thing that can be done is based on statistics and quantum mechanics has this nice little habit of not following the traditional laws of statistics.
I have to say that I agree with 90% of what you say but I strongly disagree with the other 10%.
The key word is responsibility. If a programmer is able to get their stuff done and work well within an environment, then there is no sense making waves if he keeps odd hours.
It's one thing to work 1400-2100 but don't hassle someone because their coming in at 1000 instead of 0800 when they are putting in 16 hour days.
As for a dress code, most programmers don't directly interact with the customer. If they do, then they should present a good image of the company. If a guy comes in with a T-Shirt because he is going to put in a 20 hour day and wants to be comfortable at 2AM, well, let it be.
Bitching about management is always going to happen. Playing video games should be dealt with in the harshest of ways.
A few hours of meetings a week can be really damaging to productivity if they are spread out all through the week so that the programmer only has like 2-3 hour stretchs to do real work. Programming requires long durations of uninterrupted time to be effective.
1) Adding more people (especially entry level) to a project does not get it done quicker.
2) Most of the time, one cannot justify reducing the schedule of a project by equally reducing the requirements as requirements are often interdependent.
3) Every moment a programmer spends filling out paper work, attending training, or attending meetings goes against productivity by a factor of 2. Productive programming requires long uninterrupted durations of time. If these things are required, block them together to maximize programming durations.
4) Some problems just can't be solved by throwing money at them. Therefore it is important to have a knowledgable person within each team to determine whether something is technically feasible. Essentially, management should generally not try to determine the technically feasibility of a task.
5) Large teams are not more productive. While it's tempting to float unproductive people on productive teams, the team will take a huge productivity hit. It makes more sense to have some projects fail and other succeed rather than having everything delivered half-ass.
I partially agree with some of the things expressed about not given in to the dot-com type attitude. Managers really have to crack down on people that goof off too much. Goofing off too much should be judged by the individuals productivity and how their goofing off effects others productivity.
If you have a guy that helps everyone and is 3 or 4 times more productive than everyone else, then if he is surfing the net, leave it be. On the other hand, if you have an individual who hasn't written a working line of code in a month and sits around chatting all day, well, then a manager needs to step in.
The flexibility of a programmers work habits should be a priviledge, not a right.
Or one could use the MagicSys keys built into the kernel and simply use a standard keyboard :)
I don't know what the use is in responding to an AC, but this seems to be the best expression of the general misconception.
The issue isn't whether 20K is a reasonable travel buy but rather whether is makes sense to just award him 20K as a travel budget when we will be forced to pay taxes on it reducing it to like 13K when assuming Perl Foundation is a non-profit, they could take him on the payroll and avoid the 7K in taxes.
That's what my concern is... I personally don't think 20K is an unusually large amount for travel expenses. Perl has a ton of developers, but having someone to represent perl is terribly important for the growth of the language.
I'm assuming you have first hand experience with this issue because I honestly have never heard anyone argue this point. I've also worked on a number of open source projects and have never known anyone to take a significant amount of time away from their professional career working on free software.
I do know individuals who may have missed certain oppertunities to excel at their jobs but that was only because they did not invest the overtime as they had prior obligations with the open source projects.
I have to say though that I understand your point and agree with you from a philosophical stand point, but I don't know if I concur with your call to action of FS leaders since I really don't know/think the problem is as wide spread as you seem to feel it is.
What exactly did you feel supported your claim in the presentation? I know there was a bit on people who do FS at their work but I was under the impression that it was _part_ of their work, not replacing their work. I know many individuals (including myself) who have worked on FS projects as part of their job - usually to adopt a FS project to be used in a production environment.
I'm actually interested to hear if this is really a widespread problem, because if it is, then I would definitely to my part do improve integrity with the FS world. It's been my experience though that most FS programmers have a pretty high degree of integrity as it is already though...
I go so often because there are so few good computer books out there. So many books are published that are oriented towards beginner programmers. Very few are really oriented towards hardcore programmers.
The thing is, I buy almost all the really good books I can find because even if they contain a bit of duplicate info, those one or two articles can be so valuable.
Some good examples are the (More)? Effective C++ and Effective STL series by Scott Myers and the O'Reilly book on Linux Device drivers (both editions).
Some topics that I would like to see covered:
I'd say the last one is probably the most realistic and I am pretty sure that it is something that a lot of Unix programmers would really like to see.
The real key is having a great deal of content. Every book doesn't have to have an overview of computer architecture...
programmer A has 30% downtime (from the employer's perspective) and spends all of it goofing off. Programmer B has 40% downtime, which could also be spent goofing off, but FS work cuts into the goof-off time so that it's only 20%.
I don't think it's fair to assume that the FS programmer will have more downtime. Any activity that improves one's skills also is semi-productive too so even if there is a slightly greater down time, the gain in productivity from expanding one's skill set should offset that.
Now, programming is an odd thing too that I think managers have a hard time understand unless they have a very techinical background. Sometimes productivity is not just code, but thoroughly analyzing a design or pondering a certain issue. I heard a few managers rationalize downtime in this way since goofing off is really just multi-tasking.
While I recognize the fundamental principle that working on non-work related material is not a Good Thing (tm), I have to disagree that individual who work on FS projects are likely to be less productive than those who don't. I wouldn't say that FS is a virus that is destroying corporate productivity. In fact, I would imagine that it only improves corporate productive as it improves an employee's skill set.
Your comments on the 'dark side' of learning how to manage time are very true. Alot of more experience programmers do get stuck in the cube farm mainly because they've learned how to play management just right to get away with the least amount of work possible.
I would not draw the conclusion though that the cost of free software rides on corporations though. I definitely am of the opinion that free software costs no more to a corporation than any other hobby would. It also seems reasonable that since FS improves an employee's skill set, it is lesser of an evil than any other hobby.
I think the biggest fears management have towards FS is that they see it as competition. I don't think they have an easy time understanding the fundamental difference between work related programming (which can be stressly and tedious) verses FS programming (which is stimulating and for lack of a better term, fun).
So, I do understand how a manager may have greater reservations about an Employee working on a FS project verses just joking around at the water cooler, but I think these fears have no justification.
The intellectual-property contamination is definitely a whole different issue. I have always atleast been of the opinion that any FS I work on has to be entirely unrelated to what I do at work in order to avoid conflict of interest.
Well, I'm basing my logic on the fact that FS is what most FS programmer do in their downtime. While they also may have some pure goof-off time, my point is that the FS would likely seem to cut into the goof-time and not the productive time since one has to assume that if most FS programmers have 11+ years experience, they have learned by know how to manage their time at work.