I'm confused here. Is ACT a specific application or a class of tools. Are you certain there is nothing that can work for sales forces right now on linux whether it be web-based, in-house ports, or some tool built on top of vantive, scopus, or a similar cross-platform tool?
Heck, on my bicycle I typically pull entirely off the road to the right (onto the sidewalk, dirt whatever) when an emergency vehicle is approaching.
Partly I assume I'm less visible, but partly it just seems retarded not to get out of the way. It's sad that most vehicles don't even START to pull over until they're sure that the siren is coming right for them.
A stable framerate is soo much more pleasing aesthetically. Variable framerates are really distracting and make me think about the engine and the software and the hardware, instead of being immersed in the game.
Unfortunately techs are usually poorly equipped to negotiate skillfully, a fact I learned personally when my scum-of-a-boss-who-I-thought-was-a-friend ripped me off for thousands because I didn't know how to negotiate properly. For years I was bitter, until I started checking out books and audio tapes on how to negotiate effectively. Bottom line: it was my fault I got ripped off.
Of course. It was your fault for being attacked. The victim is always guilty.
If you're willing to rate FF6 as a musical artistic high, then you earn yourself the ranking of fanboy.
Sure, Nobuo (sp?) may have done a decent job with the technology available at the time, but it was more an impressive technical achievement than an artistic one.
As an _avid_ collector of all lo-fi electronic music from personal computers and game systems, (http://kmods.dyndns.org..) I understand the temptation to declare nostalgic favourites as artistically brilliant. However, Final Fantasy Six had some enjoyable themes, and a certain amount of breadth, but the execution and finesse were sorely lacking: when compared to the music world at large.
Okay, I can see that you have a different kind of work environment than that which I've been in, but so far the concrete requirements as I understand them are:
coordination of a number of involved parties
ability to pass an issue between, or share an issue among members of different departments
ability to discuss and work on the issue as it progresses and is discussed by the several members.
I still don't see how a decent ticket tracking system doesn't address these. Most of them include a series of events which occur on the ticket, which can be requests, objections, dicussions, permissions, or what have you. They pretty much all feature subscription lists which allow all involved parties to receive emails of updates. A good ticketing system will allow you to control which updates are broadcast to who, and which are not. They pretty much all feature some kind of web front end for polling for current status if the pushed emails are not enough.
I like Roundup myself because it integrates the handling of tickets and the discussing of issues in email into a single activity. I also like it because it isn't overly complicated, and thus is a joy to use, and thus people will tend to use it to document their work better.
Speaking as a sysadmin who's deployed such a system, I'm pretty unclear as to why support-style ticket tracking doesn't work for you. Sure, some systems aren't well featured, but most should be a perfect fit for request tracking. You get issue assignment, updates, web viewability, email notification, etc.
The main thing that's different between requests and support problems is that you can ignore a request for nearly forever and have that be the correct response (low priority etc.) but most ticket/request systems don't hardcode any logic that makes this an issue.
Maybe if you were aware of the history of Psion, you would realize that their home-grown OS had high levels of productivity and usefuleness/data intergchange for over a decade.
The frowny face at Psions with WinCE isn't just anti-microsoft bigotry, it's a userbase who was satisfied who has now been given a bait-and-switch.
Firstly, you can set Linux up differently for different systems. An embedded system need not use the same init as a server or desktop, and probably already doesn't, if the engineers know what they're doing.
Secondly, the Python runtime isn't going to break. This kind of application just isn't going to strain it at all.
But, you're right of course. Adding all this complexity and logic to init seems sketchy. For it to have any chance of reliabiliy, the interfaces and logic have to be very narrowly and simply defined, and that's not the impression I'm getting out of this incomplete description.
the problem is that now I have to have python installed with all of it's megs of space just to run the fscking init. I was bad enough that I had to install perl for this a while back. Pretty soon I'll need a 60G drive to install the base system. Hmmm, sound like another OS I've heard of.
For starters, you don't need all of python installed to run a python program, there's a python compiler which can bundle all the necessary components into a single executble file. So we can toss that argument out.
But more importantly, this is a straw man. The problem was that the grandparent was spewing nonsense about VM startup times that had no relation to reality, which was disproved. I don't like this idea of an init system any better than you do.
The problem isn't python, but sysadmin-unfixable binary network interfaces and a lot of sysadmin-inaccessable frameworks without a clear explanation of any particular benefit.
If you're communicating to another system via TCP/IP in a deterministic fashion, as part of an overall realtime system, this is crucial.
You may point out that this is insanity given the nature of ethernet, etc. but in a controlled environment it can be accomodated, and rewriting all the functionality provided by UDP etc. is not necessarily a fun afternoon project.
In some environments, there can also be the issue of getting io to the devices, for example a torpedo may want to use the io system to send data to a flash file system so that in the event of a reboot it can continue where it left off after a 200ms delay. Buffering this in memory and waiting for the task to be scheduled is not a very good option.
These hybrid solutions can be very unpleasant to use, with issues like the tcp stack being inaccessable to realtime code.
Interrupt latency is an important aspect of the total determinism picture, but if you want a moderately complex application to run in a deterministic fashion, RTLinux may or may not be able to meet your needs.
I would argue that ram is getting cheaper faster than Linux is getting bigger. How large is a single surface mount DRAM these days? For this reason, I think Linux will become steadily more applicable to more deeply embedded applications.
This doesn't, of course, invalidate your claim that Linux is currently too big for many situations.
Maybe I didn't read the right articles, but I saw some belief that the GPL kernel might not mix well with the embedded world, and a perception of Linux being embraced by competitors, which caused them to try the other route: BSD.
I didn't see any kind of "Linux is no good" message coming from WRS. Maybe I missed some clueless sales-drone speeches?
The people you see making the pro-linux statements today: especially Fiddler, were making similar noises around the time I left, back in 1999. The attitude hasn't fundamentally changed, they just tried other avenues and they didn't work.
WRS has long had an idiology that the runtime is not the important piece, but that the tools are where the major development value is. This stems from the origin of the company as a tools provider for VRTX. As a result, they've supported multiple runtimes over the course of the company, at times runtimes provided by alternate vendors. Thus, the Linux thing isn't new.
What might be new is that the general open source movement is providing more and more sophisticated developer tools for free, such that their custom-packaging of GCC and gui project manager/debugger/etc aren't worth the boatload of cash they're used to charging for it.
Back when I was at Windriver, me and another guy over in tech support tried to get Tornado over to Linux, but while we were attempting it, management was deciding to deprecate the other UNIX builds and was busy creating dependencies on the registry and MFC. At the time X libs weren't generally reentrant which was a blocker.
We got sidetracked and the build stagnated and we never did that final 20%. It would have been so easy with just one person doing it full time...
In practice, haters of python whitespace are inevitably users who remember bad whitespace experiences from other systems. Whitespace on python is, by contrast, a good experience. Try it and you'll see.
Slashdot Mirror
Offtopic, but... Summer of this year seems alright.
jrodman@Skonnos:~> man info
Reformatting info(1), please wait...
INFO(1) User Commands INFO(1<)
NAME
info - read Info documents
[...]
General Public License. For more information about these matters, see
the files named COPYING.
info 4.6 June 2003 INFO(1)
I'm confused here. Is ACT a specific application or a class of tools. Are you certain there is nothing that can work for sales forces right now on linux whether it be web-based, in-house ports, or some tool built on top of vantive, scopus, or a similar cross-platform tool?
Heck, on my bicycle I typically pull entirely off the road to the right (onto the sidewalk, dirt whatever) when an emergency vehicle is approaching.
Partly I assume I'm less visible, but partly it just seems retarded not to get out of the way. It's sad that most vehicles don't even START to pull over until they're sure that the siren is coming right for them.
Maybe if they raised the speed limit everybody would drive the speed limit.
Or maybe they'd all drive even faster. I daresay that's the more believable outcome given what has happened with the raising of highway speed limits.
A stable framerate is soo much more pleasing aesthetically. Variable framerates are really distracting and make me think about the engine and the software and the hardware, instead of being immersed in the game.
Unfortunately techs are usually poorly equipped to negotiate skillfully, a fact I learned personally when my scum-of-a-boss-who-I-thought-was-a-friend ripped me off for thousands because I didn't know how to negotiate properly. For years I was bitter, until I started checking out books and audio tapes on how to negotiate effectively. Bottom line: it was my fault I got ripped off.
Of course. It was your fault for being attacked. The victim is always guilty.
I like to get security issues resolved within a few hours of the problem being announced.
Usually this can be accomplished in minutes without disruption.
That humans use the exact same algorithms as computers do is not an argument, it is empty supposition with pretty much no basis at all.
Possibly difficult to distinguish? Okay.
Arbitrary? Hardly.
If you're willing to rate FF6 as a musical artistic high, then you earn yourself the ranking of fanboy.
..) I understand the temptation to declare nostalgic favourites as artistically brilliant. However, Final Fantasy Six had some enjoyable themes, and a certain amount of breadth, but the execution and finesse were sorely lacking: when compared to the music world at large.
Sure, Nobuo (sp?) may have done a decent job with the technology available at the time, but it was more an impressive technical achievement than an artistic one.
As an _avid_ collector of all lo-fi electronic music from personal computers and game systems, (http://kmods.dyndns.org
Oh come now. The difference between computation and intelligence is obvious. The open question is whether you can construct one out of the other.
Okay, I can see that you have a different kind of work environment than that which I've been in, but so far the concrete requirements as I understand them are:
I still don't see how a decent ticket tracking system doesn't address these. Most of them include a series of events which occur on the ticket, which can be requests, objections, dicussions, permissions, or what have you. They pretty much all feature subscription lists which allow all involved parties to receive emails of updates. A good ticketing system will allow you to control which updates are broadcast to who, and which are not. They pretty much all feature some kind of web front end for polling for current status if the pushed emails are not enough.
I like Roundup myself because it integrates the handling of tickets and the discussing of issues in email into a single activity. I also like it because it isn't overly complicated, and thus is a joy to use, and thus people will tend to use it to document their work better.
Speaking as a sysadmin who's deployed such a system, I'm pretty unclear as to why support-style ticket tracking doesn't work for you. Sure, some systems aren't well featured, but most should be a perfect fit for request tracking. You get issue assignment, updates, web viewability, email notification, etc.
The main thing that's different between requests and support problems is that you can ignore a request for nearly forever and have that be the correct response (low priority etc.) but most ticket/request systems don't hardcode any logic that makes this an issue.
My personal favourite is roundup.
Maybe if you were aware of the history of Psion, you would realize that their home-grown OS had high levels of productivity and usefuleness/data intergchange for over a decade.
The frowny face at Psions with WinCE isn't just anti-microsoft bigotry, it's a userbase who was satisfied who has now been given a bait-and-switch.
Firstly, you can set Linux up differently for different systems. An embedded system need not use the same init as a server or desktop, and probably already doesn't, if the engineers know what they're doing.
Secondly, the Python runtime isn't going to break. This kind of application just isn't going to strain it at all.
But, you're right of course. Adding all this complexity and logic to init seems sketchy. For it to have any chance of reliabiliy, the interfaces and logic have to be very narrowly and simply defined, and that's not the impression I'm getting out of this incomplete description.
For starters, you don't need all of python installed to run a python program, there's a python compiler which can bundle all the necessary components into a single executble file. So we can toss that argument out.
But more importantly, this is a straw man. The problem was that the grandparent was spewing nonsense about VM startup times that had no relation to reality, which was disproved. I don't like this idea of an init system any better than you do.
The problem isn't python, but sysadmin-unfixable binary network interfaces and a lot of sysadmin-inaccessable frameworks without a clear explanation of any particular benefit.
That's not necessarily true.
If you're communicating to another system via TCP/IP in a deterministic fashion, as part of an overall realtime system, this is crucial.
You may point out that this is insanity given the nature of ethernet, etc. but in a controlled environment it can be accomodated, and rewriting all the functionality provided by UDP etc. is not necessarily a fun afternoon project.
In some environments, there can also be the issue of getting io to the devices, for example a torpedo may want to use the io system to send data to a flash file system so that in the event of a reboot it can continue where it left off after a 200ms delay. Buffering this in memory and waiting for the task to be scheduled is not a very good option.
These hybrid solutions can be very unpleasant to use, with issues like the tcp stack being inaccessable to realtime code.
Interrupt latency is an important aspect of the total determinism picture, but if you want a moderately complex application to run in a deterministic fashion, RTLinux may or may not be able to meet your needs.
Was it also proven by this tv show that the cause of the ocean gas was completely unrelated to any kind of impacts?
For the future, link to or provide details of any sort of discovery claims, lest they be dismissed out of hand.
I would argue that ram is getting cheaper faster than Linux is getting bigger. How large is a single surface mount DRAM these days? For this reason, I think Linux will become steadily more applicable to more deeply embedded applications.
This doesn't, of course, invalidate your claim that Linux is currently too big for many situations.
Maybe I didn't read the right articles, but I saw some belief that the GPL kernel might not mix well with the embedded world, and a perception of Linux being embraced by competitors, which caused them to try the other route: BSD.
I didn't see any kind of "Linux is no good" message coming from WRS. Maybe I missed some clueless sales-drone speeches?
The people you see making the pro-linux statements today: especially Fiddler, were making similar noises around the time I left, back in 1999. The attitude hasn't fundamentally changed, they just tried other avenues and they didn't work.
WRS has long had an idiology that the runtime is not the important piece, but that the tools are where the major development value is. This stems from the origin of the company as a tools provider for VRTX. As a result, they've supported multiple runtimes over the course of the company, at times runtimes provided by alternate vendors. Thus, the Linux thing isn't new.
What might be new is that the general open source movement is providing more and more sophisticated developer tools for free, such that their custom-packaging of GCC and gui project manager/debugger/etc aren't worth the boatload of cash they're used to charging for it.
Back when I was at Windriver, me and another guy over in tech support tried to get Tornado over to Linux, but while we were attempting it, management was deciding to deprecate the other UNIX builds and was busy creating dependencies on the registry and MFC. At the time X libs weren't generally reentrant which was a blocker.
..
We got sidetracked and the build stagnated and we never did that final 20%. It would have been so easy with just one person doing it full time.
Yes, leeches all.
It isn't like they wrote the manual for GDB or contributed significantly towards C++ support in GCC. Oh wait, they did.
Right. Starting python's "Virtual Machine" takes an ungodly amount of time, I mean, look at this:
Here I am on my machine, there aren't any python processes running.
jrodman@Skonnos:~> ps aux |grep python
(Yes, there could be tools written in python which don't have it in the process name, but there aren't.)
Okay, here's my python program:
jrodman@Skonnos:~> cat test.py
#!/usr/bin/python
print "hello world"
Okay, here I am running my program:
jrodman@Skonnos:~> time python test.py
hello world
real 0m0.050s
user 0m0.040s
sys 0m0.010s
Wow, you're right, it really does take 20 full seconds to start up a "virtual machine". Well, maybe 1/20th of a second. Close enough.
In practice, haters of python whitespace are inevitably users who remember bad whitespace experiences from other systems. Whitespace on python is, by contrast, a good experience. Try it and you'll see.