All this information is indispensable and you don't back it up?
Of course I do:-)
The Psion 5mx comes with synchronzation and backup software for Windows PC. I don't use the former but I do very much use the latter.
And to illustrate that:
I am actually on my second Psion 5mx. The first one died very suddenly in February. I got another one second-hand (they are not produced any more so new ones are hard to get) and in less than an hour after plugging it in, I had everything going again. There were a couple of packages that needed a re-install, otherwise, it would have been a ten-minute job.
Psion users on the other hand really use there devices intensively.
Amen to that!
I am absolutely dependent on my Psion 5mx. It is my:
Calendar. No, I don't synchronize it with anything.
Contacts database. No synch here either.
Internet client when I'm away from home. Works best when I have GPRS access, though.
Time tracker. I work as a freelancer so I have to keep track of billable hours. This app alone pays for the PDA within two months.
Database. I am the "archivist" for the choir, I sing in. The database listing our collection of music is kept on the 5mx. So is the spreadsheet logging member attendance.
Navigator. This is more for fun as it is not terribly reliable. Also, the GPS receiver runs on external power only so it is only useful in the car.
So far I haven't found anything that matches the 5mx in usefulness,
BTW, two AA alkalines last well over a month.
A girlfriend of mine had a cat that would sit and watch you all day long, not moving, not reacting to anything. If you got close enough, it would try to claw your eyes out. If you escaped and could still use your eyes, you would see the cat sitting there looking at you calm and cool. That cat was evil.
You should have given in to your anger and thrown it out the window.
Real engineering is tinkering and logging what you did. In engineering there are three phases, which involve tinkering and experimenting and doing simulation. The second phase is coming up with a game plane. With the last phase being the implementation.
There's also psychological data that shows that people tend to hold dear those things that they have invested more in.
A little story from long ago:
When B&O (Danish Design home stereo equipment) was first introduced on the US market sales were nothing to write home about - until the prices were doubled. Then it started selling like crazy.
Among other things, Kunze points out that Free software projects could be effectively discouraged from releasing software if software producers are required to provide warranties
Easy. Let the warranty state that if the users are not satisfied with the free software product, they will get their money back.
I spent a couple of days with a this bug in an ECG monitor:
When the users pressed a specific (valid) key sequence rapidly enough, the keys stopped working.
The monitor used a message passing RTOS and it turned out that a small utility function was the culrpit. This function aquired a message buffer, filled it in and sent the message to a specific task. That task was then responsible for releasing the buffer. This worked fine - until someone used this utility function in that very same task. When the key sequence was entered, one task would send a message that in turn would require a call to the utility function in that task. But before that message was processed, another task would call the utility and thus aquire the message buffer. So when the offending task became running, it would have two messages in its queue: The first message would require it to try to aquire the message buffer already used in the second message. Result: deadlock.
Despotism and socialism aren't mutually exclusive. Far from it. They appear to be mutual attractors.
Your remark just shows that you know very little of the worlds around you. Almost all Western European countries have had socialist governments without reverting into despotism.
I use SlickEdit on Windows 2000 almost daily, but it's very unstable.
So do I, and yes, I have had it crash on me. But there are months of daily use between those crashes. I've used SlickEdit for Windows since version 4 and I have just upgraded to version 7. During that time I have found Slickedit to be a very stable piece of software.
It crashes at least once a week.
Hmm, you have applied the latest patches, haven't you?
so your saying basicly 1/10 the stuff that would go into cvs if the developers had a brain cell among them
They do. But they have decided that adding this fucntionality to CVS is not viable, so they're developing subversion instead.
Hint: Many of the subversion developers are also CVS maintainers.
Re:Relatively unbiased compared to past reports
on
Forbes on Linux
·
· Score: 2
Windows keeps crashing, sometimes not even restarting and they have to call a technician to come and fix it.
The OS is not the issue here. Windows 2000 in itself is very stable. But...
The custom software they are using (developed by some fine VisualBasic grads) miscalculates the sales reports, commissioned salespeople losing sales because they ring up a sale and it goes into someone else's name.
This is where the problem is. Running the POS system on another OS such as Linux would still produce lots of errors and crashes if the POS software was developed to the same standard, that is abysmally bad.
Unfortunately I don't know if that version is still included with Visual SlickEdit (it used to be a separate product, then it was bundled for a while).
It isn't but since Slickedit has excellent facilities for building from within the editor, it isn't necessary to drop to a command window. Slickedit can grab the compiler output and show it in window where you can double-click on the error and have the code line in question shown in the editor.
Basically Slickedit contains all the good features found in IDEs without being tied to specific language/compiler.
No, because BeOS uses probalistic scheduling only for its timesliced tasks. In hard real-time systems, timeslicing is almost never used because it makes it a lot harder to guarantee that the system responds within the time limit - and getting that part right is hard enough as it is. Probablistic scheduling may help a little but it is not a cure-all. If it was, BeOS wouldn't need a Real-time class for tasks.
The default configuration of all semaphores within 5.x VxWorks modules is to be 'simple'. In order to change these initialization values, you had either hunt through symbol tables and assembly code dumps or put a gun to the head of some poor slob in Windriver tech support.
I haven't used VxWorks and therefore I don't know the level of their documentation. But if the way a semaphore works can be changed, surely there must be a documented public interface for this. Otherwise it gives no meaning to have that flag in the semaphore at all.
The problem with the Pathfinder was that the developers had to apply the patch at run-time and therefore they had to pore over symboltables and whatnot. If they had been aware of the problem during debugging before launch, it could probably have been solved by adding a simple function call.
To have a non-inversion safe objects inside a network stack is simply stupid design.
No. To need priority inheritance because the design is not priority inversion safe is simply stupid design. The question one needs to ask oneself is: Is it really necessary for the low priority task to have direct access to this resource and thereby running the risk of blocking the high priority task that uses the same resource?
There are ways to avoid priority inversion such as serializing access to the resource through the high priority task. Yes, at first this looks like priority inheritance but the big difference is that the high priority task is in control and can thus decide which request to process. Solving the problem with priority inheritance simply means that the high priority won't have to wait so long before the low priority task finishes.
Priority inheritance is the duct tape of real-time programming: It holds the program together but God knows for how long.
and the jet actually goes into a "controlled stall" and moves backwards (or so it appears visually) for a short distance. Hell if I know if it's useful in combat
It is if the opponent cannot do the same. The opponent will overshoot and is now a very nice and easy target - as Argentine pilots found out the hard way during the Falklands war when flying against British Sea Harriers.
In 1997 the Mars Pathfinder probe had a problem with VxWorks and priority inversion.
Priority inversion is never caused by the OS, only by the interrupt/task priority design. So VxWorks shouldn't be blamed here.
There are RTOS'es that try to avoid priority inversion by temporarily raising the priority of the blocking task to the same priority as the task being blocked. This may at first look like a good solution but if the priority bumping happens too often, "medium priority" tasks may get starved because the low priority task is really running at high priority.
Perhaps the F22 is having something similar -- whenever you have a RTOS, the designer must try to anticipate when it's safe to block real time interrups and when it isn't.
Blocking interrupts may mean missing interrupts. This is a very dangerous thing to do in hard realtime systems, because what you don't know may not only hurt you but may actually kill you. If it is necessary to disable interrupts to get the system running, the system design is horribly flawed.
If the build and testing is triggered from a UNIX box...
It isn't and it won't be for a forseable future. But my gripe is really with developers that don't think cross-platform from the start. Another very interesting CM project is Vesta which also cannot run in a Windows environment.
The reason for not supporting Windows for both of these projects is probably that they are so old (10+ years) that Windows was not really regarded not to mention used as a serious development system. This situation changed with Windows NT4 and more so with Windows 2000 which is my OS of choice these days (that may change back if/when MS licensing terms become too much hassle, though).
Slashdot Mirror
Of course I do :-)
The Psion 5mx comes with synchronzation and backup software for Windows PC. I don't use the former but I do very much use the latter.
And to illustrate that:
I am actually on my second Psion 5mx. The first one died very suddenly in February. I got another one second-hand (they are not produced any more so new ones are hard to get) and in less than an hour after plugging it in, I had everything going again. There were a couple of packages that needed a re-install, otherwise, it would have been a ten-minute job.
Amen to that!
I am absolutely dependent on my Psion 5mx. It is my:
- Calendar. No, I don't synchronize it with anything.
- Contacts database. No synch here either.
- Internet client when I'm away from home. Works best when I have GPRS access, though.
- Time tracker. I work as a freelancer so I have to keep track of billable hours. This app alone pays for the PDA within two months.
- Database. I am the "archivist" for the choir, I sing in. The database listing our collection of music is kept on the 5mx. So is the spreadsheet logging member attendance.
- Navigator. This is more for fun as it is not terribly reliable. Also, the GPS receiver runs on external power only so it is only useful in the car.
So far I haven't found anything that matches the 5mx in usefulness, BTW, two AA alkalines last well over a month.You should have given in to your anger and thrown it out the window.
Not where I live - last time we voted whether we would switch to euro, the majority was against.
This may change if we get to vote on it again - but when that will happen no one outside the government knows.
- Amount of extra work needed multiplied with normal hourly rate.
- Reduced earnings caused by project delay
- ...whatever else that will add to the total cost.
Tell the PHBs how much more their smart solution will cost in actual currency (dollars, kroner, euros...).Then they'll understand.
If you had bothered to look on this page (same site) and read the second paragraph you would have found out that the goal is to get 35% of our energy from renewable sources, that is wind, waves, solar etc..
...It should play the the song!
That's right - but they won't call it the real bridge afterwards. They call it a test, an experiment and throws it away when they're done with it.
No so in SW-development where the kluged-up prototype often becomes the Application 1.0 because management don't think there is time to do it right.
Thank God bridges aren't built that way!
A little story from long ago:
When B&O (Danish Design home stereo equipment) was first introduced on the US market sales were nothing to write home about - until the prices were doubled. Then it started selling like crazy.
Go Figure...
100% slower? That means it didn't run at all!
What you probaly meant was that Fortran was 100% faster than C++.
Easy. Let the warranty state that if the users are not satisfied with the free software product, they will get their money back.
When the users pressed a specific (valid) key sequence rapidly enough, the keys stopped working.
The monitor used a message passing RTOS and it turned out that a small utility function was the culrpit. This function aquired a message buffer, filled it in and sent the message to a specific task. That task was then responsible for releasing the buffer. This worked fine - until someone used this utility function in that very same task. When the key sequence was entered, one task would send a message that in turn would require a call to the utility function in that task. But before that message was processed, another task would call the utility and thus aquire the message buffer. So when the offending task became running, it would have two messages in its queue: The first message would require it to try to aquire the message buffer already used in the second message.
Result: deadlock.
I should add: this was in 8086 assembly...
Your remark just shows that you know very little of the worlds around you. Almost all Western European countries have had socialist governments without reverting into despotism.
Wait a minute, Einstein... that was INDIAN land before those white people came in and forcibly took it from them.
So do I, and yes, I have had it crash on me. But there are months of daily use between those crashes. I've used SlickEdit for Windows since version 4 and I have just upgraded to version 7. During that time I have found Slickedit to be a very stable piece of software.
It crashes at least once a week.
Hmm, you have applied the latest patches, haven't you?
They do. But they have decided that adding this fucntionality to CVS is not viable, so they're developing subversion instead.
Hint: Many of the subversion developers are also CVS maintainers.
The OS is not the issue here. Windows 2000 in itself is very stable. But...
The custom software they are using (developed by some fine VisualBasic grads) miscalculates the sales reports, commissioned salespeople losing sales because they ring up a sale and it goes into someone else's name.
This is where the problem is. Running the POS system on another OS such as Linux would still produce lots of errors and crashes if the POS software was developed to the same standard, that is abysmally bad.
It isn't but since Slickedit has excellent facilities for building from within the editor, it isn't necessary to drop to a command window. Slickedit can grab the compiler output and show it in window where you can double-click on the error and have the code line in question shown in the editor.
Basically Slickedit contains all the good features found in IDEs without being tied to specific language/compiler.
- Superb source code browser. The main reason why I bought Slickedit.
- Runs on most OS'es including Linux and OS/390(!).
- C-like macro-language
- The people at Slickedit are very responsive if you're having trouble. This includes support as well as sales.
Cons:- It costs money. A single user license is $299 in USA and Canada, $329 everywhere else.
- No Mac version.
See more at www.slickedit.com.Disclaimer: I use Slickedit eight hours a day but am in no other way affiliated with the company.
Probalistic scheduler? Had to look that one up :-)
No, because BeOS uses probalistic scheduling only for its timesliced tasks. In hard real-time systems, timeslicing is almost never used because it makes it a lot harder to guarantee that the system responds within the time limit - and getting that part right is hard enough as it is. Probablistic scheduling may help a little but it is not a cure-all. If it was, BeOS wouldn't need a Real-time class for tasks.
The default configuration of all semaphores within 5.x VxWorks modules is to be 'simple'. In order to change these initialization values, you had either hunt through symbol tables and assembly code dumps or put a gun to the head of some poor slob in Windriver tech support.
I haven't used VxWorks and therefore I don't know the level of their documentation. But if the way a semaphore works can be changed, surely there must be a documented public interface for this. Otherwise it gives no meaning to have that flag in the semaphore at all.
The problem with the Pathfinder was that the developers had to apply the patch at run-time and therefore they had to pore over symboltables and whatnot. If they had been aware of the problem during debugging before launch, it could probably have been solved by adding a simple function call.
To have a non-inversion safe objects inside a network stack is simply stupid design.
No. To need priority inheritance because the design is not priority inversion safe is simply stupid design. The question one needs to ask oneself is:
Is it really necessary for the low priority task to have direct access to this resource and thereby running the risk of blocking the high priority task that uses the same resource?
There are ways to avoid priority inversion such as serializing access to the resource through the high priority task. Yes, at first this looks like priority inheritance but the big difference is that the high priority task is in control and can thus decide which request to process. Solving the problem with priority inheritance simply means that the high priority won't have to wait so long before the low priority task finishes.
Priority inheritance is the duct tape of real-time programming: It holds the program together but God knows for how long.
It is if the opponent cannot do the same. The opponent will overshoot and is now a very nice and easy target - as Argentine pilots found out the hard way during the Falklands war when flying against British Sea Harriers.
Priority inversion is never caused by the OS, only by the interrupt/task priority design. So VxWorks shouldn't be blamed here.
There are RTOS'es that try to avoid priority inversion by temporarily raising the priority of the blocking task to the same priority as the task being blocked. This may at first look like a good solution but if the priority bumping happens too often, "medium priority" tasks may get starved because the low priority task is really running at high priority.
Perhaps the F22 is having something similar -- whenever you have a RTOS, the designer must try to anticipate when it's safe to block real time interrups and when it isn't.
Blocking interrupts may mean missing interrupts. This is a very dangerous thing to do in hard realtime systems, because what you don't know may not only hurt you but may actually kill you. If it is necessary to disable interrupts to get the system running, the system design is horribly flawed.
It isn't and it won't be for a forseable future. But my gripe is really with developers that don't think cross-platform from the start. Another very interesting CM project is Vesta which also cannot run in a Windows environment.
The reason for not supporting Windows for both of these projects is probably that they are so old (10+ years) that Windows was not really regarded not to mention used as a serious development system. This situation changed with Windows NT4 and more so with Windows 2000 which is my OS of choice these days (that may change back if/when MS licensing terms become too much hassle, though).