There are a number of dynamic cache products
that are developed just to solve your problem
- from WARP Solutions (warpsolutions.com)
just to name one. It's a much lower risk solution
than to wholesale drop all your technology investment
and replace it that could be just as bad, or worse!
Because a lot of their code can have buffer overruns due to the lack (or precieved lack) of this function by their own programmers. Makes it easy to create insecure programs and harder to create secure ones.
I just ported a large amount of code to windows, and I was very surprised to notice that snprintf() is _snprintf() on windows. It's like they hid it (or implemented it much later) and it's not part of "their" standard. Without widespread use of this function, god knows how many lines of their code uses regular sprintf() and insecure functions like it. And I doubt they use "%13s" or directives like this in sprintf(), or if their version even supports these constructs.
Don't know. Haven't used it. Can you use VS for compiling and something else for editing, for example? As for the infrastructure (.net) in general. I think it can interoperate well using XML, so that part isn't an issue unless MS starts "proprietarizing" XML protocols.
The subject says it all. Don't push your thing onto developers. Just publish it. If it's any good, people will use it. Sourceforge.net is one place to do it. Design your tool in an OO and component-oriented way, so people can mix-and-match your tool with others they are used to.
The biggest mistake you can make is to develop a monolithic "infrastructure" that can't be used interchangably with other pieces and is required for all further development. Noone is going to use that.
Publish small components, each of which do a single job really, really well, and then integrate them in a component-oriented fashion.
Good Luck!
Does anybody know whether Borland tools (new or old) are ABI compaible with MS' tools, especially for C++ (unmanaged) i.e. do C++ libs compiled with VS.Net work with Borland's tools/applications?
While it's true that wireless gear doesn't affect the avionics on most modern aircraft, and most digital networks nowdays aren't susseptible to "multiple-cell-from-altitude" degradation, you won't be able to use a wireless phone from more than about 18,000 feet. You just won't get any receptions b/c radio signals from wireless stations don't go that high up.
RogueWave SourcePro is an excellent product, highly recommended (although a bit expensive) They support connection pooling, threads, completely DB-agnostic & runtime DB back-end switching, Envelope-Letter (non-pointer) memory management. Can't live w/o it!
Aside from the fully multithreaded kernel, the real reason why solaris (incl. x86) is better for mission-critical apps is that it supports real threads. On Linux, threads are mapped as processes, so a multi-threaded application, if works at all, works much slower than on a real threaded system, like Solaris. Until Linux has real threads, a threaded OS will always outperform it. This is why I stick with Solaris on the server and MacOS X on the desktop right now. Linux (and FreeBSD, where threads don't work at all) has a problem with C++ threads and exceptions as well. It's surprising that more people don't talk about this, perhaps nobody runs heavy multi-threaded applications on Linux yet...
Yeah, I agree that the XML "faster" claim is bogus.
On a Mac (although it's being phased out in MacOS X) files have something called a "resource fork" which is not accessible via STREAMS, but a special API. It's like an attribute list that's attached to each file.
Well, not exactly:
X11, by default, does not allow other users to connect to a X server running by other users. You have to do either "xhost +" or "xauth add..." to allow other users, so X11 is not a problem.
MacOS X does not allow other users to connect to the Display server at all. It's done via Mach messages, which are read/write for the specific user running the UI server only.
As I am not a novice, my biggest problem with Linux is the lack of "real" thread implementation. Agreed, the community has done a wonderful job of hacking up pthreads support with the LinuxThreads library, but, face it, it's still a workaround, a "hack-around" the fact that the kernel has no real thread support. As a result, sometimes you get hung/orphaned and runaway processes, multiple "ps" listings, and slow performance due to this design issue. Unfortunately, this isn't easy to fix, and I am not aware of any plans to fix it. It's too bad because Linux (and FreeBSD) is now the last OS that does not have real threads. Even Windows has real threads. I am involved in creating heavily threaded, scalable real-time high-performance servers. This issue bites big time on Linux, as the programs run slowest on Linux, much slower than on any other OS. Linux would suit needs if this was fixed. Hardware support (such as dvd, cd-rw, sound, SCANNERS) is #2 on my list.
I guess my crack smoking is to blame to do the tests on the same hardware. IBM JRE, unfortunately, crashes, and I will also take 4 2-way boxes over 10 1-ways. sorry. shhhh--cough-cough-cough
Unfortunately, Linux is not an adequate deployment platform for high-traffic enterprise apps. This is due for the most part to the Linux threads architecture (or lack thereof) and less-than-optimized java implementation. Since Linux has no real threads and no optimized mutex locking (such as adaptive locks), high workload, simultaneous requests and network traffic brings latencies up very rapidly and makes the system dog slow very quickly.
Of course, Linux can be a great development platform for J2EE, and the apps can be deployed on Solaris (even Solaris Intel) or MacOS X (which has a marveous super-optimized JVM)
In (clearly unscientific) testing that I made, Solaris Intel was about 3x as fast under load and a lot snappier than Linux on the same hardware.
When the ScreenLock is activated, can I finally log in as another user? ala XP or ala Linux virtual screen. This is the only thing missing from the "Perfect" version of MacOS X? still?
Intel compiler works great, except for handling exceptions in a multi-threaded program. The exception stacks get mangled if multiple threads throw/catch exceptions at the same time.
gcc exception handling is completely thread-local so there is no locking and it works great. That's why I can't use icc for my own product.
My info is about 3 months old.
I wonder if they fixed this...?
Actually, in my company the coding standards prohibit from using quoted #include statements.
We have an environment where some include files come from a global repository that comes from nightly builds, and others come from "local" include repository that's being changed by a certain user. If the angle brackets are not used, the files from the same directory, i.e. nightly build directory will be used even though newer files are available locally. This is a major no-no. In short, the quote brackets look at the current directory - not where the make was done, but where the preprocesor is currently looking at during the inclusion process.
Don't use quoted #includes. Always use angle brackets, and -I. compiler directive. Always.
Re:GUI Toolkit Design
on
GTK-- vs. QT
·
· Score: 1
Excellent on all points.
It is an understatement that programmers don't know how to design GUIs, and they are further burdened by the complexity of using a programming language to do this.
I don't know how this moderation here works, though.
The problem with the most GUI toolkits is that the implemenation is in a programming language.
When you look at a GUI and strip the application functionality, it is "described", not "programmed". Thus, it is best to use a description language, and not a programming language to create GUIs.
The main benefit of this is that you get separation of the GUI and functionality in a very natural way, and also have flexibility to change the GUI without having to touch functionality of the application, thus achieving object-oriented design throughout the GUI.
Toolkit such as Mozilla/XPToolkit/XUL is designed with this in mind, and is cross-platform, so I would recommend it as the toolkit to use.
Also, same applies to Motif with libXmt, but it lacks cross-platform support of Mozilla.
Any other description-language based GUI toolkits out there? Let me know.
Slashdot Mirror
And, of course, for the slashdot crowd?
BlueBalls!!!
I was on the floor when reading this thread
There are a number of dynamic cache products that are developed just to solve your problem - from WARP Solutions (warpsolutions.com) just to name one. It's a much lower risk solution than to wholesale drop all your technology investment and replace it that could be just as bad, or worse!
Enjoy, no searching needed.
_ ga llery/source/ipods_world528.html
_ ga llery/source/ipods_world577.html
http://www.ipodlounge.com/assets/galleries/iatw
http://www.ipodlounge.com/assets/galleries/iatw
You'd think, but I tried it and it doesn't work.
Publishing just hangs there, it connects, by hangs.
Don't know why
YOU are clueless. snprintf() is part of ANSI C99
standard. They are late renaming this.
Oh, but snprintf() has been ANSI since 1989. Maybe they are just "late"
Because a lot of their code can have buffer overruns due to the lack (or precieved lack) of this function by their own programmers. Makes it easy to create insecure programs and harder to create secure ones.
I just ported a large amount of code to windows, and I was very surprised to notice that snprintf() is _snprintf() on windows. It's like they hid it (or implemented it much later) and it's not part of "their" standard. Without widespread use of this function, god knows how many lines of their code uses regular sprintf() and insecure functions like it. And I doubt they use "%13s" or directives like this in sprintf(), or if their version even supports these constructs.
Don't know. Haven't used it.
Can you use VS for compiling and something else for editing, for example? As for the infrastructure (.net) in general. I think it can interoperate well using XML, so that part isn't an issue unless MS starts "proprietarizing" XML protocols.
The subject says it all. Don't push your thing onto developers. Just publish it. If it's any good, people will use it. Sourceforge.net is one place to do it. Design your tool in an OO and component-oriented way, so people can mix-and-match your tool with others they are used to. The biggest mistake you can make is to develop a monolithic "infrastructure" that can't be used interchangably with other pieces and is required for all further development. Noone is going to use that. Publish small components, each of which do a single job really, really well, and then integrate them in a component-oriented fashion. Good Luck!
Does anybody know whether Borland tools (new or old) are ABI compaible with MS' tools, especially for C++ (unmanaged)
i.e. do C++ libs compiled with VS.Net work with Borland's tools/applications?
First Post!
While it's true that wireless gear doesn't affect the avionics on most modern aircraft, and most digital networks nowdays aren't susseptible to "multiple-cell-from-altitude" degradation, you won't be able to use a wireless phone from more than about 18,000 feet. You just won't get any receptions b/c radio signals from wireless stations don't go that high up.
RogueWave SourcePro is an excellent product,
highly recommended (although a bit expensive)
They support connection pooling, threads,
completely DB-agnostic & runtime DB back-end switching, Envelope-Letter (non-pointer) memory management. Can't live w/o it!
Aside from the fully multithreaded kernel, the real reason why solaris (incl. x86) is better for mission-critical apps is that it supports real threads. On Linux, threads are mapped as processes, so a multi-threaded application, if works at all, works much slower than on a real threaded system, like Solaris. Until Linux has real threads, a threaded OS will always outperform it. This is why I stick with Solaris on the server and MacOS X on the desktop right now.
Linux (and FreeBSD, where threads don't work at all) has a problem with C++ threads and exceptions as well. It's surprising that more people don't talk about this, perhaps nobody runs heavy multi-threaded applications on Linux yet...
Yeah, I agree that the XML "faster" claim is bogus.
On a Mac (although it's being phased out in MacOS X) files have something called a "resource fork" which is not accessible via STREAMS, but a special API. It's like an attribute list that's attached to each file.
Well, not exactly: X11, by default, does not allow other users to connect to a X server running by other users. You have to do either "xhost +" or "xauth add ..." to allow other users, so X11 is not a problem.
MacOS X does not allow other users to connect to the Display server at all. It's done via Mach messages, which are read/write for the specific user running the UI server only.
As I am not a novice, my biggest problem with Linux is the lack of "real" thread implementation.
Agreed, the community has done a wonderful job of hacking up pthreads support with the LinuxThreads library, but, face it, it's still a workaround, a "hack-around" the fact that the kernel has no real thread support.
As a result, sometimes you get hung/orphaned and runaway processes, multiple "ps" listings, and slow performance due to this design issue.
Unfortunately, this isn't easy to fix, and I am not aware of any plans to fix it.
It's too bad because Linux (and FreeBSD) is now the last OS that does not have real threads. Even Windows has real threads.
I am involved in creating heavily threaded, scalable real-time high-performance servers.
This issue bites big time on Linux, as the programs run slowest on Linux, much slower than on any other OS.
Linux would suit needs if this was fixed.
Hardware support (such as dvd, cd-rw, sound, SCANNERS) is #2 on my list.
I guess my crack smoking is to blame to do the tests on the same hardware. IBM JRE, unfortunately, crashes, and I will also take 4 2-way boxes over 10 1-ways. sorry. shhhh--cough-cough-cough
Unfortunately, Linux is not an adequate deployment platform for high-traffic enterprise apps. This is due for the most part to the Linux threads architecture (or lack thereof) and less-than-optimized java implementation. Since Linux has no real threads and no optimized mutex locking (such as adaptive locks), high workload, simultaneous requests and network traffic brings latencies up very rapidly and makes the system dog slow very quickly.
Of course, Linux can be a great development platform for J2EE, and the apps can be deployed on Solaris (even Solaris Intel) or MacOS X (which has a marveous super-optimized JVM)
In (clearly unscientific) testing that I made, Solaris Intel was about 3x as fast under load and a lot snappier than Linux on the same hardware.
When the ScreenLock is activated, can I finally log in as another user? ala XP or ala Linux virtual screen. This is the only thing missing from the "Perfect" version of MacOS X? still?
Intel compiler works great, except for handling exceptions in a multi-threaded program. The exception stacks get mangled if multiple threads throw/catch exceptions at the same time. gcc exception handling is completely thread-local so there is no locking and it works great. That's why I can't use icc for my own product. My info is about 3 months old. I wonder if they fixed this...?
Actually, in my company the coding standards prohibit from using quoted #include statements.
We have an environment where some include files come from a global repository that comes from nightly builds, and others come from "local" include repository that's being changed by a certain user. If the angle brackets are not used, the files from the same directory, i.e. nightly build directory will be used even though newer files are available locally. This is a major no-no.
In short, the quote brackets look at the current directory - not where the make was done, but where the preprocesor is currently looking at during the inclusion process.
Don't use quoted #includes. Always use angle brackets, and -I. compiler directive. Always.
Excellent on all points.
It is an understatement that programmers don't know how to design GUIs, and they are further burdened by the complexity of using a programming language to do this.
I don't know how this moderation here works, though.
The problem with the most GUI toolkits is that the implemenation is in a programming language.
When you look at a GUI and strip the application functionality, it is "described", not "programmed". Thus, it is best to use a description language, and not a programming language to create GUIs.
The main benefit of this is that you get separation of the GUI and functionality in a very natural way, and also have flexibility to change the GUI without having to touch functionality of the application, thus achieving object-oriented design throughout the GUI.
Toolkit such as Mozilla/XPToolkit/XUL is designed with this in mind, and is cross-platform, so I would recommend it as the toolkit to use.
Also, same applies to Motif with libXmt, but it lacks cross-platform support of Mozilla.
Any other description-language based GUI toolkits out there? Let me know.