All in all I agree with your comments, they tend to be well thought out. However, you seemed to glance over the fact that mutations relevant to evolution occur during conception, not after birth.
Sure your body has lots of defenses against mutation, because like you said, if the cells just do what they want _after_ you are born, then, as you said, it falls apart very quickly.
But it is a different story when the body is still being "designed" when the DNA that makes up the new life has mutations, THAT's when evolutionary mutations occur. Radiation speeds this up as well (this is why when you get an x-ray they use led shielding to protect the family jewels).
Like I said, all in all you're on the mark, but just don't forget that we don't live in the world of teenage mutant ninja turtles where life just randomly mutates into other things after it's been born:-P
Your point about dependencies is actually a good point. You can however build konsole without arts support. There are many configure options to manage these things, and if you aren't using the whole desktop, well then you probably want to finely tune things a little more than just "./configure"
Oh well, like you said, perhaps kde 4.0 will bring more control over such options.
I don't find it to be an attack on the C++ standard at all. In fact, all of the QT containers have STL compatibility. You can use them with STL style iterators and can use STL algorithms with them as well.
Really the only issue i could possibly see if I were to look at it from your side, then it would be the containers which already have equivalents in the c++ standard library. Well, too be honest, most (all but std::queue/std::stack/std::priority_queue?) don't give protected access to the underlying implementation. This makes the preferable option (inherit and extend) a non-option.
I have always though that it would have been nice if QString inherited from std::wstring or something, but it doesn't, we move on. It's not meant to replace the standard, it's meant to complement it.
surely, in fact, the linux kernel uses object oriented programming in things like the VFS layer. The thing is, doing OOP in C is no more efficient than C++, it really is just a matter of syntax. And if you have a language which gives you OOP and is generally efficient..then why not use it.
It's just another tool in the toolbox, i like using many languages and it's just a matter of choosing the right tool for the job.
While I can't speak volumes about Gnome and GTK. I can say that you views of KDE and QT do not appear to be based on facts, but more assumptions and preconceived notions.
KDE is NOT simply QT plus bloat, the goals of the KDE library are to provide a consistent API to applications to work well with the KDE desktop. In the grand scheme of things it is actually very light as far as things it adds to QTs very complete API. For example, it will provide a KPushButton which inherits from the QPushButton class to add a few small integration features. Also KDE offers many common widget combinations as a reusable widget in itself, this is good library design as a whole. Making libraries of reusable code is a GOOD THING.
Don't mis-interpret this as KDE zealotry, I imagine that Gnome provides some sort of API to help applications integrate well with the desktop as well.
And what is your general issue with using c++ and moc? I hate to break it to you, but moc IS "real c++". There is nothing wrong with having utilities to generate code, there is huge gain to doing it with moc instead of templates...runtime bindings. moc just hides these details for you, and to be honest, you usually don't even have to worry about it at all if you use the QT build system.
As for what is wrong with GTK + C? Well nothing is wrong with it but it's not the only choice. One thing to keep in mind though is that graphical displays usually consist of conceptual objects "windows", "buttons", "listboxes", "textboxes", etc. These are all "things" which to be honest, creating code to describe "things" is what object oriented programming excels at.
You will never see a port to GTK of KOffice because it would not be a port, but a litteral re-write as the whole code base is built around the KDE/QT libraries.
And why not start with AbiWord? Heh, this statement is a shinning example of a preference not based on the merits of what you want, but instead on an arbitrary dislike for the competition. You are of course entitled to your opinion, nothing is perfect. But you provide no real reason why something built on KDE libraries is inherently bad. Secondly, Abiword is a single word processor application with no integration into an "office solution". KOffice is looking to provide the whole shebang.
I imagine you are going to reply with "KDE is bloated", "KDE is slow". But these generalizations aren't really based on real facts. KDE is actually quite lean (and KDE 4.0 is going to be leaner because QT 4.0 is a vast improvement of 3.0). Its memory usage is nothing crazy, the reason for this is that there is a LOT of code reuse. Using the KDE libraries is effectively "free" as far as memory usage goes because modern operating systems do code sharing of dynamic libraries and the whole damn desktop uses these libraries! There are benchmarks that show that Gnome and KDE are actually quite comparable: http://ktown.kde.org/~seli/memory/desktop_benchmark.html
I'll even not go so far as to say KDE is better than Gnome in memory usage because I know that there are many factors and a single set of benchmarks by one person doesn't really prove much...but it does show that they are at least in the same ballpark.
All in all, I find your argument against using a modern library not founded in facts:(
you can easily get the same effect as the java "interface" mechanism bu supplying a class which contains only pure virtuals (and a virtual destructor). For example:
class AnimalInterface { public:
virtual ~AnimalInterface() {} // note the = 0; on the next lines, that means "pure virtual" // pure virtual means "no implementation here, a child class must implement
virtual void eat() = 0;
virtual void poop() = 0; };
if a class inherits from AnimalInterface and fails to implement eat or poop, it will result in a compiler error, this the child class must implement the "interface" supplied by the parent class. And just like java, this is safe with regard to multiple inheritance because the pure virtual functions have no implementation, which means no ambiguity with regard to which parent function to call.
I don't the the submitter understands multi-core OS's and how they are designed. Primarily the quote "Do you think it's it a smart move to further complicate an operating system to take advantage of multiple cores, or should Microsoft stick to its knitting while applications take advantage of (possibly) more resources?" gives it away.
The reason is because an application cannot really be written to take advantage of more cores unless the OS supports it. The best it can do is use algorithms which utilize more threads of execution which the OS can choose to run on multiple cores. Using more threads isn't always good, since you could be wasting time context switching on the same CPU, so the app would likely want to ask the OS how many CPUs it is working on. A prime example of this would be a multiple threaded decompresser, assuming all the I/O is out of the equation (whole image is in memory), you will likely want a thread per CPU since all threads will max out there time slices decompressing. Any more threads, and they start fighting for time slices to do work in and end up doing it in less time.
Anyway, on an OS level, multiple core support is VERY important. Linux made some huge steps in this direction in 2.6 by making the kernel preempt-able in a lot more spots. This is difficult as race conditions are sometimes hard to see, but done right and you end up with a lot less serialization of thread execution. Also of course the scheduling algorithm has to be smart enough to not bounce a thread back and forth between multiple CPUs to maintain cache consistency, this is where the notion of CPU affinity comes in. Generally the goal of any OS is the keep the CPUs as busy as possible with useful work as it can.
Finally using less coarse locking mechanisms is huge in multiple-core kernels. For a long time, Linux had something (and still does, it's just not supposed to be used anymore) called "the big lock". The idea was if you new some code was not thread safe, you could wrap it in the big lock and you would be good since NO OTHER code runs while this lock is held, it is a global critical section. The problem is, that while this is safe design, it is highly inefficient design. The correct thing to do is to have many different locks for all your different resources so that two unrelated thread sensitive pieces of code can run concurrently. From what I've heard from some MS employees, Win95 had a similar concept, and was transitioned to more fine grained locking techniques in Win98, this explains the big jump in responsiveness in Win98 as well as the jump in instability in Win98 (since these more efficient techniques are simply hard to get right the first time):-P.
All in all, there is no question that if multiple cores are here to stay, the OSes must be written to take advantage of them. At the very least, things like SMP and other multiple processing systems have a efficiency that can be gained from these types of changes.
When did it stop being a good thing to look at the completion and attempt to take the best parts of what they do and try to do it better? You see this type of behavior in every market, it's nothing new nor is it something to whine about. Sure there needs to be some genuine innovation, but there is nothing wrong with saying "hey those guys did a pretty decent job with this feature, we like it, but we can probably improve it a little."
ok, here's my issue with theories that the universe is finite.
Basically, it boils down to if the universe is finite, it therefore has shape and bounds right? In this particular case, we are comparing it to a soccer ball. But if it has bounds, then what is beyond those bounds? Is our "universe" inside a larger finite shape? or is what contains our universe infinite?
I assume they mean to imply that it would defy the rules of the "universe" to be able to escape it into said container, but that doesn't eliminate the fact that if the universe is finite, then the question remains, what is outside of our universe? I don't think "nothing" is appropriate either.
Basically, I suppose it is a matter of definition, to me universe means "all that exists", but if what we know as the universe has bounds and therefore exists inside some other possibly impossible to define region, then we aren't really talking about a universe anymore, we are talking about a limited subset of what I would call the universe.
Also, what if what we call a universe is one of many soccer balls (Imagine a ball bin in a store)? Are we still talking about each ball being the universe, I would think the bin is the universe then right? And if so, is it possible to break from one ball into another without doing damage to either ball?
I'm no theoretical astrophysicist, but I believe we need some better definitions about what we are actually talking about, cause really once you give way to possibility of a multiverse, you by definition no longer have a universe, since it means "everything" and therefore can only be one.
I would beg to differ, it is about stopping virus attacks. First of all, one of the main points of my post's previous argument was that if you could stop malware from modifying the kernel, you would effectively eliminate the need for AV vendors to modify the kernel as well.
Secondly to respond it being about
"This is about stopping the user from modifying the kernel's behaviour, so that Microsoft can lock down your computer and control what you do with it."
Well yea, who says that the user should be able to? Keep in mind that if patchguard technology existed in Microsoft kernels since windows 95, people would have never complained, because once again...it is the kernel's job to prevent access to critical data structures to ensure system stability and reliability.
"Not in the Windows world. There, the kernel is the software which Microsoft does not want altered - stuff like parts of the user interface, IE, etc. (I'm not kidding, IE *does* have components which run in ring 0)."
I am aware that IE has components that run in ring 0, my response is...so? IE still accesses this code through some sort of approved interface such as a system call or ioctl (this is a certainty as the hardware prevents all but a very few instructions from changing privilege levels downwards). Nothing about this fact contradicts my assertion that the kernel is supposed to be the only software which accesses these low level things and abstracts out interfaces for the rest of the software to utilize.
"This is not and never has been about stopping virus attacks - it won't accomplish that and Microsoft knows it; every Windows kernel is full of exploitable bugs and most viruses exploit them."
So basically you are saying that since it isn't an effective solution, it must be bad and/or not worth doing? That's ridiculous, I suppose you don't have an alarm system on your car either? It not like it doesn't take an experienced thief less that 30 seconds to shut it off and continue stealing your car. Car alarms are not 100% effective, but they are a deterrent, they add another level of difficulty and annoyance to the thief. Same principle applies here, it makes it more difficult and is better then not doing it at all.
Bottom line, lets say that it will stop just about half of the kernel level attacks starting in 2007. First of all, it will prevent all previous code from working, so all the malware that's out currently suddenly stops working, this is a good thing. Second of all, do you think that all future malware is going to have this patchguard bypass technology? odds are against it, maybe over time more and more will have the capability, but in the short term, let's say 50% again (probably being generous here). That is a significantly smaller amount of malware able to attack your system than before, so what's the problem?
Other AV vendors besides Mcafee and Symmantec have managed to port their AV technology to a patchguard enabled system, so it's not like you wont have any protection if something does get through.
I really fail to see the harm it putting up a defense like this.
sure it's not perfect, nothing is, but I find the effort of making patchguard a step in the right direction. Here's the thing, If it were possible to prevent anything but pre-approved code from running in kernel space, there would be basically no need for vendors to hook the kernel in the first place.
Also, a lot of people are really talking it up about how Microsoft sucks and patchguard is just another flawed attempt at security by a company that doesn't know its ass from its elbow (or something to that nature)...but I haven't seen much if any effort by any of the other mainstream OSes to prevent kernel patching at all. It is downright trivial to write a Linux kernel module which hooks all sorts of critical data structures, same with FreeBSD and Solaris.
Is it the argument of the anti-patchguard people that if it can't be done perfectly, lets not even bother?
I guess the major driving point of my being a Microsoft apologist in this case is that, at least from an academic point of view, the kernel is supposed to be the only software which accesses these low level things and abstracts out interfaces for the rest of the software to utilize...the kernel shouldn't be exposing anything like direct disk access, or kernel space memory to user space....ever, under any circumstances. do that and things like rootkits are an awful lot harder to make in the first place.
Some Linux distros are starting to get the point by limiting and sometimes eliminating entirely access to/dev/kmem which is a step in the right direction, but it's still not good enough.
The way I see it, Microsoft may not be perfect, but at least they are trying.
While I understand what you trying to say, I have to disagree with some assumptions you have made. Why can't someone who wants things to be simple be tech-savvy?
Personally I'm a software engineer who deals mostly with kernel level development. I run linux because I like to have more control over how things work (one of your points I agreed with). But none of this means that I wouldn't want things to be simpler. Here's the thing, when a computer is designed such that that tasks you want to do are simpler to get done, you are more productive. Of course the tricky part is that everyone wants to do different things with their computers. So software designers tend to go with what most people want to do and make things like email, web browsing and word processing the easiest tasks to do.
I guess my point is, I see what you are saying, but tech savvy and wanting things easier/simpler are not mutually exclusive.
I've been reading some of the comments, and I feel that people are missing the point. Basically the main arguments I'm seeing is that Microsoft is making it hard for competitors to make their software and/or this does not remove the need for AV programs.
That's the not really the point, what people are missing is that the goal of patchguard technology is NOT to prevent infection, it does no work to prevent viruses/worms/trojans from getting on your system. What it DOES do is prevent this malware from patching code in the system and using rootkit technology to hide from your AV products and system admins.
Basically the idea is that they are trying to remove the ability for malware to hide within your system.
Microsoft is getting this one right for a change and it's about time. AV vendors have been resorting to unsupported and frankly unstable "dirty tricks" to get the job done, it's not Microsoft's fault that they stop allowing an unsupported feature to work, they never said it would ever work to begin with!
This is really no different than when Linux stopped exporting the sys_call_table symbol, it simply is not a good idea, nor is it considered "stable" to hook things like system calls at run-time. I'm not saying it doesn't work, I'm saying it's a kludge since there are all sorts of race conditions that are being introduced, in addition to the stability of the kernel as a whole being subverted due to no way good way of verifying that the hooking code doesn't make a mistake and crash the system.
Bottom line is that AV vendors should quit the whining. They will need to adapt to the fact that MS is actually taking security seriously.
This reminded me, I was having a discussion with a coworker a little bit ago about how I wished that all of the popular compression algorithms would be implemented with multiple thread capability (the ideal would be either the application detecting the number of CPUs, or possibly an environmental tuning capability similar to "make -jN"). I did notice that winrar has implemented multiple thread usage in the more recent releases and even on my hyper threaded CPU which is not a true multicore system it has a noticeable increase in performance.
When will we start seeing all of the common UNIX compression utilities taking advantage of the great CPU scalability that many UNIX implementations and Linux like to brag about?
Nero does exactly what you described. In the backup wizard, you simply select the files/directories you want backed up. It will then tell you how many CDs/DVDs it will take to store all of it. And you hit, go. it really is just as simple as you describe.
personally as a programmer, I tend to define a memory leak as memory which will be freed (until program termination, since all used pages should be returned to the OS then...), particularly through programmer error. For example i would not define the following as a memory leak though i would disagree with it's style:
int main() {
int *a = new int[10];/* do some work with array a */
return 0; }
while i personally would not write code like this and would consider it bad style, it is not really a "leak" because firstly, it is by design and secondly it does not "leak" more and more memory over time. Realistically what this article is talking about sounds more like caching to me, that is intentionally delaying freeing memory with the expectation that it may be used again in the near future. Considering that there is an upper limit on how much memory it will take up overall, this sounds like it would generally improve performance.
Now, should it be configurable, sure, on by default, sure.
In reality, I find a lot of computer users, usually non-programmers are very much obsessed with the notion that programs are bloated, and frankly, it's getting annoying. I continually see generally good programs on betanews get bad ratings because "it's too much of a memory hog" or "it's bloated" or "omg! it is taking 20 megs of memory".
While it is trivially true that if a program can be written smaller with no change in performance in functionality then it should be, it never seems to dawn on people that programs may be written to sacrifice memory for performance. Anyone familiar with optimization techniques will tell you bigger does NOT equal slower.
first and foremost, use good coding techniques. This means use exception handling where appropriate, use standard containers over hand rolled data structures (prefer std::string over char arrays, this will help prevent almost all common string based buffer overflows alone), and follow good style guidelines.
As for a GUI programming, if you are strictly tied to c++, i would recommend QT (www.trolltech.com) they have a fabulous API (takes getting used to, but it makes sense once you do). Nice part about QT is that it is source portable to just about every major platform (X11, Win32, Mac).
It is possible to write reliable, fault tolerate code in c++ (realize please that perfect code is impossible in any language), it just has to be well thought out and done right.
did anyone else notice that AE4 and AE11 appear to be the same bug?
AE4 reads:
"REP MOVS (Repeat/Move a string from one memory location to another) operation in fast string mode continues in that mode when crossing into a page with a different memory type."
AE4 was listed a show stopper.
AE11 reads:
"REP MOVS operation in fast string mode continues in that mode when crossing into a page with a different memory type."
AE11 was listed as Possible effect on performance, but no data loss or corruption.
First of all these seem identical short of the explaining the pneumonic for REP MOVS, secondly it is alarming that the two entries which seemingly identical descriptions got different severity ratings!
I agree with your comments for the most part, but I have a couple of points that I can't help but at least play devil's advocate with.
"type deduction using the auto keyword.", I think that while this is a trivial feature to implement, it is being added for two simple purposes. firstly to shorten code: "std::vector::iterator" is quite a bit longer than "auto", sure we can typedef, but why should be have to. secondly to reduce need for modifying code when a container is changed. If i change from a vector to say a deque, they both support random access iterators, but until auto is supported, I'll have to at least update my typedefs, if not many lines of code which use iterators to access the container.
"No garbage collection.", ok, a garbage collection system is a reasonable request, at least it would be nice to have a compiler switch to enable it. But there is a problem, c++ opnly requires you to refer to objects using pointers, that is simply it's address. So how is the c++ language suppose to know at runtime that a pointer was just set to 0 and thus should have what it did point to freed? Or more annoyingly, we've got all sorts of pointers which point to all over the place, now we need reference counting and all sorts of voodoo. Also there is another problem, in c++ pointers dont have to point to a valid object, in java and other garbage collected languages, they don't usually use true pointers, but instead references to objects and such.:( Ok, well there are a few solutions. #1 that comes to mind is do what java/c# do and have a VM, and/or forbid pointing to non-objects, or at least make it difficult (enter managed c++), this way at compile time assignment to pointers/references can be adjusted to also send a message to the GC thread to update it's refernce count on objects and such. But this can potentially kill performance and/or sacrifice the "systems programming" elements of c++. No Bueno. Another solution is use smart pointers, kinda the similar to the idea of only pointing to objects and such and emitting code to update gc data, but leaves it in the hands of the developer AND has the benefit of not needing a language level change, but instead is implemented in the library. The third thing I can think of off hand is a compromise like managed c++ where ordinary pointer use is forbidden except in blocked with a "#pragma unmanaged" or something, outside of such blocks, things like T *p = reinterpret_cast(0x12345678); would be illegal (hey why not make pretty much most casts illegal in a "managed" context?
"no static virtual methods", OMG wanted these for a long time, good point
"the bias towards systems programming", I would beg to differ that it is being used nowhere for systems programming. There are several c++ development libraries for the windows kernel available along with MANY project OSes which intend to use modern language features to implement things in a new way, sure they will likely go unnoticed, but they still exist and we shouldn't take away from what they can do already.
"no standard GUI library." Tough call on this one, while it would be nice, this would destroy a lot of diversity in this field, I mean which API do we settle on?.NET, QT, FOX? And if one, why? If we make a new one, are we shut out from using these others? Why? If we are not shut out, why have it? Personally I think that it would have been nice a while ago when GUIs were still up and coming, but at this point it is too late, there are too many options with too many different benefits to each to pick one. Also, should my command line c++ app need X libraries to run? this leads me to think it would have to be a compile time option. Regardless, I don't feel a single API for GUI is workable with the diverse set of features on todays desktops (should the GUI have a notion of a "window", what if my new special OS doesn't use "windows" to represent programs but instead using a whole new paradim?
"no way to get the size of an array allocated with operator new []
I am by no means trying to plug gentoo, but I did just noticed that they added a patch to version 1.5 in portage to address this issue (seems to cap titles in history to 65535 bytes.
I wonder if the gentoo team plans to submit their patch upstream to mozilla...
The solution to this problem is simple, if you don't want people to have access to your material, don't put it on the internet. Sure there will be a certain degree of piracy regarding these materials, but that would be far less widespread. Realistically, if you publish something on a website, well it's kinda just "out there" and if you expect people not to find it, or better yet, expect people not to still have it after you take it down, well you live in a fantasy world. IMHO everything on a legitimate website is fairgame for copying so long as the original authors are properly credited.
I suppose the issue really is with sites like the New York Times where they ask for a free membership to view their content and expect a certain amount of ad revenue from the viewers. And I am sure they will get annoyed when someone uses the NYT link generator (http://nytimes.blogspace.com/genlink) to access the site without logging in, or worse yet, mirrors the story on there own site (while crediting the original source of course). But I mean common, what did they expect to happen?
It's not that I don't think people have a right to control their content, but more that I think trying to enforce those rights is impossible. Get with the times people.
proxy
Re:Let me know when it stops sucking
on
GCC 4.1 Released
·
· Score: 3, Insightful
you make it sound like enforcing strict rules is a bad thing. Really the only bad thing that gcc has done is accept that _broken_ code in the past. The fact that it no longer will compile constructs which are invalid in c and c++ is an improvment. c and c++ are just like any other standard (think html/xhtml and such) and when a compiler accepts invalid constructs it destroys the portability of the code.
The true ideal is to be able to write code that if it compiles on gcc you can say "i know for certain that this is valid c++". Such a goal is difficult, if not impossible (many things are "implementation defined") but is stilla goal worth shooting for.
it seems to me that this is uneccessary and nvidia has proved it. The have "binary" drivers and supply there own open source layer to provide the glue between their code and the kernel. All we are really talking about is a small layer inbetween the kernel and the driver to provide a "stable" (as it unchanging) interface. So bottom line is that this is simply a wrapper for the existing API. Well, just do what nvidia does, make the code that interacts directly with the kernel open source and proivde the API you need, then just make your binary link to that and interact with just that. Works pretty well. Yes, it would be nice if this was standardized, and could possibly save some people a little bit of time, but thre actual gain seems to be minimal (i've written drivers for linux before, not THAT much changes from release to release as far as the code your module will use goes).
First of all, since when is default deny "seldom done" and "difficult?" That's just rediculous. Just about every firewall product out today has a deny by default policy. And it is by no means a difficult concept. "Allow what you need and no more, if you find that you need something that is blocked, decide if it is _really_ needed and if so allow it" wow that's too tought to wrap my head around!
Also, the author seems to be under the impression that perfect software is possible...well sorry, bad news, it's not.
His ideas on "Penetrate & Patch" being wrong are just silly. Yes, of course it's true that some systems are more secure by design than others, no argument there. But that has nothing to do with the penetrate and patch cycle. The point of P&P is that you assume your system isn't perfect (and gee, what a far fetched idea that is!) and try to see how it could be broken. No programmer can think of everything and there _will_ be holes. I have also found that many security issues that didn't come in white box testing (that is analizing the source code) did come up in fuzzing and other black box approaches. Sometimes these problems are a lot more difficult to spot in the code than one would hope. Also the fact that software has an issue doesn't make it insecure by design (it could be, but it is not neccessarily true). Many times it is due to incorrect implementation of a good design, or simply a minor coding error.
Also, his idea that "if FOO worked, we'd have run out of BAR type of security problem by now." Yea, that's also not the case. Perfect example, buffer overflows have been around for quite a while now and we still seem them all the time. Companies make a diligent effort to prevent them, and attackers just figure out more creative ways to make em happen. Problems don't go away over night (if ever) once they are discovered and addressed.
His thoughts on enumerating badness are also a little out of whack. Sure it's not a good idea to assume that everything you know if is everything that exists...but it's a damn good place to start! This is one of those things that isn't a great idea, but is an effective first line of defense. It's gauranteed not to catch everything, but it's a sure fire way to get those low hanging fruit while you can.
Slashdot Mirror
All in all I agree with your comments, they tend to be well thought out. However, you seemed to glance over the fact that mutations relevant to evolution occur during conception, not after birth.
:-P
Sure your body has lots of defenses against mutation, because like you said, if the cells just do what they want _after_ you are born, then, as you said, it falls apart very quickly.
But it is a different story when the body is still being "designed" when the DNA that makes up the new life has mutations, THAT's when evolutionary mutations occur. Radiation speeds this up as well (this is why when you get an x-ray they use led shielding to protect the family jewels).
Like I said, all in all you're on the mark, but just don't forget that we don't live in the world of teenage mutant ninja turtles where life just randomly mutates into other things after it's been born
proxy
Your point about dependencies is actually a good point. You can however build konsole without arts support. There are many configure options to manage these things, and if you aren't using the whole desktop, well then you probably want to finely tune things a little more than just "./configure"
Oh well, like you said, perhaps kde 4.0 will bring more control over such options.
I don't find it to be an attack on the C++ standard at all. In fact, all of the QT containers have STL compatibility. You can use them with STL style iterators and can use STL algorithms with them as well.
Really the only issue i could possibly see if I were to look at it from your side, then it would be the containers which already have equivalents in the c++ standard library. Well, too be honest, most (all but std::queue/std::stack/std::priority_queue?) don't give protected access to the underlying implementation. This makes the preferable option (inherit and extend) a non-option.
I have always though that it would have been nice if QString inherited from std::wstring or something, but it doesn't, we move on. It's not meant to replace the standard, it's meant to complement it.
surely, in fact, the linux kernel uses object oriented programming in things like the VFS layer. The thing is, doing OOP in C is no more efficient than C++, it really is just a matter of syntax. And if you have a language which gives you OOP and is generally efficient..then why not use it.
It's just another tool in the toolbox, i like using many languages and it's just a matter of choosing the right tool for the job.
While I can't speak volumes about Gnome and GTK. I can say that you views of KDE and QT do not appear to be based on facts, but more assumptions and preconceived notions.
:(
KDE is NOT simply QT plus bloat, the goals of the KDE library are to provide a consistent API to applications to work well with the KDE desktop. In the grand scheme of things it is actually very light as far as things it adds to QTs very complete API. For example, it will provide a KPushButton which inherits from the QPushButton class to add a few small integration features. Also KDE offers many common widget combinations as a reusable widget in itself, this is good library design as a whole. Making libraries of reusable code is a GOOD THING.
Don't mis-interpret this as KDE zealotry, I imagine that Gnome provides some sort of API to help applications integrate well with the desktop as well.
And what is your general issue with using c++ and moc? I hate to break it to you, but moc IS "real c++". There is nothing wrong with having utilities to generate code, there is huge gain to doing it with moc instead of templates...runtime bindings. moc just hides these details for you, and to be honest, you usually don't even have to worry about it at all if you use the QT build system.
As for what is wrong with GTK + C? Well nothing is wrong with it but it's not the only choice. One thing to keep in mind though is that graphical displays usually consist of conceptual objects "windows", "buttons", "listboxes", "textboxes", etc. These are all "things" which to be honest, creating code to describe "things" is what object oriented programming excels at.
You will never see a port to GTK of KOffice because it would not be a port, but a litteral re-write as the whole code base is built around the KDE/QT libraries.
And why not start with AbiWord? Heh, this statement is a shinning example of a preference not based on the merits of what you want, but instead on an arbitrary dislike for the competition. You are of course entitled to your opinion, nothing is perfect. But you provide no real reason why something built on KDE libraries is inherently bad. Secondly, Abiword is a single word processor application with no integration into an "office solution". KOffice is looking to provide the whole shebang.
I imagine you are going to reply with "KDE is bloated", "KDE is slow". But these generalizations aren't really based on real facts. KDE is actually quite lean (and KDE 4.0 is going to be leaner because QT 4.0 is a vast improvement of 3.0). Its memory usage is nothing crazy, the reason for this is that there is a LOT of code reuse. Using the KDE libraries is effectively "free" as far as memory usage goes because modern operating systems do code sharing of dynamic libraries and the whole damn desktop uses these libraries! There are benchmarks that show that Gnome and KDE are actually quite comparable: http://ktown.kde.org/~seli/memory/desktop_benchmark.html
I'll even not go so far as to say KDE is better than Gnome in memory usage because I know that there are many factors and a single set of benchmarks by one person doesn't really prove much...but it does show that they are at least in the same ballpark.
All in all, I find your argument against using a modern library not founded in facts
proxy
indeed it does and it works very well:
http://www.boost.org/libs/utility/operators.htm
proxy
I don't the the submitter understands multi-core OS's and how they are designed. Primarily the quote "Do you think it's it a smart move to further complicate an operating system to take advantage of multiple cores, or should Microsoft stick to its knitting while applications take advantage of (possibly) more resources?" gives it away.
:-P.
The reason is because an application cannot really be written to take advantage of more cores unless the OS supports it. The best it can do is use algorithms which utilize more threads of execution which the OS can choose to run on multiple cores. Using more threads isn't always good, since you could be wasting time context switching on the same CPU, so the app would likely want to ask the OS how many CPUs it is working on. A prime example of this would be a multiple threaded decompresser, assuming all the I/O is out of the equation (whole image is in memory), you will likely want a thread per CPU since all threads will max out there time slices decompressing. Any more threads, and they start fighting for time slices to do work in and end up doing it in less time.
Anyway, on an OS level, multiple core support is VERY important. Linux made some huge steps in this direction in 2.6 by making the kernel preempt-able in a lot more spots. This is difficult as race conditions are sometimes hard to see, but done right and you end up with a lot less serialization of thread execution. Also of course the scheduling algorithm has to be smart enough to not bounce a thread back and forth between multiple CPUs to maintain cache consistency, this is where the notion of CPU affinity comes in. Generally the goal of any OS is the keep the CPUs as busy as possible with useful work as it can.
Finally using less coarse locking mechanisms is huge in multiple-core kernels. For a long time, Linux had something (and still does, it's just not supposed to be used anymore) called "the big lock". The idea was if you new some code was not thread safe, you could wrap it in the big lock and you would be good since NO OTHER code runs while this lock is held, it is a global critical section. The problem is, that while this is safe design, it is highly inefficient design. The correct thing to do is to have many different locks for all your different resources so that two unrelated thread sensitive pieces of code can run concurrently. From what I've heard from some MS employees, Win95 had a similar concept, and was transitioned to more fine grained locking techniques in Win98, this explains the big jump in responsiveness in Win98 as well as the jump in instability in Win98 (since these more efficient techniques are simply hard to get right the first time)
All in all, there is no question that if multiple cores are here to stay, the OSes must be written to take advantage of them. At the very least, things like SMP and other multiple processing systems have a efficiency that can be gained from these types of changes.
proxy
When did it stop being a good thing to look at the completion and attempt to take the best parts of what they do and try to do it better? You see this type of behavior in every market, it's nothing new nor is it something to whine about. Sure there needs to be some genuine innovation, but there is nothing wrong with saying "hey those guys did a pretty decent job with this feature, we like it, but we can probably improve it a little."
proxy
ok, here's my issue with theories that the universe is finite.
Basically, it boils down to if the universe is finite, it therefore has shape and bounds right? In this particular case, we are comparing it to a soccer ball. But if it has bounds, then what is beyond those bounds? Is our "universe" inside a larger finite shape? or is what contains our universe infinite?
I assume they mean to imply that it would defy the rules of the "universe" to be able to escape it into said container, but that doesn't eliminate the fact that if the universe is finite, then the question remains, what is outside of our universe? I don't think "nothing" is appropriate either.
Basically, I suppose it is a matter of definition, to me universe means "all that exists", but if what we know as the universe has bounds and therefore exists inside some other possibly impossible to define region, then we aren't really talking about a universe anymore, we are talking about a limited subset of what I would call the universe.
Also, what if what we call a universe is one of many soccer balls (Imagine a ball bin in a store)? Are we still talking about each ball being the universe, I would think the bin is the universe then right? And if so, is it possible to break from one ball into another without doing damage to either ball?
I'm no theoretical astrophysicist, but I believe we need some better definitions about what we are actually talking about, cause really once you give way to possibility of a multiverse, you by definition no longer have a universe, since it means "everything" and therefore can only be one.
Just some thoughts.
proxy
Secondly to respond it being about Well yea, who says that the user should be able to? Keep in mind that if patchguard technology existed in Microsoft kernels since windows 95, people would have never complained, because once again...it is the kernel's job to prevent access to critical data structures to ensure system stability and reliability.
I am aware that IE has components that run in ring 0, my response is...so? IE still accesses this code through some sort of approved interface such as a system call or ioctl (this is a certainty as the hardware prevents all but a very few instructions from changing privilege levels downwards). Nothing about this fact contradicts my assertion that the kernel is supposed to be the only software which accesses these low level things and abstracts out interfaces for the rest of the software to utilize.
So basically you are saying that since it isn't an effective solution, it must be bad and/or not worth doing? That's ridiculous, I suppose you don't have an alarm system on your car either? It not like it doesn't take an experienced thief less that 30 seconds to shut it off and continue stealing your car. Car alarms are not 100% effective, but they are a deterrent, they add another level of difficulty and annoyance to the thief. Same principle applies here, it makes it more difficult and is better then not doing it at all.
Bottom line, lets say that it will stop just about half of the kernel level attacks starting in 2007. First of all, it will prevent all previous code from working, so all the malware that's out currently suddenly stops working, this is a good thing. Second of all, do you think that all future malware is going to have this patchguard bypass technology? odds are against it, maybe over time more and more will have the capability, but in the short term, let's say 50% again (probably being generous here). That is a significantly smaller amount of malware able to attack your system than before, so what's the problem?
Other AV vendors besides Mcafee and Symmantec have managed to port their AV technology to a patchguard enabled system, so it's not like you wont have any protection if something does get through.
I really fail to see the harm it putting up a defense like this.
proxy
sure it's not perfect, nothing is, but I find the effort of making patchguard a step in the right direction. Here's the thing, If it were possible to prevent anything but pre-approved code from running in kernel space, there would be basically no need for vendors to hook the kernel in the first place.
/dev/kmem which is a step in the right direction, but it's still not good enough.
Also, a lot of people are really talking it up about how Microsoft sucks and patchguard is just another flawed attempt at security by a company that doesn't know its ass from its elbow (or something to that nature)...but I haven't seen much if any effort by any of the other mainstream OSes to prevent kernel patching at all. It is downright trivial to write a Linux kernel module which hooks all sorts of critical data structures, same with FreeBSD and Solaris.
Is it the argument of the anti-patchguard people that if it can't be done perfectly, lets not even bother?
I guess the major driving point of my being a Microsoft apologist in this case is that, at least from an academic point of view, the kernel is supposed to be the only software which accesses these low level things and abstracts out interfaces for the rest of the software to utilize...the kernel shouldn't be exposing anything like direct disk access, or kernel space memory to user space....ever, under any circumstances. do that and things like rootkits are an awful lot harder to make in the first place.
Some Linux distros are starting to get the point by limiting and sometimes eliminating entirely access to
The way I see it, Microsoft may not be perfect, but at least they are trying.
proxy
While I understand what you trying to say, I have to disagree with some assumptions you have made. Why can't someone who wants things to be simple be tech-savvy?
Personally I'm a software engineer who deals mostly with kernel level development. I run linux because I like to have more control over how things work (one of your points I agreed with). But none of this means that I wouldn't want things to be simpler. Here's the thing, when a computer is designed such that that tasks you want to do are simpler to get done, you are more productive. Of course the tricky part is that everyone wants to do different things with their computers. So software designers tend to go with what most people want to do and make things like email, web browsing and word processing the easiest tasks to do.
I guess my point is, I see what you are saying, but tech savvy and wanting things easier/simpler are not mutually exclusive.
proxy
I've been reading some of the comments, and I feel that people are missing the point. Basically the main arguments I'm seeing is that Microsoft is making it hard for competitors to make their software and/or this does not remove the need for AV programs.
That's the not really the point, what people are missing is that the goal of patchguard technology is NOT to prevent infection, it does no work to prevent viruses/worms/trojans from getting on your system. What it DOES do is prevent this malware from patching code in the system and using rootkit technology to hide from your AV products and system admins.
Basically the idea is that they are trying to remove the ability for malware to hide within your system.
Microsoft is getting this one right for a change and it's about time. AV vendors have been resorting to unsupported and frankly unstable "dirty tricks" to get the job done, it's not Microsoft's fault that they stop allowing an unsupported feature to work, they never said it would ever work to begin with!
This is really no different than when Linux stopped exporting the sys_call_table symbol, it simply is not a good idea, nor is it considered "stable" to hook things like system calls at run-time. I'm not saying it doesn't work, I'm saying it's a kludge since there are all sorts of race conditions that are being introduced, in addition to the stability of the kernel as a whole being subverted due to no way good way of verifying that the hooking code doesn't make a mistake and crash the system.
Bottom line is that AV vendors should quit the whining. They will need to adapt to the fact that MS is actually taking security seriously.
proxy
This reminded me, I was having a discussion with a coworker a little bit ago about how I wished that all of the popular compression algorithms would be implemented with multiple thread capability (the ideal would be either the application detecting the number of CPUs, or possibly an environmental tuning capability similar to "make -jN"). I did notice that winrar has implemented multiple thread usage in the more recent releases and even on my hyper threaded CPU which is not a true multicore system it has a noticeable increase in performance.
When will we start seeing all of the common UNIX compression utilities taking advantage of the great CPU scalability that many UNIX implementations and Linux like to brag about?
proxy
Nero does exactly what you described. In the backup wizard, you simply select the files/directories you want backed up. It will then tell you how many CDs/DVDs it will take to store all of it. And you hit, go. it really is just as simple as you describe.
personally as a programmer, I tend to define a memory leak as memory which will be freed (until program termination, since all used pages should be returned to the OS then...), particularly through programmer error. For example i would not define the following as a memory leak though i would disagree with it's style:
/* do some work with array a */
int main() {
int *a = new int[10];
return 0;
}
while i personally would not write code like this and would consider it bad style, it is not really a "leak" because firstly, it is by design and secondly it does not "leak" more and more memory over time. Realistically what this article is talking about sounds more like caching to me, that is intentionally delaying freeing memory with the expectation that it may be used again in the near future. Considering that there is an upper limit on how much memory it will take up overall, this sounds like it would generally improve performance.
Now, should it be configurable, sure, on by default, sure.
In reality, I find a lot of computer users, usually non-programmers are very much obsessed with the notion that programs are bloated, and frankly, it's getting annoying. I continually see generally good programs on betanews get bad ratings because "it's too much of a memory hog" or "it's bloated" or "omg! it is taking 20 megs of memory".
While it is trivially true that if a program can be written smaller with no change in performance in functionality then it should be, it never seems to dawn on people that programs may be written to sacrifice memory for performance. Anyone familiar with optimization techniques will tell you bigger does NOT equal slower.
proxy
first and foremost, use good coding techniques. This means use exception handling where appropriate, use standard containers over hand rolled data structures (prefer std::string over char arrays, this will help prevent almost all common string based buffer overflows alone), and follow good style guidelines.
As for a GUI programming, if you are strictly tied to c++, i would recommend QT (www.trolltech.com) they have a fabulous API (takes getting used to, but it makes sense once you do). Nice part about QT is that it is source portable to just about every major platform (X11, Win32, Mac).
It is possible to write reliable, fault tolerate code in c++ (realize please that perfect code is impossible in any language), it just has to be well thought out and done right.
proxy
did anyone else notice that AE4 and AE11 appear to be the same bug?
AE4 reads:
"REP MOVS (Repeat/Move a string from one memory location to another) operation in fast string mode continues in that mode when crossing into a page with a different memory type."
AE4 was listed a show stopper.
AE11 reads:
"REP MOVS operation in fast string mode continues in that mode when crossing into a page with a different memory type."
AE11 was listed as Possible effect on performance, but no data loss or corruption.
First of all these seem identical short of the explaining the pneumonic for REP MOVS, secondly it is alarming that the two entries which seemingly identical descriptions got different severity ratings!
proxy
I agree with your comments for the most part, but I have a couple of points that I can't help but at least play devil's advocate with.
:( Ok, well there are a few solutions. #1 that comes to mind is do what java/c# do and have a VM, and/or forbid pointing to non-objects, or at least make it difficult (enter managed c++), this way at compile time assignment to pointers/references can be adjusted to also send a message to the GC thread to update it's refernce count on objects and such. But this can potentially kill performance and/or sacrifice the "systems programming" elements of c++. No Bueno. Another solution is use smart pointers, kinda the similar to the idea of only pointing to objects and such and emitting code to update gc data, but leaves it in the hands of the developer AND has the benefit of not needing a language level change, but instead is implemented in the library. The third thing I can think of off hand is a compromise like managed c++ where ordinary pointer use is forbidden except in blocked with a "#pragma unmanaged" or something, outside of such blocks, things like T *p = reinterpret_cast(0x12345678); would be illegal (hey why not make pretty much most casts illegal in a "managed" context?
.NET, QT, FOX? And if one, why? If we make a new one, are we shut out from using these others? Why? If we are not shut out, why have it? Personally I think that it would have been nice a while ago when GUIs were still up and coming, but at this point it is too late, there are too many options with too many different benefits to each to pick one. Also, should my command line c++ app need X libraries to run? this leads me to think it would have to be a compile time option. Regardless, I don't feel a single API for GUI is workable with the diverse set of features on todays desktops (should the GUI have a notion of a "window", what if my new special OS doesn't use "windows" to represent programs but instead using a whole new paradim?
"type deduction using the auto keyword.", I think that while this is a trivial feature to implement, it is being added for two simple purposes. firstly to shorten code: "std::vector::iterator" is quite a bit longer than "auto", sure we can typedef, but why should be have to. secondly to reduce need for modifying code when a container is changed. If i change from a vector to say a deque, they both support random access iterators, but until auto is supported, I'll have to at least update my typedefs, if not many lines of code which use iterators to access the container.
"No garbage collection.", ok, a garbage collection system is a reasonable request, at least it would be nice to have a compiler switch to enable it. But there is a problem, c++ opnly requires you to refer to objects using pointers, that is simply it's address. So how is the c++ language suppose to know at runtime that a pointer was just set to 0 and thus should have what it did point to freed? Or more annoyingly, we've got all sorts of pointers which point to all over the place, now we need reference counting and all sorts of voodoo. Also there is another problem, in c++ pointers dont have to point to a valid object, in java and other garbage collected languages, they don't usually use true pointers, but instead references to objects and such.
"no static virtual methods", OMG wanted these for a long time, good point
"the bias towards systems programming", I would beg to differ that it is being used nowhere for systems programming. There are several c++ development libraries for the windows kernel available along with MANY project OSes which intend to use modern language features to implement things in a new way, sure they will likely go unnoticed, but they still exist and we shouldn't take away from what they can do already.
"no standard GUI library." Tough call on this one, while it would be nice, this would destroy a lot of diversity in this field, I mean which API do we settle on?
"no way to get the size of an array allocated with operator new []
I am by no means trying to plug gentoo, but I did just noticed that they added a patch to version 1.5 in portage to address this issue (seems to cap titles in history to 65535 bytes.
I wonder if the gentoo team plans to submit their patch upstream to mozilla...
proxy
The solution to this problem is simple, if you don't want people to have access to your material, don't put it on the internet. Sure there will be a certain degree of piracy regarding these materials, but that would be far less widespread. Realistically, if you publish something on a website, well it's kinda just "out there" and if you expect people not to find it, or better yet, expect people not to still have it after you take it down, well you live in a fantasy world. IMHO everything on a legitimate website is fairgame for copying so long as the original authors are properly credited.
I suppose the issue really is with sites like the New York Times where they ask for a free membership to view their content and expect a certain amount of ad revenue from the viewers. And I am sure they will get annoyed when someone uses the NYT link generator (http://nytimes.blogspace.com/genlink) to access the site without logging in, or worse yet, mirrors the story on there own site (while crediting the original source of course). But I mean common, what did they expect to happen?
It's not that I don't think people have a right to control their content, but more that I think trying to enforce those rights is impossible. Get with the times people.
proxy
you make it sound like enforcing strict rules is a bad thing. Really the only bad thing that gcc has done is accept that _broken_ code in the past. The fact that it no longer will compile constructs which are invalid in c and c++ is an improvment. c and c++ are just like any other standard (think html/xhtml and such) and when a compiler accepts invalid constructs it destroys the portability of the code.
The true ideal is to be able to write code that if it compiles on gcc you can say "i know for certain that this is valid c++". Such a goal is difficult, if not impossible (many things are "implementation defined") but is stilla goal worth shooting for.
it seems to me that this is uneccessary and nvidia has proved it. The have "binary" drivers and supply there own open source layer to provide the glue between their code and the kernel. All we are really talking about is a small layer inbetween the kernel and the driver to provide a "stable" (as it unchanging) interface. So bottom line is that this is simply a wrapper for the existing API. Well, just do what nvidia does, make the code that interacts directly with the kernel open source and proivde the API you need, then just make your binary link to that and interact with just that. Works pretty well. Yes, it would be nice if this was standardized, and could possibly save some people a little bit of time, but thre actual gain seems to be minimal (i've written drivers for linux before, not THAT much changes from release to release as far as the code your module will use goes).
proxy
First of all, since when is default deny "seldom done" and "difficult?" That's just rediculous. Just about every firewall product out today has a deny by default policy. And it is by no means a difficult concept. "Allow what you need and no more, if you find that you need something that is blocked, decide if it is _really_ needed and if so allow it" wow that's too tought to wrap my head around!
Also, the author seems to be under the impression that perfect software is possible...well sorry, bad news, it's not.
His ideas on "Penetrate & Patch" being wrong are just silly. Yes, of course it's true that some systems are more secure by design than others, no argument there. But that has nothing to do with the penetrate and patch cycle. The point of P&P is that you assume your system isn't perfect (and gee, what a far fetched idea that is!) and try to see how it could be broken. No programmer can think of everything and there _will_ be holes. I have also found that many security issues that didn't come in white box testing (that is analizing the source code) did come up in fuzzing and other black box approaches. Sometimes these problems are a lot more difficult to spot in the code than one would hope. Also the fact that software has an issue doesn't make it insecure by design (it could be, but it is not neccessarily true). Many times it is due to incorrect implementation of a good design, or simply a minor coding error.
Also, his idea that "if FOO worked, we'd have run out of BAR type of security problem by now." Yea, that's also not the case. Perfect example, buffer overflows have been around for quite a while now and we still seem them all the time. Companies make a diligent effort to prevent them, and attackers just figure out more creative ways to make em happen. Problems don't go away over night (if ever) once they are discovered and addressed.
His thoughts on enumerating badness are also a little out of whack. Sure it's not a good idea to assume that everything you know if is everything that exists...but it's a damn good place to start! This is one of those things that isn't a great idea, but is an effective first line of defense. It's gauranteed not to catch everything, but it's a sure fire way to get those low hanging fruit while you can.
proxy