Are there any free or commercial UNIX compatible operating systems that are not derived from the original code? Without any USL, Berkeley or GNU code, everything would have to be done from scratch. Not just the kernel, but all of the utilities. Who would be crazy enough to undertake all this in a commercial, proprietary setting?
If Linux were proprietary, it wouldn't be sufficiently UNIX like so on those grounds alone it would differ, since compatibility was and still is an important requirement. What proprietary vendor could even make a business case for meeting such a requirement, starting from scratch?
There would likely be better partnerships between hardware vendors and the vendor of proprietary Linux. The installations would probably have more bleeding edge hardware support, but wouldn't run well with old hardware. On the other hand, it would have poor market penetration. The stability would probably be worse.
I think that the system would be specialized. It would either be something geared at ISP's, large enterprises or for embedded use, but not all three. It would probably not attempt to crack the desktop market.
You might not see ``swiss army knife'' features like advanced routing, loopback block devices, or user-space network drivers. It's unlikely that there would be good support for hobbyists, such as amateur radio hackers.
The platform support would almost certainly suck. It would most likely not run on SPARCs, Alphas, PPC's, 68K's, Intels, Strongarms, etc.
The openness of Linux lets it be more things to more people, from small applications to big ones.
Anyway, proprietary software often makes or breaks it according to circumstances that have nothing to do with technical merit.
We could equally ask, how well would {Solaris, HP-UX, AIX, NT, BeOS,...} do if it were GNU software?
First of all, who would call a program Mosaic? These developers must be living with their heads in the sand to not know about the Mosaic web browser.
I think that this is just a scam to get some government $$$. The formula for this business is easy: identify a bogey man, write some software and use fear to sell it.
I think that the only reasonably certain predictor of violent behavior is, well, previous violent behavior.
How do you predict the behavior of the ``all round nice guy'' who is upright, successful, active within the community---in other words, one who fits the ``fits the mold''---yet who one day snaps and climbs the tower with a rifle to shoot at random victims?
Get real. People can always learn to evade the strategies of naive software anyway; just bullshit on the questions.
I just wonder how much this is going to end up costing U.S. taxpayers.
I think the red ones will have worse battery life.
on
Color Palms Announced
·
· Score: 2
Take it from a developer who supports all Win32 platforms from NT Server down to various WinCE devices.
We have encountered all kinds of issues over the past two years:
- UDP sockets set to non-blocking block anyway on recv() - connects to *non-existent* local TCP ports succeeding! - WaitForMultipleObjects hangs forever even with specified timeout. - Waiting for process to terminate by waiting on its handle doesn't work
These are just specific issues I recall off the top of my head.
Believe me, we have tons of #ifdef _WIN32_WCE occurences.
The overall user experience is that hangs are frequent.
How about revealing a ciphertext, plaintext and the algorithm and having people try to crack the key? Or at least some plaintext and ciphertext pairs, along with a larger message that is to be cracked without specifying anything about the algorithm.
By the way, the message reveals who really shot JFK. It's produced by a one time pad.;)
Linux threads don't quite conform to the POSIX standard because of the underlying model that is markedly different from systems like Solaris or Digital UNIX.
There are some differences in signal handling, and also notable differences in file locking. According to POSIX, a lock set by fcntl() is owned by a process, so if one thread places a lock, and another thread in the same process places a conflicting lock, the lock region should simply be extended In Linux, the second thread will block because it is de-facto a second process and the flock() code doesn't take into account that the process is actually part of a ``cluster'' of threads.
There also have been issues in the threading library as recently as glibc 2.1.1. I submitted a patch that fixed a serious crash in the case that the process creates too many threads (which could happen even if the number of threads is low, due to ulimit).
Other than some stability issues and incompatibilities with POSIX, I would not conclude that LinuxThreads is improperly implemented. The API is there and works. Things like mutexes, condition variables and thread-specific keys are nicely implemented. I particularly like the wait-free queuing algorithm used to resolve contentions for locks, based on an atomic compare-exchange sequence.
As for NT threads: there are some nasty issues that require painful workarounds. I could write volumes about the deficiencies, but here are some highlights:
1. No cancellation mechanism! In NT, if you want to shut down a thread in an orderly manner, you have to figure out what object(s) it is blocking on and disentangle it. In POSIX threads, you simply cancel the thread and when it hits the next cancellation point, it executes registered cleanup handlers and terminates. In NT, there are no cleanup handlers; a thread killed by TerminateThread just leaks all of its local resources.
2. Thread local storage is a joke! In POSIX, every thread specific key lets you register a cleanup handler. When a thread terminates, it executes cleanup handlers for all thread specific keys that have handlers. The only way I know of to do this in NT is to put your stuff into a DLL, so that you can hook the clean up to the THREAD_DETACH command passed to DllMain()---under this solution you have to write your own thread specific storage subsystem that supports destructors.
3. No condition variables! NT's events are poor substitutes for condition variables. There is no way to create an event that can wake up all threads waiting on it AND which can wake up just a single thread. With POSIX conditions, you have pthread_cond_signal() and pthread_cond_broadcast(). Furthermore, pthread_cond_wait() is a cancellation point (recall that NT has no cancellation). Events are horrible, stateful objects. Conditions are stateless, making it easier to verify code to be free of race conditions and other problems.
4. Poor exclusion mechanisms! Critical sections are the rough equivalent of the POSIX mutex. But they are fraught with problems. For one thing, each critical section has its own internal event that is used to resolve contention. This event is allocated when needed. Thus in low memory conditions, EnterCriticalSection() can throw a win32 exception due to failure to allocate the event handle! InitializeCriticalSection() returns nothing. (But there is a little known hack in NT only: if you pass a spin count with its high order bit set to InitializeCriticalSectionAndSpincount() then it will pre-allocate the event). Preallocated or not, each critical section potentially consumes non-swappable kernel memory!
By contrast, Linux mutexes do not consume any kernel resources. Nothing has to ever be allocated other than the space for the pthread_mutex_t object itself. Contention is resolved by suspending, and each thread comes with a way to suspend and resume so no semaphore-like object needs to be allocated.
Another problem with NT critical sections is that there is no way to atomically release one of these and wait on some object. POSIX has pthread_cond_wait() which releases a mutex and waits on a condition in a way that avoids losing the wakeup signalled from some other thread that subsequently acquires the mutex.
My experiences with Win32 programming under NT have led me to implement everything myself that is missing in the low level API: thread specific storage, mutexes and condition variables, cancellation, etc.
Don't worry. We have long been developing safeguards that will ensure the security of our respective jobs. I'm thinking of inventions like C, C++ and Perl.;)
Jokes aside, here are my two cents on the ``IT people shortage''. The problem is the availability of useful statistics that can be used to understand the problem, if it exists.
There is much diversity in jobs related to computing. You could be creating a web page, debugging an embedded OS, fixing some COBOL code on a mainframe, or gluing some SQL queries to a graphical interface and in all cases be called an IT worker. To lump these kinds of people into one category and declare a shortage of them is a big mistake.
What if the alleged shortage exists because so many small to mid size businesses business need eight dollar an hour VB monkeys and HTML jockeys. It could be that the shortage can be attributed to the dramatic surge in the use of inexpensive PC's? These platforms comes with an inadequate OS and inappropriate applications that require endless tweaking, tailoring, and propping up with wooden sticks. Sure you can get the core middleware from a vendor, but making it all work for the business requires labor. Thousands of little companies are reinventing the same thing in-house. Also the dramatic rise of the internet has created opportunities, but many of these are menial work that is looked down upon by a real software developer---for example, the mindless work of cranking out HTML and web related scripts in order to create cheesy web sites. From what I hear, jobs are dull, often stressful and underpaid. People that know how to do them don't want to do them, hence shortage.
The question is, how relevant is a labor shortage in a particular area of computing to someone who has not interest in that area?
The way I see it jobs that are are at greatest risk are jobs that involve very narrowly defined set of skills. For example, if all you know is how to customize some particular proprietary software package, your job will disappear along with that software package. One year there may be a shortage of people whose resumes bear acronyms relevant to that package, the next year, those who don't retrain are gone. But the change which brought that about was ultimately due to changes brought about by real developers.
So it's entirely about how the strokes are physically distributed: They're NOT. Every key (regardless of where it is on the keyboard or in the typewriter) is on a lever which hits the paper at EXACTLY THE SAME PLACE.
Yes, it is true that the hammers ultimately hit at the same place. However, a jam occurs before the hammers actually strike the paper. Those hammers that are close together are more likely to jam because of the acute angle between their paths. There is simply more opportunity for them to hit each other. Hammers that are far apart have a much smaller opportunity for jamming, since their paths intersect much more obliquely. Get it? When I was a child I would play with these typewriters, trying to see under circumstances I could produce a jam. I distinctly remember that it was far easier to produce a jam by simultaneously, or nearly simultaneously, striking keys whose hammers are close together than to produce a jam using keys that are far apart. The timing had to be much tighter. You could type an alternating sequence of letters far apart very quickly without jamming, but not so for letters close together. So distribution obviously matters.
Dvorak makes a dog's breakfast out of your vi command layout. For starters, hjkl movement keys end up scrambled.
An alternate keyboard layout might be manageable for people who only type text, but more difficult for users who use keyboard driven programs. Part of the problem is that when you type commands in a program like vi, you don't think of the letter that you are typing. When I want the cursor to go up, I just do it, I don't think ``okay, going up means letter K''. The motivation to move the cursor automatically translates to the right key. I suspect that even if I learned to type words instinctively on a Dvorak keyboard, I would still be tripped up when it came to editor commands.
From what I understand, QWERTY was supposedly designed to prevent jamming, not necessarily to slow typists down. Or perhaps to maximize speed while minizming jamming. The left to right hand alternation actually helps your speed---or so I have seen it argued in the Dvorak-vs-QWERTY articles that have been linked from/.
The problems on old typewriters occur when you strike two keys that are in close proximity at about the same time; that's when the type heads get all stuck together. So it's not entirely about speed but about how the strokes are physically distributed. It's not hard to see that a design which distributes the load to prevent jamming could also have a beneficial effect on typing efficiency.
The ranking capability is nice, but what's missing is more sophisticated pattern searching and a way to combine boolean expressions. There are times when I simply can't specify what I want to Google, so I'm forced to go to clunky old Altavista's advanced text search.
The ability to rank pages is good when you are doing broad searching that comes up with many hits. When you are searching for something specific, the ranking is next to useless---who needs ranking for a half dozen results?
Or am I just ignorant? Someone will undoubtedly now point me to some piece of RTFM.
If I understand it, what this license does is reserve the right held by the original author (``originator'') to re-appropriate derived works into their own proprietary product. However, the people creating derived works can effectively hamper this because they can choose to redistribute using the GPL rather than the TGPL. The way I understand it, only the TGPL'ed modifications can be re-appropriated.
I think that the same effect can be achieved by offering the code under two different licenses, like the GPL plus something more restrictive. This would eliminate the complication in the TGPL in that it explicitly has to give a choice between itself and the GPL.
Thus the TGPL would simply by the GPL with a clause saying that the author can take back the modifications and use them. And the author would offer the code either under TGPL or GPL, with your choice as to which one you choose to agree to and use for subsequent redistribution.
The article talks about these two things as though they were hardware standards from competing vendors.
When in fact you can remap your keyboard using software, and put stickers on the keycaps. (Shuffling the keycaps around won't work all that well because on most keyboards, the keycaps from different rows have different shapes). (Some of us wouldn't need the stickers; it would not impede me at all if the key labels were sanded right off).
Moreover, choosing a keyboard layout is personal preference. If you choose a Dvorak layout, you won't suddenly be a technological outcast who is unable to use computer software. (Except that, you will be stuck to having to implement your customization in every environment, whereas if you type QWERTY, you don't need to customize anything).
I don't see what the fuss is about taking this far enough to be able to establish a link to a satellite. You want end-to-end security, not end-to-satellite and satellite-to-end! What about rogue satellites run by Eve?
Also, on a different note, the title of this story should have been ``quantum key exchange'' not ``quantum encryption''. I was misled into thinking that this would be about quantum computing rather than communication.
Firstly, you can ignore the problem if you allow only the exact same executable to re-open the memory map. In that case, the vtable pointers that are in that persistent file should be valid, because the vtables have fixed virtual addresses in static storage. All you have to ensure is that the mapping of the region is to the same address so that pointers to within that storage also remain valid. Of course, this will not work if you change an recompile the program, because the vtables might then shuffle around.
Secondly, you can still hack outside of the C++ language to mess with objects' vtable pointers. It should be possible to wrap up this ugliness in a module that can be adapted for various compilers.
Here are some good reasons why they might be considering using C++.
1. Perl is already written in C. C++ gives you an easier migration path from C than other languages. You can gradually move the program component by component. The C++ parts can freely call the C parts and everything is linked into a homogeneous whole.
2. Speed. Perl is a interpreter for a programming language. Moreover, it is widely used in practical applications. So it deserves to be written in a systems programming language that is statically typed and translates to reasonably efficient machine code.
Although, autism has had some slashdot attention lately, but let's not go overboard ascribing everything to it.;) It's not productive to merge ``autism'' and ``intelligence'' as synonyms for the same thing; the power of words lies in their ability to discern among meanings.
The guy is obviously a goddam packer, and not one of us fine mappers who can spot concurrency problems from a mile away.:)
Here is what I would have done with the original code: short of replacing the mutex with a critical section, I would eliminate the case in which the mutex is tested for abandonment. The logic of the system should guarantee that mutex abandonment doesn't take place. It can only happen if you have threads that mysteriously terminate when they should not, like in the middle of holding a critical lock. When that happens, your software is screwed; you might as well dereference a null pointer and call it a day. So these error checks are a complete waste of time and indicate a strong packer mentality---``I don't know what the hell is going on in this software, or what the relationship is between this function and the rest of the system, so I will guard myself against every possiblity, real or imagined.'' It would be better to inspect all of the critical regions of code protected by that mutex and verify that all of them properly release the lock, and do not terminate the thread in the middle.
In Chapter 2, section ``Quality Plateau'', the author attempts to restructure some skanky looking function written for the Win32 environment. For the sake of making it look more readable, he suspiciously moves a mutex release so that some accesses to global variables are no longer protected! The whole point of the mutex is so that you can safely and atomically do the g_nIndex++ and the update of the g_dwTimes[] array! (I know because I chased the reference and looked it up on the book. In _Advanced Windows NT_, a critical section is used instead of a mutex).
I would restructure the piece of code by calling GetTickCount outside of the critical region of code, and only do what is absolutely necessary while the lock is held: namely the update of the shared data.
Also, what kind of a dorky cheesehead thinks that changing from one bracing style to another is a form of simplification?
Overall, I find the piece to be a rambling bunch of psychobabble designed to stroke the egos of programmers, who will at once fancy themselves to be the good mappers and not the evil peckers. Oops, packers.;)
Slashdot Mirror
The VB dummies get a little self esteem boost out of all this. What's wrong with that?
They deserve our pity and emotional support, not to be cut down.
;)
Are there any free or commercial UNIX compatible operating systems that are not derived from the original code? Without any USL, Berkeley or GNU code, everything would have to be done from scratch. Not just the kernel, but all of the utilities. Who would be crazy enough to undertake all this in a commercial, proprietary setting?
If Linux were proprietary, it wouldn't be sufficiently UNIX like so on those grounds alone it would differ, since compatibility was and still is an important requirement. What proprietary vendor could even make a business case for meeting such a requirement, starting from scratch?
There would likely be better partnerships between hardware vendors and the vendor of proprietary Linux. The installations would probably have more bleeding edge hardware support, but wouldn't run well with old hardware. On the other hand, it would have poor market penetration. The stability would probably be worse.
...} do if it were GNU software?
I think that the system would be specialized. It would either be something geared at ISP's, large enterprises or for embedded use, but not all three. It would probably not attempt to crack the desktop market.
You might not see ``swiss army knife'' features like advanced routing, loopback block devices, or user-space network drivers. It's unlikely that there would be good support for hobbyists, such as amateur radio hackers.
The platform support would almost certainly suck. It would most likely not run on SPARCs, Alphas, PPC's, 68K's, Intels, Strongarms, etc.
The openness of Linux lets it be more things to more people, from small applications to big ones.
Anyway, proprietary software often makes or breaks it according to circumstances that have nothing to do with technical merit.
We could equally ask, how well would {Solaris, HP-UX, AIX, NT, BeOS,
First of all, who would call a program Mosaic? These developers must be living with their heads in the sand to not know about the Mosaic web browser.
I think that this is just a scam to get some government $$$. The formula for this business is easy: identify a bogey man, write some software and use fear to sell it.
I think that the only reasonably certain predictor of violent behavior is, well, previous violent behavior.
How do you predict the behavior of the ``all round nice guy'' who is upright, successful, active within the community---in other words, one who fits the ``fits the mold''---yet who one day snaps and climbs the tower with a rifle to shoot at random victims?
Get real. People can always learn to evade the strategies of naive software anyway; just bullshit on the questions.
I just wonder how much this is going to end up costing U.S. taxpayers.
Just a suspicion.
Take it from a developer who supports all Win32 platforms from NT Server down to various WinCE devices.
We have encountered all kinds of issues over the past two years:
- UDP sockets set to non-blocking block anyway on recv()
- connects to *non-existent* local TCP ports succeeding!
- WaitForMultipleObjects hangs forever even with specified timeout.
- Waiting for process to terminate by waiting on its handle doesn't work
These are just specific issues I recall off the top of my head.
Believe me, we have tons of #ifdef _WIN32_WCE occurences.
The overall user experience is that hangs are frequent.
How about revealing a ciphertext, plaintext and the algorithm and having people try to crack the key? Or at least some plaintext and ciphertext pairs, along with a larger message that is to be cracked without specifying anything about the algorithm.
;)
By the way, the message reveals who really shot JFK. It's produced by a one time pad.
Linux threads don't quite conform to the POSIX standard because of the underlying model that is markedly different from systems like Solaris or Digital UNIX.
There are some differences in signal handling, and also notable differences in file locking. According to POSIX, a lock set by fcntl() is owned by a process, so if one thread places a lock, and another thread in the same process places a conflicting lock, the lock region should simply be extended In Linux, the second thread will block because it is de-facto a second process and the flock() code doesn't take into account that the process is actually part of a ``cluster'' of threads.
There also have been issues in the threading library as recently as glibc 2.1.1. I submitted a patch that fixed a serious crash in the case that the process creates too many threads (which could happen even if the number of threads is low, due to ulimit).
Other than some stability issues and incompatibilities with POSIX, I would not conclude that LinuxThreads is improperly implemented. The API is there and works. Things like mutexes, condition variables and thread-specific keys are nicely implemented. I particularly like the wait-free queuing algorithm used to resolve contentions for locks, based on an atomic compare-exchange sequence.
As for NT threads: there are some nasty issues that require painful workarounds. I could write volumes about the deficiencies, but here are some highlights:
1. No cancellation mechanism! In NT, if you want to shut down a thread in an orderly manner, you have to figure out what object(s) it is blocking on and disentangle it. In POSIX threads, you simply cancel the thread and when it hits the next cancellation point, it executes registered cleanup handlers and terminates. In NT, there are no cleanup handlers; a thread killed by TerminateThread just leaks all of its local resources.
2. Thread local storage is a joke! In POSIX, every thread specific key lets you register a cleanup handler. When a thread terminates, it executes cleanup handlers for all thread specific keys that have handlers. The only way I know of to do this in NT is to put your stuff into a DLL, so that you can hook the clean up to the THREAD_DETACH command passed to DllMain()---under this solution you have to write your own thread specific storage subsystem that supports destructors.
3. No condition variables! NT's events are poor substitutes for condition variables. There is no way to create an event that can wake up all threads waiting on it AND which can wake up just a single thread. With POSIX conditions, you have pthread_cond_signal() and pthread_cond_broadcast(). Furthermore, pthread_cond_wait() is a cancellation point (recall that NT has no cancellation). Events are horrible, stateful objects. Conditions are stateless, making it easier to verify code to be free of race conditions and other problems.
4. Poor exclusion mechanisms! Critical sections are the rough equivalent of the POSIX mutex. But they are fraught with problems. For one thing, each critical section has its own internal event that is used to resolve contention. This event is allocated when needed. Thus in low memory conditions, EnterCriticalSection() can throw a win32 exception due to failure to allocate the event handle! InitializeCriticalSection() returns nothing. (But there is a little known hack in NT only: if you pass a spin count with its high order bit set to InitializeCriticalSectionAndSpincount() then it will pre-allocate the event). Preallocated or not, each critical section potentially consumes non-swappable kernel memory!
By contrast, Linux mutexes do not consume any kernel resources. Nothing has to ever be allocated other than the space for the pthread_mutex_t object itself. Contention is resolved by suspending, and each thread comes with a way to suspend and resume so no semaphore-like object needs to be allocated.
Another problem with NT critical sections is that there is no way to atomically release one of these and wait on some object. POSIX has pthread_cond_wait() which releases a mutex and waits on a condition in a way that avoids losing the wakeup signalled from some other thread that subsequently acquires the mutex.
My experiences with Win32 programming under NT have led me to implement everything myself that is missing in the low level API: thread specific storage, mutexes and condition variables, cancellation, etc.
Long live shred guitar. :) Favorites: Kruiz, Yngwie, Annihilator.
;)
Also a lot of baroque music and some romantic: J. S. Bach, Vivaldi, Chopin, and others.
Used to be a huge jazz fan in my teens: Chick Corea, Weather Report were my favorites. I still dig that stuff.
Basically anything that demonstrates the ability to play cool shit.
The project is doomed. ;)
Don't worry. We have long been developing safeguards that will ensure the security of our respective jobs. I'm thinking of inventions like C, C++ and Perl. ;)
Jokes aside, here are my two cents on the ``IT people shortage''. The problem is the availability of useful statistics that can be used to understand the problem, if it exists.
There is much diversity in jobs related to computing. You could be creating a web page, debugging an embedded OS, fixing some COBOL code on a mainframe, or gluing some SQL queries to a graphical interface and in all cases be called an IT worker. To lump these kinds of people into one category and declare a shortage of them is a big mistake.
What if the alleged shortage exists because so many small to mid size businesses business need eight dollar an hour VB monkeys and HTML jockeys. It could be that the shortage can be attributed to the dramatic surge in the use of inexpensive PC's? These platforms comes with an inadequate OS and inappropriate applications that require endless tweaking, tailoring, and propping up with wooden sticks. Sure you can get the core middleware from a vendor, but making it all work for the business requires labor. Thousands of little companies are reinventing the same thing in-house. Also the dramatic rise of the internet has created opportunities, but many of these are menial work that is looked down upon by a real software developer---for example, the mindless work of cranking out HTML and web related scripts in order to create cheesy web sites. From what I hear, jobs are dull, often stressful and underpaid. People that know how to do them don't want to do them, hence shortage.
The question is, how relevant is a labor shortage in a particular area of computing to someone who has not interest in that area?
The way I see it jobs that are are at greatest risk are jobs that involve very narrowly defined set of skills. For example, if all you know is how to customize some particular proprietary software package, your job will disappear along with that software package. One year there may be a shortage of people whose resumes bear acronyms relevant to that package, the next year, those who don't retrain are gone. But the change which brought that about was ultimately due to changes brought about by real developers.
Yes, it is true that the hammers ultimately hit at the same place. However, a jam occurs before the hammers actually strike the paper. Those hammers that are close together are more likely to jam because of the acute angle between their paths. There is simply more opportunity for them to hit each other. Hammers that are far apart have a much smaller opportunity for jamming, since their paths intersect much more obliquely. Get it? When I was a child I would play with these typewriters, trying to see under circumstances I could produce a jam. I distinctly remember that it was far easier to produce a jam by simultaneously, or nearly simultaneously, striking keys whose hammers are close together than to produce a jam using keys that are far apart. The timing had to be much tighter. You could type an alternating sequence of letters far apart very quickly without jamming, but not so for letters close together. So distribution obviously matters.
Go to FOLDOC, and look up the term ``race condition''.
Dvorak makes a dog's breakfast out of your vi command layout. For starters, hjkl movement keys end up scrambled.
An alternate keyboard layout might be manageable for people who only type text, but more difficult for users who use keyboard driven programs. Part of the problem is that when you type commands in a program like vi, you don't think of the letter that you are typing. When I want the cursor to go up, I just do it, I don't think ``okay, going up means letter K''. The motivation to move the cursor automatically translates to the right key. I suspect that even if I learned to type words instinctively on a Dvorak keyboard, I would still be tripped up when it came to editor commands.
From what I understand, QWERTY was supposedly designed to prevent jamming, not necessarily to slow typists down. Or perhaps to maximize speed while minizming jamming. The left to right hand alternation actually helps your speed---or so I have seen it argued in the Dvorak-vs-QWERTY articles that have been linked from /.
The problems on old typewriters occur when you strike two keys that are in close proximity at about the same time; that's when the type heads get all stuck together. So it's not entirely about speed but about how the strokes are physically distributed. It's not hard to see that a design which distributes the load to prevent jamming could also have a beneficial effect on typing efficiency.
The ranking capability is nice, but what's missing is more sophisticated pattern searching and a way to combine boolean expressions. There are times when I simply can't specify what I want to Google, so I'm forced to go to clunky old Altavista's advanced text search.
The ability to rank pages is good when you are doing broad searching that comes up with many hits. When you are searching for something specific, the ranking is next to useless---who needs ranking for a half dozen results?
Or am I just ignorant? Someone will undoubtedly now point me to some piece of RTFM.
If I understand it, what this license does is reserve the right held by the original author (``originator'') to re-appropriate derived works into their own proprietary product. However, the people creating derived works can effectively hamper this because they can choose to redistribute using the GPL rather than the TGPL. The way I understand it, only the TGPL'ed modifications can be re-appropriated.
I think that the same effect can be achieved by offering the code under two different licenses, like the GPL plus something more restrictive. This would eliminate the complication in the TGPL in that it explicitly has to give a choice between itself and the GPL.
Thus the TGPL would simply by the GPL with a clause saying that the author can take back the modifications and use them. And the author would offer the code either under TGPL or GPL, with your choice as to which one you choose to agree to and use for subsequent redistribution.
The article talks about these two things as though they were hardware standards from competing vendors.
When in fact you can remap your keyboard using software, and put stickers on the keycaps. (Shuffling the keycaps around won't work all that well because on most keyboards, the keycaps from different rows have different shapes). (Some of us wouldn't need the stickers; it would not impede me at all if the key labels were sanded right off).
Moreover, choosing a keyboard layout is personal preference. If you choose a Dvorak layout, you won't suddenly be a technological outcast who is unable to use computer software. (Except that, you will be stuck to having to implement your customization in every environment, whereas if you type QWERTY, you don't need to customize anything).
I don't see what the fuss is about taking this far enough to be able to establish a link to a satellite. You want end-to-end security, not end-to-satellite and satellite-to-end! What about rogue satellites run by Eve?
Also, on a different note, the title of this story should have been ``quantum key exchange'' not ``quantum encryption''. I was misled into thinking that this would be about quantum computing rather than communication.
Among other things, originated the IP masquerading code. Here is her home page.
Firstly, you can ignore the problem if you allow only the exact same executable to re-open the memory map. In that case, the vtable pointers that are in that persistent file should be valid, because the vtables have fixed virtual addresses in static storage. All you have to ensure is that the mapping of the region is to the same address so that pointers to within that storage also remain valid. Of course, this will not work if you change an recompile the program, because the vtables might then shuffle around.
Secondly, you can still hack outside of the C++ language to mess with objects' vtable pointers. It should be possible to wrap up this ugliness in a module that can be adapted for various compilers.
Here are some good reasons why they might be considering using C++.
1. Perl is already written in C. C++ gives you an easier migration path from C than other languages. You can gradually move the program component by component. The C++ parts can freely call the C parts and everything is linked into a homogeneous whole.
2. Speed. Perl is a interpreter for a programming language. Moreover, it is widely used in practical applications. So it deserves to be written in a systems programming language that is statically typed and translates to reasonably efficient machine code.
Although, autism has had some slashdot attention lately, but let's not go overboard ascribing everything to it. ;) It's not productive to merge ``autism'' and ``intelligence'' as synonyms for the same thing; the power of words lies in their ability to discern among meanings.
The guy is obviously a goddam packer, and not one of us fine mappers who can spot concurrency problems from a mile away. :)
Here is what I would have done with the original code: short of replacing the mutex with a critical section, I would eliminate the case in which the mutex is tested for abandonment. The logic of the system should guarantee that mutex abandonment doesn't take place. It can only happen if you have threads that mysteriously terminate when they should not, like in the middle of holding a critical lock. When that happens, your software is screwed; you might as well dereference a null pointer and call it a day. So these error checks are a complete waste of time and indicate a strong packer mentality---``I don't know what the hell is going on in this software, or what the relationship is between this function and the rest of the system, so I will guard myself against every possiblity, real or imagined.'' It would be better to inspect all of the critical regions of code protected by that mutex and verify that all of them properly release the lock, and do not terminate the thread in the middle.
In Chapter 2, section ``Quality Plateau'', the author attempts to restructure some skanky looking function written for the Win32 environment. For the sake of making it look more readable, he suspiciously moves a mutex release so that some accesses to global variables are no longer protected! The whole point of the mutex is so that you can safely and atomically do the g_nIndex++ and the update of the g_dwTimes[] array! (I know because I chased the reference and looked it up on the book. In _Advanced Windows NT_, a critical section is used instead of a mutex).
;)
I would restructure the piece of code by calling GetTickCount outside of the critical region of code, and only do what is absolutely necessary while the lock is held: namely the update of the shared data.
Also, what kind of a dorky cheesehead thinks that changing from one bracing style to another is a form of simplification?
Overall, I find the piece to be a rambling bunch of psychobabble designed to stroke the egos of programmers, who will at once fancy themselves to be the good mappers and not the evil peckers. Oops, packers.