As my post stated, I was asking about the exception-handling performance changes mentioned in the write up.
It states:
"The cost of throwing an exception one level on a 990 MHz Intel Pentium is around 12-13 micro seconds in the plain GNU g++ implementation, which we reduced to 2.1 micro seconds by modifying the runtime library, including unwinding the stack in one phase, and caching information on exception paths. In contrast the cost of a trivial printk operation -- printk("Error\n") -- is 18 micro seconds."
Exception-handling changes relevant for g++?
on
C++ In The Linux kernel
·
· Score: 3, Interesting
Kernel aside, I wonder if G++ developers out there have any comments on these guys' exception-handling changes?
Would they be applicable to the user-space runtime?
Actually, there certainly are people with English, History, and Communications backgrounds who are skilled programmers.
I've also met folks with formal CS training who were dismal and unproductive software programmers.
Mathematics and algorithm-development skills are what they are, you have them or you don't. But natural ability and self-education are real factors in all fields.
I've been thinking about this way of doing things more and more since the appearance of Knoppix, FAI, Adios, and various cluster installation facilities--and clearly, so has Redhat.
Most importantly, this
1. avoids the absurdity of moving all processing, and indeed disk to a central server
2. focusses attention on development and maintenance of prototype installations for different types of machines
Some of the implementation techniques don't seem pleasant--but they're doing things in a way that appears forward-looking.
An architecture that wastes the power of the computers where the users are sitting, and overburdens some central computers where their apps run, and then puts every pixel on every screen in the company on the network wire, cannot be an appropriate solution to computer management problems.
There are nice properties to sharing an environment with others, and that's actually what I miss most about timesharing. I think you need something a lot more sophisticated than remote desktops to bring it back, though.
Funny, I have a hard time seeing how Java doesn't have as much openness as it needs, or how the open-source development world doesn't already have as much Java as it needs and wants.
I found the whole teleology of the argument very strange. Java has been a success story, not a failure for Sun, up to the present. It's already widely-adopted, and so would be around for decades even if it lost all momentum tomorrow. Finally, its target market and mindshare are with commercial developers and software producers, not open source programming communities-- it's not for the licensing a smaller percentage of those choose to work in Java. I found that claim almost disingenous.
But, no, the integrity of a dictionary depends upon the commitment of the editor to record actual usage--and never to "expose neologisms he [sic] likes."
The point is, that kind of editing is not description, but prescription. I'd like to see ESR give some thought to his scholarly responsibility in this instance.
Huh? This is indeed the rationale for releasing SAPDB under the GPL. But it's not new. SAPDB was open-sourced in 2000.
Ugly move, if true--current users had no warning
on
SAP and MySQL Join Forces
·
· Score: 4, Interesting
The SAP people have been utterly silent on the SAPDB list.
I guess that tends to confirm this story, though for myself (and this is the view expressed by everyone who's commented on the SAPDB list) I can't see how this works technically. The two systems are virtually nothing alike, for all they both speak SQL.
Worse, if true, this is far from the right way to treat the user community that has grown up around SAPDB. In that they found out about this in the Heise story--just like Slashdot.
Not nice.
For the past 2 years, it's seemed like there was a slow process of opening-up on the SAPDB list. The internal SAP developers finally this year provided external CVS access, and although they still seemed to value the fact that the code was difficult for non-SAP people to understand and work on--riddled with strange interfaces like COM migrated to Unix sans comments, and intentionally undocumented areas--I got the sense that things were improving.
For all the above, SAPDB as a project felt (perhaps due to its status as the less-known, more featureful GPL'd dbms) like a community resource that _came from_ a company, rather than like the property of a company you can download for free, which is how I've always seen mysql.
I still can't figure out what to feel about the vaporware merger of the systems, with development done by (yikes!) the Mysql folks, who a few years ago said we had no nead for transactions...
1. harder to install, with a slightly strange mix of admin tools (combination of old/crufty, and new/experimental)
2. definitely trickier to manage, as you need to learn protocols for setting up, and backing up, databases and their logs, at least. This is true of other RDBMSs of course, but the trend has been toward more self-managing systems.
3. Relies of ODBC as the cli--which is actually fine (eg, compatible with PHP) but still less familiar to Unix/OSS people
4. Still undergoing stabilizing bugfix cycle, seemingly, although I haven't myself ever encountered a problem with it
5. Is, as mentioned, less tolerant of inexpert admins--and more problematic, the error codes are frequently impossible to understand
6. Really is difficult, at present, to hack. In general, the code is VERY challenging to work with (particularly the ugly, custom built build system), although it should be said that the SAP internal developers are steadily improving all aspects of the system, and a time WILL come when external developers can see rewards for their hacking efforts.
Compensating for this is the VERY skilled and responsive SAPDB development team, and a very strong feature set.
I would say that Open Source products actually do lower barriers to entry in consulting services, in spite of IBM's current success selling them.
IBM relies on its premium reputation and size to deliver consulting at higher margins, and those are advantages that aren't going away, but they should slowly decline.
Herding the market into proprietary hardware solutions like Mainframe Linux fits Joel's model, but, this is condemned to be a niche-market, high-end strategy. IBM cannot transform a commoditized, PC computing market into a market for proprietary IBM hardware. Just ask Bill Gates.
Seems to me that, licensing aside, just becuase the rise of Linux isn't due _solely_ to Linux being free as in beer, free as in beer is one of the most important benefits of Linux, all the same.
If "Linux companies" have to redefine Linux as the same kind of single-giant-vendor software product that traditional OSes are, then there's no really good long-term reason for customers to adopt Linux.
I genuinely believe that Linux companies can learn to build business models that allow them to make a healthy profit, providing employment to the kinds of folks who have collaborated to create Linux in the first place, without turning Linux into the 21st Century equivalent of SCO Unix, complete with per-seat licensing.
How can they do this?
By slowly building the infrastructure for providing services that are good enough, and affordable enough, for businesses to WANT to buy them.
Every company that tries to figure out how to make a killing selling free software--by making it non-free--is first and foremost proposing nothing less than to rob free software of the very value it presents to users. But the proposal is a false grail and a phoney, in any case: consumers and the free software communities will avoid these commercialization attempts, I predict.
It seems to me that the only software vendors that can be harmed by the GPL are those making software that a bunch of hackers, cost-sharing companies, or community-minded individuals would be _willing_ to make for free.
Why should we keep paying for what some or all of us really would make--and already have made--for free?
Slashdot Mirror
I guess he could by lying.
I personally think Kerry's record shows that he has integrity, and that he'll at least try to keep this promise.
As my post stated, I was asking about the exception-handling performance changes mentioned in the write up.
It states:
"The cost of throwing an exception one level on a 990 MHz Intel Pentium is around 12-13 micro seconds in the plain GNU g++ implementation, which we reduced to 2.1 micro seconds by modifying the runtime library, including unwinding the stack in one phase, and caching information on exception paths. In contrast the cost of a trivial printk operation -- printk("Error\n") -- is 18 micro seconds."
Kernel aside, I wonder if G++ developers out there have any comments on these guys' exception-handling changes?
Would they be applicable to the user-space runtime?
The press release keeps talking about their addition of real-time features added to Linux--RTAI, RTLinux, MontaVista, etc, not mentioned.
What are the development, licensing, etc, issues here?
Actually, there certainly are people with English, History, and Communications backgrounds who are skilled programmers.
I've also met folks with formal CS training who were dismal and unproductive software programmers.
Mathematics and algorithm-development skills are what they are, you have them or you don't. But natural ability and self-education are real factors in all fields.
I've been thinking about this way of doing things more and more since the appearance of Knoppix, FAI, Adios, and various cluster installation facilities--and clearly, so has Redhat.
Most importantly, this
1. avoids the absurdity of moving all processing, and indeed disk to a central server
2. focusses attention on development and maintenance of prototype installations for different types of machines
Some of the implementation techniques don't seem pleasant--but they're doing things in a way that appears forward-looking.
I look forward to seeing more of this.
I sure that large IT companies would love it if they could remove all the smaller competitors.
I wonder if comporate consumers are ever motivated by price competition? Hmm...
Stinky stinky slow.
Not even remotely (so to speak), in my opinion.
An architecture that wastes the power of the computers where the users are sitting, and overburdens some central computers where their apps run, and then puts every pixel on every screen in the company on the network wire, cannot be an appropriate solution to computer management problems.
There are nice properties to sharing an environment with others, and that's actually what I miss most about timesharing. I think you need something a lot more sophisticated than remote desktops to bring it back, though.
Funny, I have a hard time seeing how Java doesn't have as much openness as it needs, or how the open-source development world doesn't already have as much Java as it needs and wants.
I found the whole teleology of the argument very strange. Java has been a success story, not a failure for Sun, up to the present. It's already widely-adopted, and so would be around for decades even if it lost all momentum tomorrow. Finally, its target market and mindshare are with commercial developers and software producers, not open source programming communities-- it's not for the licensing a smaller percentage of those choose to work in Java. I found that claim almost disingenous.
That doesn't make investing in Novell atop Linux a good investment.
This is the type of infrastructure functionality people should indeed be deploying on un-encumbered Linux, IMHO.
And gosh, if that provision also prevents customers from installing systems and supporting themselves, who cares, right?
Exactly. Thanks for this post.
What's a problem for me is the fact that as described in the license, it's a mandatory support contract.
That makes it effectively the same as the per-seat licensing people slammed Caldera for, doesn't it?
Why are Linux/Free Software advocates satisfied with that?
I agree with the plea for reasonableness.
But, no, the integrity of a dictionary depends upon the commitment of the editor to record actual usage--and never to "expose neologisms he [sic] likes."
The point is, that kind of editing is not description, but prescription. I'd like to see ESR give some thought to his scholarly responsibility in this instance.
Huh? This is indeed the rationale for releasing SAPDB under the GPL. But it's not new. SAPDB was open-sourced in 2000.
The SAP people have been utterly silent on the SAPDB list.
I guess that tends to confirm this story, though for myself (and this is the view expressed by everyone who's commented on the SAPDB list) I can't see how this works technically. The two systems are virtually nothing alike, for all they both speak SQL.
Worse, if true, this is far from the right way to treat the user community that has grown up around SAPDB. In that they found out about this in the Heise story--just like Slashdot.
Not nice.
For the past 2 years, it's seemed like there was a slow process of opening-up on the SAPDB list. The internal SAP developers finally this year provided external CVS access, and although they still seemed to value the fact that the code was difficult for non-SAP people to understand and work on--riddled with strange interfaces like COM migrated to Unix sans comments, and intentionally undocumented areas--I got the sense that things were improving.
For all the above, SAPDB as a project felt (perhaps due to its status as the less-known, more featureful GPL'd dbms) like a community resource that _came from_ a company, rather than like the property of a company you can download for free, which is how I've always seen mysql.
I still can't figure out what to feel about the vaporware merger of the systems, with development done by (yikes!) the Mysql folks, who a few years ago said we had no nead for transactions...
Designed to, and achieved, seem to be materially different, in this case?
I think reviews should address those questions.
I wonder if it is logical to describe "errors" on this scale in such euphemistic terms?
It is...
1. harder to install, with a slightly strange mix of admin tools (combination of old/crufty, and new/experimental)
2. definitely trickier to manage, as you need to learn protocols for setting up, and backing up, databases and their logs, at least. This is true of other RDBMSs of course, but the trend has been toward more self-managing systems.
3. Relies of ODBC as the cli--which is actually fine (eg, compatible with PHP) but still less familiar to Unix/OSS people
4. Still undergoing stabilizing bugfix cycle, seemingly, although I haven't myself ever encountered a problem with it
5. Is, as mentioned, less tolerant of inexpert admins--and more problematic, the error codes are frequently impossible to understand
6. Really is difficult, at present, to hack. In general, the code is VERY challenging to work with (particularly the ugly, custom built build system), although it should be said that the SAP internal developers are steadily improving all aspects of the system, and a time WILL come when external developers can see rewards for their hacking efforts.
Compensating for this is the VERY skilled and responsive SAPDB development team, and a very strong feature set.
I would say that Open Source products actually do lower barriers to entry in consulting services, in spite of IBM's current success selling them.
IBM relies on its premium reputation and size to deliver consulting at higher margins, and those are advantages that aren't going away, but they should slowly decline.
Herding the market into proprietary hardware solutions like Mainframe Linux fits Joel's model, but, this is condemned to be a niche-market, high-end strategy. IBM cannot transform a commoditized, PC computing market into a market for proprietary IBM hardware. Just ask Bill Gates.
Seems to me that, licensing aside, just becuase the rise of Linux isn't
due _solely_ to Linux being free as in beer, free as in beer is one of
the most important benefits of Linux, all the same.
If "Linux companies" have to redefine Linux as the same kind of
single-giant-vendor software product that traditional OSes are, then
there's no really good long-term reason for customers to adopt
Linux.
I genuinely believe that Linux companies can learn to build business
models that allow them to make a healthy profit, providing employment to
the kinds of folks who have collaborated to create Linux in the first
place, without turning Linux into the 21st Century equivalent of SCO
Unix, complete with per-seat licensing.
How can they do this?
By slowly building the infrastructure for providing services that are
good enough, and affordable enough, for businesses to WANT to buy them.
Every company that tries to figure out how to make a killing selling
free software--by making it non-free--is first and foremost proposing
nothing less than to rob free software of the very value it presents to
users. But the proposal is a false grail and a phoney, in any case:
consumers and the free software communities will avoid these
commercialization attempts, I predict.
It seems to me that the only software vendors that can be harmed by the GPL are those making software that a bunch of hackers, cost-sharing companies, or community-minded individuals would be _willing_ to make for free.
Why should we keep paying for what some or all of us really would make--and already have made--for free?
They could very well have used a non-proprietary core, as the original poster suggested.
I think in hindsight, that would have been a very sensible decision, don't you?