Like you said, 'almost' all. Many markets actually hold their suppliers to certain standards. I'm pretty sure NASA's software developers are held accountable, not that it has counts for much, what with their repeated incompetence. Still, I'm sure butts were liberally kicked.
Surely you jest. The vast majority of GUI CPU time on a typical GNOME box is spent in Pango. I dare you to profile it and prove me wrong. Pango puts in a lot of hard work, and most of it goes to waste. Now parts of GNOME are actually written in C# using Mono and Gtk#, giving you a couple of extra layers of failware. The work X.Org does is extremely minimal these days, especially when it uses hardware acceleration for some render tasks.
Smart scheduling is no competition for fast code, and KDE wins hard by using Qt. Even Swing with the (apparently proprietary) Java2D backend is much faster than GTK, even when GTK uses Cairo.
Look at 'top' and sort by total CPU time. X.Org will be one of the highest, but you have to remember it takes a chunk of everyone's CPU time and that persists even after they die. I'm sure if you add up all your other graphical programs, even the ones that are running just now and not counting the old ones, it'll be much higher than X.Org.
Precisely because it's so likely with Microsoft products. If they didn't disclaim it they'd be in serious trouble. Disclaiming doesn't make it a non-issue though.
With desktop environments like GNOME taking up more CPU time per user than all Google servers combined, a strong scheduler is desirable to make it at least sort-of tolerable. Although really, switching to KDE is known to have a much stronger positive effect.
I hope Novell escapes from this wiser and embraces freedom-based principles more. They have a lot of good employees and industry power, so the work they do can really make a difference in a struggle like this. They've chosen to be used as a counter-example instead, but I hope it results in a lesson learned and not a lot of careers ruined. Microsoft can market it to convince most people they're in the right, and somehow it's the FOSS people's fault. Novell can't really do that, so they have to issue a public apology for their devil worship, or continue their decline into the fiery pits of hell.
I think that even though GOTO itself is not necessarily such a bad thing, its current use in C is more of a hack now because C lacks some otherwise common *structured* constructs such as try..catch..finally. But my bigger problem with GOTO is that it's one of those things which completely and utterly destroys the ability to represent a program as a tree structure for possible branches, which keeps us even further from functional-like purity in C code.
GOTO is very rarely used in C++ where the pattern of relying on safe stack destructors (as a sort of 'finally') is wide-spread and well understood. It's downright forbidden in Java, which has solid garbage collection and an explicit 'finally', and therefore very little need for a specific GOTO. These features are much easier to reason about and understand than a GOTO C program which is basically just a self-traversing jump table.
Windows GUI drawing has been done on the DirectDraw pipeline for a very long time. The new backend is supposedly even better, but you can't claim DirectX doesn't have its share.
It's not that simple though. Linux needs a next generation of good coders, and tomorrow's good coders are pretty bad today. If their skills can be cultivated in the educational environment of Linux development, they'll stick with the project and eventually become good or even really good. If they'll never become really good, it'll probably show up as evidence too early to really matter.
It doesn't take a genius coder to implement a driver by a specification, or write then run some tests based on suggestions, but some experience will do. The really brilliant coders are where they belong, designing and implementing schedulers, device driver *architectures*, file systems, and so on. Some of the decent coders will move up to be brilliant. You won't know unless you invite them all in and sort them out later.
What? Okay, so C doesn't have built-in DbC, but it is trivial to add with macros and in fact has been done in every open Unix for many years. FreeBSD and Linux even have invariants for mutex usage correctness and detecting deadlocks, something that Eiffel cannot express without doing a lot more hackery than you would have to with C.
In my frequent Java work I get by just fine with its DbC, that is its type system, Eclipse' static analysis, 'final' keyword, and assertions. I can't remember the last time I had a non-trivial bug.
When I was forced into Eiffel work in uni, bugs were aplenty because of the braindead design of the base library, and extremely low-level language constructs. It doesn't even have any 'for' for chrissakes, you have to do a complete from..until..do..end, and manage things like iterators manually. I had to build higher and higher abstractions manually just to make at least some level of source moderately clean, even though I was repeating what should be the compiler's work. Java isn't *much* better in that regard, but still better, and with a lot more machine assistance from good IDEs.
I'm not saying C is a fantastic language, but it's the best-suited to the kind of work they're doing. There have been dozens of supposed C-killers, and no kernel devs have taken them up with any notable interest. And they're the ones really aching for a more expressive language, so they would know one when they see one.
"Generally, software from 1998 runs fine on Linux. I mean, if the source hasn't been updated since then, or you can get untouched source from 1998. Just build and run. It's not as if the X Windows framework, Qt, or GTK have changed so far that legacy apps don't work."
Not to be too picky, but Qt and GTK+ in fact have changed plenty. Qt is up to its 4th major version, and GTK+ is up to its second. Technically the GTK 1.x branch still exists, even if nobody willingly uses it.
*Binary* compatibility is better on BSDs though, which are not only conservative about ABI changes, but actually provide compat libraries to support old binaries, and even binaries from other operating systems. It's something I think a few Linux fellows should put some time into, although perhaps the "problem" isn't nearly as bad as some people like to pretend it is. I'd like Linux to have maximum interop with other systems, free and non-free alike, and it's a shame this kind of compatibility isn't prolific. But it's not like it regularly occurs to me to care either.
Fantastic, but my point is that if he's using AMD64, where 64-bit code really is at least as fast as 32-bit code, then 'long' really is quite large. This document indicates that "int" is 4 bytes and "long" is 8 bytes.
It's GNOME that's infected with Mono now, Ubuntu only inherits that from GNOME. So use Kubuntu, which is completely C/C++/Python with other small bits like Perl about the place. You should be using KDE anyway, GNOME doesn't have many useful advantages now, and is losing those few remaining advantages too.
And if the boycott leads to a mass migration away from Suse + Xandros + Linspire, that's all the more users (and developers developers developers) taking up the properly free distros and giving them mindshare and therefore power. It's not like people ditching Linspire for siding with Microsoft will move to Microsoft itself.
It bothers me too, but I've decided to think it's because at the time the decision was made, GNOME may have had some kind of advantage over KDE for the target market Mark had in mind, such as technophiles who fear power and elegance and just want something brutish that mostly works like their Windows does. It's not like KDE has had anything less than first-class support, it's just not the 'root' distribution. There could also be problems with KDE being based on Qt, but I highly doubt anyone really cares about that because it doesn't affect your use of KDE at all.
For an electrolysis you need electrons that will be added to or removed from a material. For an example of electroplating, a metal that is in an ionic bond with another substance will form a layer on another metal if it is torn away from its bond. Since you know exactly how many electrons are needed to add to the metal so it can break the ionic bond, you know exactly how many atoms of that metal will be freed by that number of electrons. And that's what I mean by a precise measure for that reaction.
The point of having a physical object is that it can be used as a root for calibrating devices. From there you can calibrate more devices on each other. The further you get, the less likely you are to be precise, but the chances are pretty good that little deviations up and down will cancel out overall. But it's absolutely important to have an exact starting point, and a physical object is the only way to do that.
It's a lot easier to measure a large object than a small one and multiply it, since a small error will also multiply out. What I don't get is how they intend to build an exact number of atoms into the sphere. You would need some other exact measurement, like number of electrons for calculating precise electrolysis procedures.
And if Office was licensed in a compatible license with OpenOffice, then Microsoft could pull just as much code back from OpenOffice. Whether or not they want to is a matter of debate. But they could also integrate many GPL code bases they couldn't previously use because of the copyleft nature of the GPL.
I repeat, I am not commenting on Paul at all, I am talking about how it is very natural to associate negative things with a person's words just based on a negative opinion of the person. And that could explain cases like this where people are off-put even when somebody agrees with them, based on other qualms they have with that person. Paul is the subject here, but that's not what I'm talking about at all. I hope that's clear on this revision.
Two words: associative bias. Just like how when people hear Microsoft say anything at all, they know it's actually to create more vendor lock-in and stifle competition. The words just feel dirty because you know what the person is thinking. I don't know the whole story about Paul, but if anyone is bitter towards him for whatever reasons, they'll be especially suspicious if he seems to agree with them. That's usually an enemy's best tactic, to seem like a friend and still serve their own interests. As soon as your interests clash with theirs, you're the one who gets screwed. Which is why you should probably just switch to Ubuntu now if you haven't already. Did I sidetrack there?
A Windows rewrite is impossible. It took Microsoft about 6 years just to go from XP to Vista, which was essentially just some extra restrictions and flashy graphics. Not even the most fundamental problems like coupling between the kernel and Command Prompt, or moronic path separators and drive lettering, were even sort of slightly fixed. Microsoft moves so incredibly slowly in their software development that if they started a Windows rewrite, they would never finish and Linux would cruise into world domination shortly.
So, yes, I would love to see Microsoft attempt a Windows rewrite from the ground up. That's just what the world needs right now.
Have you filed the bug report? Anyway, what does that have to do with anything I said? Engineering a good format is not the same as supporting it well.
Precisely right - the transparency of XML is pretty much its only strength. But that also means anyone with an XML parser and a glance at their file can systematically read out the contents. If there was an open binary format, eventually there would be some implementations that should be even easier than using an XML parser. Let's not bring OOXML into this though, it's clear that's just wrapping all of the proprietary Office garbage in an XML container and claiming it's now open.
Microsoft have an incredible track record of failing to engineer good XML formats. Take a look at the formats of Kopete chat logs versus Windows Live Messenger. Kopete stores the same data in a much, much, much more compact way. The WLM format is so insane that it uses elements for things that are very clearly attributes (i.e. defined exactly once per parent element, with a limited type like a date). It's a joke. I couldn't do worse if I tried. I don't want the same kind of brutal stupidity governing my documents, open or proprietary, binary or markup.
Worth noting is that an open format is still preferable to a closed but fast format. At least with the open format, all of the data is there, so you can pay the CPU time to do a conversion to a fast format (whatever that may be, relevant for what you're doing).
I think the confusion is that ODF, etc. are meant to *keep* the data in a way that is unlikely to ever be unsupported. A fast binary format may be far too heavily engineered to easily tell what it is without looking at implementation source code or very good documentation. XML, for all of its efficiency faults, can be extremely clear even to the human eye, especially when coupled with a good schema definition. And I severely doubt that there will ever exist a Unix platform that doesn't have the venerable deflate algorithm aboard.
So the format does exactly what it should: it makes it abundantly clear what's contained within, in a way that can *trivially* be parsed out with any compliant XML library. A fast format can follow along after that, and as long as both of them are open, there is fundamentally no problem with supporting both of them widely. Users shouldn't even have to care which format they save in, because both of them would be supported. One would just happen to be easier to support in code. The other would need a special library for it, but then that's open too. There's really no problem there that can compare with the current situation of having Office documents of varying and fantastically terrible formats.
It takes you an hour? With Python and SQLAlchemy I can have a database abstraction with connection pooling and ORM in about 20 lines of absurdly simple code, more if the schema is beefy. Then I can tack on a neat PyGTK, PyQT, or whatever other GUI in another page or so, using a visual designer like Glade or Qt Designer. Or I could make a web application interface with CherryPy or Twisted Web and any of the dozens of elegant HTML templating kits. Overall this is a 15 minute job at most, and that's including revising the APIs if needed. And apart from using a visual designer for the GUI, this can all be done with a neat text editor like Vim or Emacs, no need for gigabytes of proprietary vendor-lockin crap. You don't need Intellisense much if the intelligence is in the design.
And then there's Ruby on Rails which does almost all of *that* for you, leaving very little work for you to do. You can get the entire open source stack in a single archive for Windows, called InstantRails, and there are plugins for Eclipse to integrate in that too.
Visual Studio might seem really good if you only ever read marketing hype. But once you get in the trenches and try real platforms with real development environments, the reality is entirely different.
Slashdot Mirror
Like you said, 'almost' all. Many markets actually hold their suppliers to certain standards. I'm pretty sure NASA's software developers are held accountable, not that it has counts for much, what with their repeated incompetence. Still, I'm sure butts were liberally kicked.
Surely you jest. The vast majority of GUI CPU time on a typical GNOME box is spent in Pango. I dare you to profile it and prove me wrong. Pango puts in a lot of hard work, and most of it goes to waste. Now parts of GNOME are actually written in C# using Mono and Gtk#, giving you a couple of extra layers of failware. The work X.Org does is extremely minimal these days, especially when it uses hardware acceleration for some render tasks.
Smart scheduling is no competition for fast code, and KDE wins hard by using Qt. Even Swing with the (apparently proprietary) Java2D backend is much faster than GTK, even when GTK uses Cairo.
Look at 'top' and sort by total CPU time. X.Org will be one of the highest, but you have to remember it takes a chunk of everyone's CPU time and that persists even after they die. I'm sure if you add up all your other graphical programs, even the ones that are running just now and not counting the old ones, it'll be much higher than X.Org.
Precisely because it's so likely with Microsoft products. If they didn't disclaim it they'd be in serious trouble. Disclaiming doesn't make it a non-issue though.
With desktop environments like GNOME taking up more CPU time per user than all Google servers combined, a strong scheduler is desirable to make it at least sort-of tolerable. Although really, switching to KDE is known to have a much stronger positive effect.
I hope Novell escapes from this wiser and embraces freedom-based principles more. They have a lot of good employees and industry power, so the work they do can really make a difference in a struggle like this. They've chosen to be used as a counter-example instead, but I hope it results in a lesson learned and not a lot of careers ruined. Microsoft can market it to convince most people they're in the right, and somehow it's the FOSS people's fault. Novell can't really do that, so they have to issue a public apology for their devil worship, or continue their decline into the fiery pits of hell.
I think that even though GOTO itself is not necessarily such a bad thing, its current use in C is more of a hack now because C lacks some otherwise common *structured* constructs such as try..catch..finally. But my bigger problem with GOTO is that it's one of those things which completely and utterly destroys the ability to represent a program as a tree structure for possible branches, which keeps us even further from functional-like purity in C code.
GOTO is very rarely used in C++ where the pattern of relying on safe stack destructors (as a sort of 'finally') is wide-spread and well understood. It's downright forbidden in Java, which has solid garbage collection and an explicit 'finally', and therefore very little need for a specific GOTO. These features are much easier to reason about and understand than a GOTO C program which is basically just a self-traversing jump table.
Windows GUI drawing has been done on the DirectDraw pipeline for a very long time. The new backend is supposedly even better, but you can't claim DirectX doesn't have its share.
It's not that simple though. Linux needs a next generation of good coders, and tomorrow's good coders are pretty bad today. If their skills can be cultivated in the educational environment of Linux development, they'll stick with the project and eventually become good or even really good. If they'll never become really good, it'll probably show up as evidence too early to really matter.
It doesn't take a genius coder to implement a driver by a specification, or write then run some tests based on suggestions, but some experience will do. The really brilliant coders are where they belong, designing and implementing schedulers, device driver *architectures*, file systems, and so on. Some of the decent coders will move up to be brilliant. You won't know unless you invite them all in and sort them out later.
What? Okay, so C doesn't have built-in DbC, but it is trivial to add with macros and in fact has been done in every open Unix for many years. FreeBSD and Linux even have invariants for mutex usage correctness and detecting deadlocks, something that Eiffel cannot express without doing a lot more hackery than you would have to with C.
In my frequent Java work I get by just fine with its DbC, that is its type system, Eclipse' static analysis, 'final' keyword, and assertions. I can't remember the last time I had a non-trivial bug.
When I was forced into Eiffel work in uni, bugs were aplenty because of the braindead design of the base library, and extremely low-level language constructs. It doesn't even have any 'for' for chrissakes, you have to do a complete from..until..do..end, and manage things like iterators manually. I had to build higher and higher abstractions manually just to make at least some level of source moderately clean, even though I was repeating what should be the compiler's work. Java isn't *much* better in that regard, but still better, and with a lot more machine assistance from good IDEs.
I'm not saying C is a fantastic language, but it's the best-suited to the kind of work they're doing. There have been dozens of supposed C-killers, and no kernel devs have taken them up with any notable interest. And they're the ones really aching for a more expressive language, so they would know one when they see one.
"Generally, software from 1998 runs fine on Linux. I mean, if the source hasn't been updated since then, or you can get untouched source from 1998. Just build and run. It's not as if the X Windows framework, Qt, or GTK have changed so far that legacy apps don't work."
Not to be too picky, but Qt and GTK+ in fact have changed plenty. Qt is up to its 4th major version, and GTK+ is up to its second. Technically the GTK 1.x branch still exists, even if nobody willingly uses it.
*Binary* compatibility is better on BSDs though, which are not only conservative about ABI changes, but actually provide compat libraries to support old binaries, and even binaries from other operating systems. It's something I think a few Linux fellows should put some time into, although perhaps the "problem" isn't nearly as bad as some people like to pretend it is. I'd like Linux to have maximum interop with other systems, free and non-free alike, and it's a shame this kind of compatibility isn't prolific. But it's not like it regularly occurs to me to care either.
Fantastic, but my point is that if he's using AMD64, where 64-bit code really is at least as fast as 32-bit code, then 'long' really is quite large. This document indicates that "int" is 4 bytes and "long" is 8 bytes.
Try again on a CPU architecture that isn't from the stone age.
It's GNOME that's infected with Mono now, Ubuntu only inherits that from GNOME. So use Kubuntu, which is completely C/C++/Python with other small bits like Perl about the place. You should be using KDE anyway, GNOME doesn't have many useful advantages now, and is losing those few remaining advantages too.
And if the boycott leads to a mass migration away from Suse + Xandros + Linspire, that's all the more users (and developers developers developers) taking up the properly free distros and giving them mindshare and therefore power. It's not like people ditching Linspire for siding with Microsoft will move to Microsoft itself.
It bothers me too, but I've decided to think it's because at the time the decision was made, GNOME may have had some kind of advantage over KDE for the target market Mark had in mind, such as technophiles who fear power and elegance and just want something brutish that mostly works like their Windows does. It's not like KDE has had anything less than first-class support, it's just not the 'root' distribution. There could also be problems with KDE being based on Qt, but I highly doubt anyone really cares about that because it doesn't affect your use of KDE at all.
For an electrolysis you need electrons that will be added to or removed from a material. For an example of electroplating, a metal that is in an ionic bond with another substance will form a layer on another metal if it is torn away from its bond. Since you know exactly how many electrons are needed to add to the metal so it can break the ionic bond, you know exactly how many atoms of that metal will be freed by that number of electrons. And that's what I mean by a precise measure for that reaction.
The point of having a physical object is that it can be used as a root for calibrating devices. From there you can calibrate more devices on each other. The further you get, the less likely you are to be precise, but the chances are pretty good that little deviations up and down will cancel out overall. But it's absolutely important to have an exact starting point, and a physical object is the only way to do that.
It's a lot easier to measure a large object than a small one and multiply it, since a small error will also multiply out. What I don't get is how they intend to build an exact number of atoms into the sphere. You would need some other exact measurement, like number of electrons for calculating precise electrolysis procedures.
And if Office was licensed in a compatible license with OpenOffice, then Microsoft could pull just as much code back from OpenOffice. Whether or not they want to is a matter of debate. But they could also integrate many GPL code bases they couldn't previously use because of the copyleft nature of the GPL.
I repeat, I am not commenting on Paul at all, I am talking about how it is very natural to associate negative things with a person's words just based on a negative opinion of the person. And that could explain cases like this where people are off-put even when somebody agrees with them, based on other qualms they have with that person. Paul is the subject here, but that's not what I'm talking about at all. I hope that's clear on this revision.
Two words: associative bias. Just like how when people hear Microsoft say anything at all, they know it's actually to create more vendor lock-in and stifle competition. The words just feel dirty because you know what the person is thinking. I don't know the whole story about Paul, but if anyone is bitter towards him for whatever reasons, they'll be especially suspicious if he seems to agree with them. That's usually an enemy's best tactic, to seem like a friend and still serve their own interests. As soon as your interests clash with theirs, you're the one who gets screwed. Which is why you should probably just switch to Ubuntu now if you haven't already. Did I sidetrack there?
A Windows rewrite is impossible. It took Microsoft about 6 years just to go from XP to Vista, which was essentially just some extra restrictions and flashy graphics. Not even the most fundamental problems like coupling between the kernel and Command Prompt, or moronic path separators and drive lettering, were even sort of slightly fixed. Microsoft moves so incredibly slowly in their software development that if they started a Windows rewrite, they would never finish and Linux would cruise into world domination shortly.
So, yes, I would love to see Microsoft attempt a Windows rewrite from the ground up. That's just what the world needs right now.
Have you filed the bug report? Anyway, what does that have to do with anything I said? Engineering a good format is not the same as supporting it well.
Precisely right - the transparency of XML is pretty much its only strength. But that also means anyone with an XML parser and a glance at their file can systematically read out the contents. If there was an open binary format, eventually there would be some implementations that should be even easier than using an XML parser. Let's not bring OOXML into this though, it's clear that's just wrapping all of the proprietary Office garbage in an XML container and claiming it's now open.
Microsoft have an incredible track record of failing to engineer good XML formats. Take a look at the formats of Kopete chat logs versus Windows Live Messenger. Kopete stores the same data in a much, much, much more compact way. The WLM format is so insane that it uses elements for things that are very clearly attributes (i.e. defined exactly once per parent element, with a limited type like a date). It's a joke. I couldn't do worse if I tried. I don't want the same kind of brutal stupidity governing my documents, open or proprietary, binary or markup.
Worth noting is that an open format is still preferable to a closed but fast format. At least with the open format, all of the data is there, so you can pay the CPU time to do a conversion to a fast format (whatever that may be, relevant for what you're doing).
I think the confusion is that ODF, etc. are meant to *keep* the data in a way that is unlikely to ever be unsupported. A fast binary format may be far too heavily engineered to easily tell what it is without looking at implementation source code or very good documentation. XML, for all of its efficiency faults, can be extremely clear even to the human eye, especially when coupled with a good schema definition. And I severely doubt that there will ever exist a Unix platform that doesn't have the venerable deflate algorithm aboard.
So the format does exactly what it should: it makes it abundantly clear what's contained within, in a way that can *trivially* be parsed out with any compliant XML library. A fast format can follow along after that, and as long as both of them are open, there is fundamentally no problem with supporting both of them widely. Users shouldn't even have to care which format they save in, because both of them would be supported. One would just happen to be easier to support in code. The other would need a special library for it, but then that's open too. There's really no problem there that can compare with the current situation of having Office documents of varying and fantastically terrible formats.
It takes you an hour? With Python and SQLAlchemy I can have a database abstraction with connection pooling and ORM in about 20 lines of absurdly simple code, more if the schema is beefy. Then I can tack on a neat PyGTK, PyQT, or whatever other GUI in another page or so, using a visual designer like Glade or Qt Designer. Or I could make a web application interface with CherryPy or Twisted Web and any of the dozens of elegant HTML templating kits. Overall this is a 15 minute job at most, and that's including revising the APIs if needed. And apart from using a visual designer for the GUI, this can all be done with a neat text editor like Vim or Emacs, no need for gigabytes of proprietary vendor-lockin crap. You don't need Intellisense much if the intelligence is in the design.
And then there's Ruby on Rails which does almost all of *that* for you, leaving very little work for you to do. You can get the entire open source stack in a single archive for Windows, called InstantRails, and there are plugins for Eclipse to integrate in that too.
Visual Studio might seem really good if you only ever read marketing hype. But once you get in the trenches and try real platforms with real development environments, the reality is entirely different.