Inkscape uses libnr, its own rendering engine (which is actually responsible for 95% of rendering-related issues and awful performance in some edge cases), but they plan on moving to Cairo sometime soon. The good thing with Inkscape is that by some miracle it works well most of the time. The bad thing is that the code is mostly shit. There are at least 3 layers of cruft in some parts of the codebase, and although the language is C++, some 60% of the code is still plain C. There is a lot of duplicated code that performs differently but does essentially the same, like import and paste. However, they're improving quite fast on that front - 0.47 is meant to be centered on refactoring.
(BTW I dug a bit into Inkscape code to fix the clipboard, so I know what I'm talking)
My experience with Visual Studio Express (on a rather underpowered Sharp Mebius with 256MB of RAM and P3 866) was OMG BLOAT WTF. Also, the install and uninstall are ungodly long (I had the impression that Ubuntu installs faster - and that's a whole OS!). On the other hand, Code::Blocks worked quite well. Recently I'm using gedit, because CB doesn't play well with Autotools, and Anjuta crashes when I try to import the Inkscape directory into it.
Ah but nuclear power is polluting. Nuclear power pollutes from the ground to the ground, cradle to cradle. Huh? That's a 1986-style Greenpeace mantra. Nuclear power is not polluting unless someone very, very seriously screws up. It's like saying that airplanes kill civilians and destroy buildings.
Open source drivers are actually better than published specifications, because they are easily verifiable - they either work or don't work. Specifications can be obscure, contain errors or omit important subtleties, and you can't test that any other way than implementing the driver using these specs. There is also the added fun of hardware bugs...
Ideally, a vendor should both provide specs and assist the people developing the Linux driver, as AMD does with its graphics cards.
Vista will sell because it is forced onto unwilling customers. In Poland you almost can't buy a laptop without Vista, except budget-end ones that sometimes run "Linux" (no mention of the distro), but the more disturbing thing is that your warranty is void if you replace the OS. This means if you want to downgrade to XP you're royally screwed, because warranty is the main reason people buy in stores instead of e.g. on auction sites.
a lot of the reason computers have been able to advance as quickly as they have is because we have a single majority platform Incoming Bullshit Alert...
There are some obstacles to implementing these changes: 1. FOSS fundamentalism - "MP3 codecs and DeCSS are unclean, so let's make it harder to use them". I think Medibuntu should be optionally enabled, and the important components (DeCSS, restricted codecs etc.) automatically pulled in, at installation. There could also be a checklist of what the user wants to install (MP3, DVD, encrypted DVD...) with explanation of the legal implications. 2. Windows users which think Add/Remove programs means Remove programs (because in Windows you can't Add any programs via this menu...). This, however, can be countered by having a package manager advertised properly. 3. Windows way of installing programs by downloading them from websites. The users end up downloading the source and trying to compile it, and fail miserably (I have seen this personally with my brother trying to install Kadu). There should be something discouraging this mode of action. 4. Usability testing spoils a test subject. You need to find new ones every time, because they gain experience the first time they test. 5. Once Ubuntu is loaded with pretty wizards, no developers will use it ("build a system that an idiot can use, and only an idiot will want to use it"). There should be an "expert" mode which turns off all introductory wizards.
From what I see Ubuntu is currently catering to its expected target demographic (medium-level geeks). Because of this, there's PulseAudio, which allows one to route sound over LAN, but no MP3 playback, because it requires something unclean.
Chernobyl was not a design flaw, it was a giant procedural flaw. Generally they had incompetent people on a graveyard shift running a risky experiment with disregard for safety procedures.
RBMKs used in Chernobyl are less inherently safe than other designs, but their goal was not safety. The two core features of RBMK reactors used in Chernobyl are that: 1. It can run on natural uranium. 2. It can be used to produce plutonium. It made perfect sense to use such a reactor during the cold war.
C# is not a new version of C++. It is something completely different with a familiar name slapped on it to confuse the unwary.
* C# is compiled to bytecode while C++ is compiled to native code. * C# has no multiple inheritance. * C# has no global functions or variables, everything must be in some class like in Java. * C# has no explicit memory management, though it has deterministic finalization, so RAII is possible. * C# has rather limited operator overloading. * C# distinguishes between reference types and value types. C++ has no such distinction, though the difference between an object and a pointer to an object is similar. * C#'s preprocessor is very limited (no macros). * C# has generics which are a dumbed-down version of C++ templates. etc., etc... * C# has switch on strings, while C++ has switch only on integer types. * In C#, code like int bar = 1; if(bar) {...} is invalid because there is no coercion of integers to booleans. * C# requires special gymnastics to use pointers. etc., etc...
So C# is actually more an extension of Java than a new version of C++.
- C++ has no built-in garbage collector. However, you have multiple options: smart pointers + RAII, garbage collector library, your own GC implementation... - Java has a built-in garbage collector. However, explicit memory management is impossible, and the lack of destructors and scoped objects is very inconvenient at times. This leads to acquireResource() - releaseResource() style coding - something which should be long gone.
The main problems are: 1. People tend to learn the syntax only, and when the syntax doesn't directly provide what they need, they moan and look for another language instead of looking for appropriate libraries. 2. People are anxious about doing the Wrong Thing, so if there is no officially blessed way to do something they won't do it at all so that they won't have to take the blame later.
Java is a rather dumb language, but at the same time this makes it very attractive for enterprise development. Dumb languages can enable poor programmers to produce working code, while they don't obstruct good programmers too often.
I don't see C++ or C going anywhere when it comes to performance-critical apps and low-level stuff like web servers, databases, OS kernels, device drivers etc., but it will decline in the enterprise.
@ SatanicPuppy: C++ is actually relatively easy to multi-thread, because you can use RAII to lock critical sections and mutexes, so you can't forget to unlock them - the compiler does it for you when the lock falls out of scope. Java on the other hand requires you to manually unlock everything because there are no destructors or scoped objects. Parallel processing is inherently complex, so no language is going to magically make it easy.
Developing a drug costs a lot of money and time. However, making a drug in ample quantites and distributing it for free to people costs even more money.
Developing useful software costs a lot of money and/or time. However, making copies of software in ample quantities and distributing them for free to people costs exactly nothing.
I would expect that Bill G. would at the very least be able to discriminate between tangible and intangible (intellectual) property. His drug analogy is weak at best.
The sentence about GPL preventing software from being improved is actually a very old MS smokescreen tactic: when MS does something wrong, they immediately find an entity that can pose a threat to them and accuse them of exactly the same wrongdoing. Otherwise, it's blatantly wrong and stupid; I don't believe he's being serious. I can't even come up with a good example to the contrary because of this sentence's overwhelming disjunction with reality.
OOXML is not MS Office 2007 format. OO.o is implementing the MS Office 2007 format, not OOXML. (Sure, they are similar, but MS Office 2007 uses many deprecated OOXML features, which conforming OOXML applications should not use).
OOXML has no major "producers", so it's rather worthless to implement right now. Office 2007 format is more interesting.
I believe at least some versions of Linux have adress space randomization turned on by default, so it's generally not possible to know where system() is beforehand.
Slashdot Mirror
Inkscape uses libnr, its own rendering engine (which is actually responsible for 95% of rendering-related issues and awful performance in some edge cases), but they plan on moving to Cairo sometime soon.
The good thing with Inkscape is that by some miracle it works well most of the time. The bad thing is that the code is mostly shit. There are at least 3 layers of cruft in some parts of the codebase, and although the language is C++, some 60% of the code is still plain C. There is a lot of duplicated code that performs differently but does essentially the same, like import and paste. However, they're improving quite fast on that front - 0.47 is meant to be centered on refactoring.
(BTW I dug a bit into Inkscape code to fix the clipboard, so I know what I'm talking)
My experience with Visual Studio Express (on a rather underpowered Sharp Mebius with 256MB of RAM and P3 866) was OMG BLOAT WTF. Also, the install and uninstall are ungodly long (I had the impression that Ubuntu installs faster - and that's a whole OS!). On the other hand, Code::Blocks worked quite well. Recently I'm using gedit, because CB doesn't play well with Autotools, and Anjuta crashes when I try to import the Inkscape directory into it.
Well, there are nuclear ice breakers and subs, so maybe nuclear freighters and passengers boats are next?
Open source drivers are actually better than published specifications, because they are easily verifiable - they either work or don't work. Specifications can be obscure, contain errors or omit important subtleties, and you can't test that any other way than implementing the driver using these specs. There is also the added fun of hardware bugs...
Ideally, a vendor should both provide specs and assist the people developing the Linux driver, as AMD does with its graphics cards.
Vista will sell because it is forced onto unwilling customers. In Poland you almost can't buy a laptop without Vista, except budget-end ones that sometimes run "Linux" (no mention of the distro), but the more disturbing thing is that your warranty is void if you replace the OS. This means if you want to downgrade to XP you're royally screwed, because warranty is the main reason people buy in stores instead of e.g. on auction sites.
There are some obstacles to implementing these changes:
1. FOSS fundamentalism - "MP3 codecs and DeCSS are unclean, so let's make it harder to use them". I think Medibuntu should be optionally enabled, and the important components (DeCSS, restricted codecs etc.) automatically pulled in, at installation. There could also be a checklist of what the user wants to install (MP3, DVD, encrypted DVD...) with explanation of the legal implications.
2. Windows users which think Add/Remove programs means Remove programs (because in Windows you can't Add any programs via this menu...). This, however, can be countered by having a package manager advertised properly.
3. Windows way of installing programs by downloading them from websites. The users end up downloading the source and trying to compile it, and fail miserably (I have seen this personally with my brother trying to install Kadu). There should be something discouraging this mode of action.
4. Usability testing spoils a test subject. You need to find new ones every time, because they gain experience the first time they test.
5. Once Ubuntu is loaded with pretty wizards, no developers will use it ("build a system that an idiot can use, and only an idiot will want to use it"). There should be an "expert" mode which turns off all introductory wizards.
From what I see Ubuntu is currently catering to its expected target demographic (medium-level geeks). Because of this, there's PulseAudio, which allows one to route sound over LAN, but no MP3 playback, because it requires something unclean.
Chernobyl was not a design flaw, it was a giant procedural flaw. Generally they had incompetent people on a graveyard shift running a risky experiment with disregard for safety procedures.
RBMKs used in Chernobyl are less inherently safe than other designs, but their goal was not safety. The two core features of RBMK reactors used in Chernobyl are that:
1. It can run on natural uranium.
2. It can be used to produce plutonium.
It made perfect sense to use such a reactor during the cold war.
C# is not a new version of C++. It is something completely different with a familiar name slapped on it to confuse the unwary.
* C# is compiled to bytecode while C++ is compiled to native code.
* C# has no multiple inheritance.
* C# has no global functions or variables, everything must be in some class like in Java.
* C# has no explicit memory management, though it has deterministic finalization, so RAII is possible.
* C# has rather limited operator overloading.
* C# distinguishes between reference types and value types. C++ has no such distinction, though the difference between an object and a pointer to an object is similar.
* C#'s preprocessor is very limited (no macros).
* C# has generics which are a dumbed-down version of C++ templates.
etc., etc...
* C# has switch on strings, while C++ has switch only on integer types.
* In C#, code like int bar = 1; if(bar) {...} is invalid because there is no coercion of integers to booleans.
* C# requires special gymnastics to use pointers.
etc., etc...
So C# is actually more an extension of Java than a new version of C++.
I think C++ is better than Java. Why?
- C++ has no built-in garbage collector. However, you have multiple options: smart pointers + RAII, garbage collector library, your own GC implementation...
- Java has a built-in garbage collector. However, explicit memory management is impossible, and the lack of destructors and scoped objects is very inconvenient at times. This leads to acquireResource() - releaseResource() style coding - something which should be long gone.
The main problems are:
1. People tend to learn the syntax only, and when the syntax doesn't directly provide what they need, they moan and look for another language instead of looking for appropriate libraries.
2. People are anxious about doing the Wrong Thing, so if there is no officially blessed way to do something they won't do it at all so that they won't have to take the blame later.
Java is a rather dumb language, but at the same time this makes it very attractive for enterprise development. Dumb languages can enable poor programmers to produce working code, while they don't obstruct good programmers too often.
I don't see C++ or C going anywhere when it comes to performance-critical apps and low-level stuff like web servers, databases, OS kernels, device drivers etc., but it will decline in the enterprise.
@ SatanicPuppy:
C++ is actually relatively easy to multi-thread, because you can use RAII to lock critical sections and mutexes, so you can't forget to unlock them - the compiler does it for you when the lock falls out of scope. Java on the other hand requires you to manually unlock everything because there are no destructors or scoped objects. Parallel processing is inherently complex, so no language is going to magically make it easy.
Developing a drug costs a lot of money and time. However, making a drug in ample quantites and distributing it for free to people costs even more money. Developing useful software costs a lot of money and/or time. However, making copies of software in ample quantities and distributing them for free to people costs exactly nothing. I would expect that Bill G. would at the very least be able to discriminate between tangible and intangible (intellectual) property. His drug analogy is weak at best. The sentence about GPL preventing software from being improved is actually a very old MS smokescreen tactic: when MS does something wrong, they immediately find an entity that can pose a threat to them and accuse them of exactly the same wrongdoing. Otherwise, it's blatantly wrong and stupid; I don't believe he's being serious. I can't even come up with a good example to the contrary because of this sentence's overwhelming disjunction with reality.
OOXML is not MS Office 2007 format. OO.o is implementing the MS Office 2007 format, not OOXML. (Sure, they are similar, but MS Office 2007 uses many deprecated OOXML features, which conforming OOXML applications should not use). OOXML has no major "producers", so it's rather worthless to implement right now. Office 2007 format is more interesting.
I believe at least some versions of Linux have adress space randomization turned on by default, so it's generally not possible to know where system() is beforehand.