Pascal was a nice language, but working with strings was horrible.
You had to create all your strings the same length, because another length was interpreted as another type, so you could not pass strings of different length between procedures.
With Borland Turbo-Pascal that was of course possible, but it did only run on CPM/DOS systems.
For servers : the WANG VS system (and probably other systems like AS/400 and mainframes), when a process crashed, the memory dump was written to a printer.
Of course, these machines never crash, only processes on them (and then mostly due to programmer errors).
Right now, we are having an issue with sublicensed software, which is part of a compiler we use to produce images for embedded software.
Somewhere down the compile chain, there is a DOS tool with the standard DOS limits and problems : it can only use a 127 byte command line, and it is written using the single-user, single-tasking paradigm.
The result is that it only knows one temporary directory (\tmp) and two names for its output files.
Because of that, I cannot start two builds of different products at the same time, because they might interfere with each other through this tiny program, of which nobody seems to have the source code.
This means that instead of having done two builds in 4 hours, we now have to look at the priorities, build one target first, and then the other, which means an eight hour delay.
And we are working on Windows, so no nice chroot environment ore something like that (and please do not start on VMWare, our IT department is moronic and backwards).
In the last 10 months I came to the conclusion that I could get a whole slew of printers to work with Debian, including Winprinters like the HP 710C and the Lexmark 3200.
There are two packages for installing ghostscript printer drivers, one is call gs-fsf or gs-gnu or something and then there is an additional package.
A study paid for by a company, touting that companies product as the best, is just a commercial.
In some magazines and TV you sometimes see (here in Europe (Belgium and Holland)) in a small type "Commercial information".
I think it is frowned upon to pose such things as not being commercial, I think that it would even be possible to file a complaint against such things.
The thing that triggers me here is a scene from Spitting Image, where a Leonard Nimoy/Spock puppet stands behind Marc Antony, and when he utters the phrase, he touches Spock's ears. Then Spock applies the Vulcan death grip to Marc Antony.
It had something to do with Leonard Nimoy wanting to act in Shakespeare plays.
Atomicity at the file system level exists already a long time. It is called indexed-sequential files. This is handled by ISAM/VSAM and likewise files.
All minicomputers had (have (AS/400)) something and mainframes will surely have it.
This is a transactional system implemented at the OS level.
I have only experience with this on the WANG VS minicomputer platform, but there the transactioning was also implemented at the filesystem (or OS level).
With the advent of Un*x like operating systems, this functionality disappeared from the file system, and third party packages where needed to implement it. And of course the most logical course was to do this through the database.
Yes. I have done some pretty COBOL coding and maintenance, and I was able to create simpler algorithms to do things faster than previous programmers who thought they were smart.
I always tried to find a mathematical underground, implement that in the simplest way and was able to get dramatic speedups, without even intentionally tweaking code for performance.
We got an application here which compiles IDL files into components and headers, but on a large scale.
The people who created this tool, did this with a background of embedded processing and compiler writing, but they had no idea of of batch processing issues or porcessing large files.
So instead of writing their program to use intermediate files in sequential way, they just totally used up all memory, including swap because they thought that was efficient.
They also wrote the application from a single-user desktop point of view. What they did not realise whas that we had to run multiple jobs using the same tool on one machine.
The result was that instead of using the harddisk of the system in an efficient manner, we used the memory system in a very inefficient manner, resulting in significant slowdowns on builds.
I think that the people where more aware that errors could happen, and probably used proofs (tests) and double checks to make sure that they where getting the right figures.
The problem with spreadsheets is that they give people a false sense of security : whatever the computer computes must be correct.
We are running Continuus here for versioning, configuration management and problem reporting.
This application suite is not complete. We have written a whole lot of software around it so that it can optimally be used in our processes.
One of the things that we have and that probably can aid Bugzilla is an overview of subprojects and their outstanding and resolved bugs. But of course that means having a more formal way of working between Bugzilla and the kernel developers.
Another part of the processes here which makes that more people are involved around certain bugs, is the use of control boards which decide on problems and requests.
Of course, this also means a more formal way of working.
One solution could maybe be the use of private IRC channels for calling together meetings if necessary.
However, one aspect of a meeting which then should not be forgotten is to have someone write a report and post it along the problem reports.
I have been thinking about the ways for commercial delivery of software for Linux.
What happens when you install software on Windows , be it drivers or applications ?
Insert CD/Floppy
Autorun/Click Setup
A wizard starts up
User interacts with wizard
Wizard interacts with system
The same could be done in Linux through the use of a unified interface against apt/urpmi/yum.
This way the commercial developer could have a standard for creating his wizards, and through interaction with the dependency resolving systems be sure that the right packages will be installed by the OS itself (which btw. also happens under Windows when it asks for your installation disks).
Insert CD/Floppy
Autorun/Click Setup
A wizard starts up
User interacts with wizard
Wizard interacts with package system interface
The advantage is that whatever way the user installs his normal software (network connection, DVD, CD, local mirror) will also be used through the installation wizard.
I think that the problem more has to do with the fact that programmers don't tend to have people with graphical skills in their environment.
My father can draw (as in oil painting, water painting, etching, sketching, ink art, etc).
After he is finished doing the electricity for my brother's house, I will go with him over techniques to produce icons, because I would like him help to create a new set of icons for WebMin, which the Webmin people would then get.
If you believe that OSS can provide what the world needs, yo uhave a lot to learn about business. The cost of OS licenses is trivial. The cost of support and integration is not. More importantly, the cost of training - and ongoing training of new hires - can be daunting. Face it - IT is a necessary evil in a competitive market. It's like accounting (in non-accounting firms), or purchasing, or administrative support - a cost which is necessary but does not provide income.
Here lies the error in many companies, because management does not understand, and IT people are not taught :
You should actively use and investigate IT to leverage your business processes.
If you do only a 'little' customisation, then you are not going far enough. If your IT people are more busy keeping the infrastructure stable, than analysing business processes and streamlining customisation, then sure they are a cost.
If they understand the business and are able to make other people more productive, then they are not a cost anymore, they can have positive value.
As for using COTS, it is not bad, but if you act like above, then you will notice after five years that you have written more software around the existing package than there was originally in the package.
The COTS is only the engine, which can be difficult to build, so a purchasing decision can be positive, but such a solution cannot work wonders, because it is written with a finite set of scenarios and procedures in mind. A healthy, innovative business' (with the true meaning of the word) processes will be evolved and adapted, and that means that you will move more and more to the core functionalities of the COTS, and that you will write more and more around the superfluous functionalities of the COTS.
Choosing a product and then adapting your business processes around it, means that you try to shoehorn yourself into a straightjacket, and that it is your vendor who dictates how your business processes will run.
I have worked in mid-sized business, and all our software ran on one minicomputer, to provide services for twenty people.
I worked there not as a technician, but as an analyst/programmer.
Hiring someone to keep your PC's and network up to date is just costing the company, there are no added values.
Being able to hire a programmer, because all your software runs on a stable platform, and all your hardware is stable, makes it possible to add more value to the business processes.
Why would a mid-sized business want to hire an MCSE ? They are not programmers, they can't add any value to a business.
Slashdot Mirror
Pascal was a nice language, but working with strings was horrible.
You had to create all your strings the same length, because another length was interpreted as another type, so you could not pass strings of different length between procedures.
With Borland Turbo-Pascal that was of course possible, but it did only run on CPM/DOS systems.
Good question, but I would extend it to : why choose Pascal over Ada (or otherwise) ?
It seems that amidst a whole plethora of languages, those are the only (most-used) descendants of Algol-type languages still in use.
You seem to have rather large bytes...
For servers : the WANG VS system (and probably other systems like AS/400 and mainframes), when a process crashed, the memory dump was written to a printer.
Of course, these machines never crash, only processes on them (and then mostly due to programmer errors).
Stallman is right.
Right now, we are having an issue with sublicensed software, which is part of a compiler we use to produce images for embedded software.
Somewhere down the compile chain, there is a DOS tool with the standard DOS limits and problems : it can only use a 127 byte command line, and it is written using the single-user, single-tasking paradigm.
The result is that it only knows one temporary directory (\tmp) and two names for its output files.
Because of that, I cannot start two builds of different products at the same time, because they might interfere with each other through this tiny program, of which nobody seems to have the source code.
This means that instead of having done two builds in 4 hours, we now have to look at the priorities, build one target first, and then the other, which means an eight hour delay.
And we are working on Windows, so no nice chroot environment ore something like that (and please do not start on VMWare, our IT department is moronic and backwards).
Fuck closed-source software.
Memory is nowadays always addressed in bytes.
2^64 bytes, instead of 2^64 64bit words.
And it could still be fitted in a 64 pin package.
Hey, this is great. I got that idea years back, when none of the technology that could made it possible even existed or was too expensive.
I always thought about using a kind of radar though. I got the idea from reading about how anti-aircraft systems work.
Did he write the fly recognition software himself ?
Great feat implementing this.
Which printer do you have specifically ?
In the last 10 months I came to the conclusion that I could get a whole slew of printers to work with Debian, including Winprinters like the HP 710C and the Lexmark 3200.
There are two packages for installing ghostscript printer drivers, one is call gs-fsf or gs-gnu or something and then there is an additional package.
A study paid for by a company, touting that companies product as the best, is just a commercial.
In some magazines and TV you sometimes see (here in Europe (Belgium and Holland)) in a small type "Commercial information".
I think it is frowned upon to pose such things as not being commercial, I think that it would even be possible to file a complaint against such things.
The thing that triggers me here is a scene from Spitting Image, where a Leonard Nimoy/Spock puppet stands behind Marc Antony, and when he utters the phrase, he touches Spock's ears. Then Spock applies the Vulcan death grip to Marc Antony.
It had something to do with Leonard Nimoy wanting to act in Shakespeare plays.
When did adding overhead become the mark of skill?
When Microsoft started dominating the market.
Atomicity at the file system level exists already a long time. It is called indexed-sequential files. This is handled by ISAM/VSAM and likewise files.
All minicomputers had (have (AS/400)) something and mainframes will surely have it.
This is a transactional system implemented at the OS level.
I have only experience with this on the WANG VS minicomputer platform, but there the transactioning was also implemented at the filesystem (or OS level).
With the advent of Un*x like operating systems, this functionality disappeared from the file system, and third party packages where needed to implement it. And of course the most logical course was to do this through the database.
I have them at home in my (dead tree) Scientific American collection.
Yes. I have done some pretty COBOL coding and maintenance, and I was able to create simpler algorithms to do things faster than previous programmers who thought they were smart.
I always tried to find a mathematical underground, implement that in the simplest way and was able to get dramatic speedups, without even intentionally tweaking code for performance.
He is certainly not alone in his thinking.
We got an application here which compiles IDL files into components and headers, but on a large scale.
The people who created this tool, did this with a background of embedded processing and compiler writing, but they had no idea of of batch processing issues or porcessing large files.
So instead of writing their program to use intermediate files in sequential way, they just totally used up all memory, including swap because they thought that was efficient.
They also wrote the application from a single-user desktop point of view. What they did not realise whas that we had to run multiple jobs using the same tool on one machine.
The result was that instead of using the harddisk of the system in an efficient manner, we used the memory system in a very inefficient manner, resulting in significant slowdowns on builds.
I think that the people where more aware that errors could happen, and probably used proofs (tests) and double checks to make sure that they where getting the right figures.
The problem with spreadsheets is that they give people a false sense of security : whatever the computer computes must be correct.
We are running Continuus here for versioning, configuration management and problem reporting.
This application suite is not complete. We have written a whole lot of software around it so that it can optimally be used in our processes.
One of the things that we have and that probably can aid Bugzilla is an overview of subprojects and their outstanding and resolved bugs. But of course that means having a more formal way of working between Bugzilla and the kernel developers.
Another part of the processes here which makes that more people are involved around certain bugs, is the use of control boards which decide on problems and requests.
Of course, this also means a more formal way of working.
One solution could maybe be the use of private IRC channels for calling together meetings if necessary.
However, one aspect of a meeting which then should not be forgotten is to have someone write a report and post it along the problem reports.
xprint does this fine...
ESR's comments where not about adding a printer, but about setting up CUPS to be able to share and print on the network.
And he was right, I had exactly the same problem as he, because the default CUPS installation restricts the usage to the local address 127.0.0.1.
You cannot change that from the web interface, you have to delve through the CUPS configuration file.
I have been thinking about the ways for commercial delivery of software for Linux.
What happens when you install software on Windows , be it drivers or applications ?
The same could be done in Linux through the use of a unified interface against apt/urpmi/yum.
This way the commercial developer could have a standard for creating his wizards, and through interaction with the dependency resolving systems be sure that the right packages will be installed by the OS itself (which btw. also happens under Windows when it asks for your installation disks).
The advantage is that whatever way the user installs his normal software (network connection, DVD, CD, local mirror) will also be used through the installation wizard.
I think that the problem more has to do with the fact that programmers don't tend to have people with graphical skills in their environment.
My father can draw (as in oil painting, water painting, etching, sketching, ink art, etc).
After he is finished doing the electricity for my brother's house, I will go with him over techniques to produce icons, because I would like him help to create a new set of icons for WebMin, which the Webmin people would then get.
My doctor uses a printer (well, not on visit of course).
If you believe that OSS can provide what the world needs, yo uhave a lot to learn about business. The cost of OS licenses is trivial. The cost of support and integration is not. More importantly, the cost of training - and ongoing training of new hires - can be daunting. Face it - IT is a necessary evil in a competitive market. It's like accounting (in non-accounting firms), or purchasing, or administrative support - a cost which is necessary but does not provide income.
Here lies the error in many companies, because management does not understand, and IT people are not taught :
You should actively use and investigate IT to leverage your business processes.
If you do only a 'little' customisation, then you are not going far enough. If your IT people are more busy keeping the infrastructure stable, than analysing business processes and streamlining customisation, then sure they are a cost.
If they understand the business and are able to make other people more productive, then they are not a cost anymore, they can have positive value.
As for using COTS, it is not bad, but if you act like above, then you will notice after five years that you have written more software around the existing package than there was originally in the package.
The COTS is only the engine, which can be difficult to build, so a purchasing decision can be positive, but such a solution cannot work wonders, because it is written with a finite set of scenarios and procedures in mind. A healthy, innovative business' (with the true meaning of the word) processes will be evolved and adapted, and that means that you will move more and more to the core functionalities of the COTS, and that you will write more and more around the superfluous functionalities of the COTS.
Choosing a product and then adapting your business processes around it, means that you try to shoehorn yourself into a straightjacket, and that it is your vendor who dictates how your business processes will run.
I have worked in mid-sized business, and all our software ran on one minicomputer, to provide services for twenty people.
I worked there not as a technician, but as an analyst/programmer.
Hiring someone to keep your PC's and network up to date is just costing the company, there are no added values.
Being able to hire a programmer, because all your software runs on a stable platform, and all your hardware is stable, makes it possible to add more value to the business processes.
Why would a mid-sized business want to hire an MCSE ? They are not programmers, they can't add any value to a business.