Reverse engineering would really be implementing the same functionality with access to all the tools, but without any documentation. I doubt if in that case Linux would really have seen the light.
Part of our federal government in Belgium is an example how cross-platform really works.
Applications are developed in Java, but are currently not running on Sun.
Peter Strickx, CTO of Fedict, is a previous Sun employee, but his viewpoint is that he should be able to switch suppliers from one day to the other (probably barring contracts) on any level. That is probably also the reason that last year, he mandated the use of ODF.
In *nix systems, the system is set to default deny for all administrator tasks and access. Using sudo one can give users small specific tasks.
The problem for MS is that due to their backward compatibility, their policy has always been default allow, and now they have to do the inverse from *nix.
The competition policy in Europe has nothing to do with protectionism. It is trying to make the European market open and transparent.
I do not know about other European countries, but when Karel Van Miert was commissioner (he is from Belgium), there where several cases of Belgium companies being punished.
Besides, most software companies profiting from breaking MS monopoly would be American ones. Europe does not really have a computer hardware industry, and I can on the top of my head only name SAP and Software AG as big European software companies (there used to be Baan to). For the rest, it is all relatively big companies either doing services or small compenies building extremely niche software.
Isn't the problem with growth, that eventually you will reach a ceiling, unless you are able to drive out competitors, in which case you become a monopoly ?
Re:Will anyone gain anything from this? Not Linux
on
The End is Nigh for XP
·
· Score: 1
I think that IT administration does not bring any real value to a company. It is just making sure that people can do their jobs by providing infrastructure. However, this is something that can be outsourced, just like electricity, water and cleaning. The more stable the infrastructure is, the less it costs.
IT administration thus brings no value in itself, nor helps it people to do their job better. For that you need analysis, automation and education.
Analysis : what are our business processes and how can we help people to do their better and/or faster ?
Automation : how will these things be implemented ?
Education : how can we help understand people how these tools can help them do a better job ?
IT administration is pure overhead, and should be kept down as much as possible. Things which help here are quality of all components involved.
Quality of network connections, so that no time is lost searching for buggy cables.
Quality of network hardware.
Quality of computer hardware.
Quality of systems software.
Quality of applications.
Doing a little upfront investigation into the quality of these things, and investing some more money into hardware and installation, will go a long way of relieving IT infrastructure from the babysitter syndrome.
The problem with the security model of Windows is that it is too complex. It is very difficult to check with a program.
In Unix, you just do 'find . -perm...'.
I use a bunch of servers for builds which should all be completely the same. After a monthly patch (which is done by IT, not myself), two of them cannot execute the DELTREE.EXE command anymore from a Windows Service. I get permission denied. If I compare its permissions with those on other servers, they are completely the same.
The only security model that I have ever met that was really safe, good and understandable was that of Netware.
It simply reflects the quality of the team behind it.
I think that this relates to all software packages of comparable complexity.
Unfortunately, because of the complexity, most managers do not understand what benefits such packages can bring when supported by good programmers and analysts, and thus do not hire such people.
As an example, the company where my wife works uses Axapta and is now implementing Sharepoint. I think it has a size of 200 to 300 people, but they only have 2 people for IT, and their only job is administration and support.
However, from the descriptions she gives me of their usage of Axapta, it seems that this company has bought it believing that such a package is immediately usable and nothing needs to be done. I think that this package is severely under used.
My experience tells me that the administration and support part could be outsourced almost completely, and that these two people should be busy analysing, optimising and implementing their business processes on top of Axapta. One blatant example in this case is that the Axapta system is used by purchasing and sales, but not by production.
I think that the lessons for anyone wanting to purchase complex software are these :
Software is hard.
Understanding and knowing your business process is hard.
Mapping the bought software to your business process is even harder.
You WILL need tailoring of your business software.
You need people with technical, analytical and basic business skills to help use this software.
Mapping your business process to the bought software is hard, risky and expensive.
If you think that purchased software will immediately do what you need, then you are fooling yourself, you will be fooled by the salesmen, and you will be disappointed (but probably not admit it) by the final results.
I have one example here. It is a small DOS program, called convert.exe, which somehow does transformations in the linking phase of ELF files in a cross platform environment.
From what I know, VxWorks licensed this from another company, which does not have the sources anymore.
From time to time this program crashes, due to the output generated by the Tornado compiler. This renders our daily builds unusable for particular targets, which is definitely a show stopper for testing daily our embedded software.
I am in somewhat the same position, but it is recognised here that our Unix servers are a necessity. So everyone in our department gets WRQ Reflection as a standard application, and we run Samba on one of the Unix servers.
Looking at the way IT companies which support/partner with MS software act, it seems that there are only two possible ways why they do it.
In the first instance, they don't know anything about computers or software, and gladly drink the MS Kool-Aid. Support from this kind of company is throwing away money.
In the second instance, they do know about computers or software, and thus also know that MS software is more costly. In that case they are purposefully using the clients ignorance as a money source.
I have only moved my father to Linux, but it was worth a while.
I started with dual booting his Win95 system to get rid of Internet Explorer and mail issues. I created three partitions, so that he could exchange data between the two systems. He used Linux for connectivity and Win95 for the rest.
Some time later, I prepared a complete Linux system for him (Debian+ KDE 3.5). We kept his old system with a network connection, so that he could access it using VNC.
The only things for which he calls is to know about the functionality of programs. He uses OO.o, GIMP, QCad, Sylpheed, and is able to use his printer, scanner and camera. If he calls because he has problems, he either finds it himseld, or I am able to trace it together with him, and its always because he has forgotten something (which would be the same under Windows).
This particular migration took 6 years. This was because a whole lot of desktop functionality was missing and was only added incrementally. The last one to enter (about a year, a year and a half ago) was support for USB drives in KDE (it was available longer before in GNOME).
I think, currently, the only difficult thing in migrating someone from Windows to Linux, is to have a usage, software and hardware inventory upfront, and based upon that finding out what the possible options are for hardware support, software equivalents and data migration.
I started with assembly, because I got nothing else. It was 1980/1981, I was fourteen years old, and a computer was just too expensive. However, the library got this fantastic book from Dirksen, which laid out microprocessors and microcomputers with the 8080. There was also an engineer in our neighbourhood who had designed and built a microcomputer himself, so I could ask this person questions. Mostly, I read books about microcomputers and assembly.
However, I did not have the pleasure to really start programming until I was 18, and in my last year of highschool in Electronics. We got 8080 SDK's. A couple of months later I was able to buy my first computer, a Sinclair ZX Spectrum. Until then, I had not programmed in any high-level language.
I am even designing my system from the ground up, using a microprogrammable architecture and standard logic components.
It should become a 12-bit system. Don't know when I will get a working implementation, because for me this project is more than designing a 12-bit system : I have written simulations of my basic components in Common Lisp, so part of my time was also spent learning Common Lisp, writing component implementations and test harnesses, and trying to grok how to implement a simulation on bus/wire level.
This 12-bit system is necessary to gather basic knowledge and tools, because ultimately I want to go to something larger, for which I probably will need FPGA technology.
Well, I'll see. I am busy on this since August 2006, and I have learned a lot in the meantime.
Additional goals for a wider implementation are porting LCC to the architecture, or try to obtain an architecture which could run Scheme on the bare metal.
In this whole thread and the previous comments, I cannot understand that these companies stay afloat. They all have too much money on their hands.
In 1997-1998, I worked for a small transport company, where the boss was someone who had built the company up from the ground (that possibly explains it), starting with trucking himself, and building a company which was specialised in liquid and powder transport.
When the system went down (not so often : WANG VS minicomputers were robust and thrustworthy), the first thing that he did was calculate how much the downtime would cost him.
I think there were two reasons for this. The first one being that since he built up the company himself, he knew the costs and advantages of everything, the second was because of being in transport, margins were not big.
I now program severn years in Perl, and yes, I have to tolerate its eccentricities, but for me the only language I would be willing to trade it for is Common Lisp, not Python.
And I know that on comp.lang.lisp there are some people who find Python a better Lisp, but I have done some small projects in Python, and I am now doing a large project in Common Lisp, and though I am still learning Common Lisp, I just like it better in every way.
I cannot explain it completely, it is a combination of factors, starting with the fact that the things I do in Perl now, have been influenced by "How To Design Programs", the fact that Common Lisp always has a compiler, that through type assertions a Common Lisp program can be highly optimized by the compiler, that there are two nice Emacs environments for Lisp, SLIME and ILISP, that it is a relief from the line noise that is needed in Perl (but Python has also line noise : I hate the fact that dictionary keys have to be quoted (that is also why I do not like PHP)), that the lambda functions in Perl and Common Lisp are equally powerful, and not restricted as in Python.
So it seems that PMD is something like lint, splint or QAC, but then for Java.
Where I work we use QAC on C code (embedded development), to obtain information and statistics on such things. However, there is also an extensive code review practice set up.
Slashdot Mirror
Is the command line in Linux so hard to use?
So, he did work from existing documentation.
Reverse engineering would really be implementing the same functionality with access to all the tools, but without any documentation. I doubt if in that case Linux would really have seen the light.
Part of our federal government in Belgium is an example how cross-platform really works.
Applications are developed in Java, but are currently not running on Sun.
Peter Strickx, CTO of Fedict, is a previous Sun employee, but his viewpoint is that he should be able to switch suppliers from one day to the other (probably barring contracts) on any level. That is probably also the reason that last year, he mandated the use of ODF.
Beware of the complicators
In *nix systems, the system is set to default deny for all administrator tasks and access. Using sudo one can give users small specific tasks.
The problem for MS is that due to their backward compatibility, their policy has always been default allow, and now they have to do the inverse from *nix.
Building your OS to the POSIX spec is not the same as reverse engineering.
The competition policy in Europe has nothing to do with protectionism. It is trying to make the European market open and transparent.
I do not know about other European countries, but when Karel Van Miert was commissioner (he is from Belgium), there where several cases of Belgium companies being punished.
Besides, most software companies profiting from breaking MS monopoly would be American ones. Europe does not really have a computer hardware industry, and I can on the top of my head only name SAP and Software AG as big European software companies (there used to be Baan to). For the rest, it is all relatively big companies either doing services or small compenies building extremely niche software.
Isn't the problem with growth, that eventually you will reach a ceiling, unless you are able to drive out competitors, in which case you become a monopoly ?
I think that IT administration does not bring any real value to a company. It is just making sure that people can do their jobs by providing infrastructure. However, this is something that can be outsourced, just like electricity, water and cleaning. The more stable the infrastructure is, the less it costs.
IT administration thus brings no value in itself, nor helps it people to do their job better. For that you need analysis, automation and education.
IT administration is pure overhead, and should be kept down as much as possible. Things which help here are quality of all components involved.
Doing a little upfront investigation into the quality of these things, and investing some more money into hardware and installation, will go a long way of relieving IT infrastructure from the babysitter syndrome.
Parent should have been modded funny, not insightful (I love the smell of satire in the morning).
The problem with the security model of Windows is that it is too complex. It is very difficult to check with a program.
In Unix, you just do 'find . -perm ...'.
I use a bunch of servers for builds which should all be completely the same. After a monthly patch (which is done by IT, not myself), two of them cannot execute the DELTREE.EXE command anymore from a Windows Service. I get permission denied. If I compare its permissions with those on other servers, they are completely the same.
The only security model that I have ever met that was really safe, good and understandable was that of Netware.
It simply reflects the quality of the team behind it.
I think that this relates to all software packages of comparable complexity.
Unfortunately, because of the complexity, most managers do not understand what benefits such packages can bring when supported by good programmers and analysts, and thus do not hire such people.
As an example, the company where my wife works uses Axapta and is now implementing Sharepoint. I think it has a size of 200 to 300 people, but they only have 2 people for IT, and their only job is administration and support.
However, from the descriptions she gives me of their usage of Axapta, it seems that this company has bought it believing that such a package is immediately usable and nothing needs to be done. I think that this package is severely under used.
My experience tells me that the administration and support part could be outsourced almost completely, and that these two people should be busy analysing, optimising and implementing their business processes on top of Axapta. One blatant example in this case is that the Axapta system is used by purchasing and sales, but not by production.
I think that the lessons for anyone wanting to purchase complex software are these :
That is why I always have a good laugh when anyone mentions backward compatibility and Microsoft in the same sentence.
I have one example here. It is a small DOS program, called convert.exe, which somehow does transformations in the linking phase of ELF files in a cross platform environment.
From what I know, VxWorks licensed this from another company, which does not have the sources anymore.
From time to time this program crashes, due to the output generated by the Tornado compiler. This renders our daily builds unusable for particular targets, which is definitely a show stopper for testing daily our embedded software.
I am in somewhat the same position, but it is recognised here that our Unix servers are a necessity. So everyone in our department gets WRQ Reflection as a standard application, and we run Samba on one of the Unix servers.
Looking at the way IT companies which support/partner with MS software act, it seems that there are only two possible ways why they do it.
In the first instance, they don't know anything about computers or software, and gladly drink the MS Kool-Aid. Support from this kind of company is throwing away money.
In the second instance, they do know about computers or software, and thus also know that MS software is more costly. In that case they are purposefully using the clients ignorance as a money source.
You should not transfer in one step.
I have only moved my father to Linux, but it was worth a while.
I started with dual booting his Win95 system to get rid of Internet Explorer and mail issues. I created three partitions, so that he could exchange data between the two systems. He used Linux for connectivity and Win95 for the rest.
Some time later, I prepared a complete Linux system for him (Debian+ KDE 3.5). We kept his old system with a network connection, so that he could access it using VNC.
The only things for which he calls is to know about the functionality of programs. He uses OO.o, GIMP, QCad, Sylpheed, and is able to use his printer, scanner and camera. If he calls because he has problems, he either finds it himseld, or I am able to trace it together with him, and its always because he has forgotten something (which would be the same under Windows).
This particular migration took 6 years. This was because a whole lot of desktop functionality was missing and was only added incrementally. The last one to enter (about a year, a year and a half ago) was support for USB drives in KDE (it was available longer before in GNOME).
I think, currently, the only difficult thing in migrating someone from Windows to Linux, is to have a usage, software and hardware inventory upfront, and based upon that finding out what the possible options are for hardware support, software equivalents and data migration.
I started with assembly, because I got nothing else. It was 1980/1981, I was fourteen years old, and a computer was just too expensive. However, the library got this fantastic book from Dirksen, which laid out microprocessors and microcomputers with the 8080. There was also an engineer in our neighbourhood who had designed and built a microcomputer himself, so I could ask this person questions. Mostly, I read books about microcomputers and assembly.
However, I did not have the pleasure to really start programming until I was 18, and in my last year of highschool in Electronics. We got 8080 SDK's. A couple of months later I was able to buy my first computer, a Sinclair ZX Spectrum. Until then, I had not programmed in any high-level language.
<joke>Young kids these days</joke>
I am even designing my system from the ground up, using a microprogrammable architecture and standard logic components.
It should become a 12-bit system. Don't know when I will get a working implementation, because for me this project is more than designing a 12-bit system : I have written simulations of my basic components in Common Lisp, so part of my time was also spent learning Common Lisp, writing component implementations and test harnesses, and trying to grok how to implement a simulation on bus/wire level.
This 12-bit system is necessary to gather basic knowledge and tools, because ultimately I want to go to something larger, for which I probably will need FPGA technology.
Well, I'll see. I am busy on this since August 2006, and I have learned a lot in the meantime.
Additional goals for a wider implementation are porting LCC to the architecture, or try to obtain an architecture which could run Scheme on the bare metal.
But I was running DR-DOS 5.0 several months before MS-DOS 5.0 came out, and it ran circles around MS-DOS 5.0.
I agree with you on the Lisp part.
Here is a nice link to Lisp and Scheme implementations on top of the JVM.
In this whole thread and the previous comments, I cannot understand that these companies stay afloat. They all have too much money on their hands.
In 1997-1998, I worked for a small transport company, where the boss was someone who had built the company up from the ground (that possibly explains it), starting with trucking himself, and building a company which was specialised in liquid and powder transport.
When the system went down (not so often : WANG VS minicomputers were robust and thrustworthy), the first thing that he did was calculate how much the downtime would cost him.
I think there were two reasons for this. The first one being that since he built up the company himself, he knew the costs and advantages of everything, the second was because of being in transport, margins were not big.
Perl Best Practices by Damian Conway and Perl::Critic.
I now program severn years in Perl, and yes, I have to tolerate its eccentricities, but for me the only language I would be willing to trade it for is Common Lisp, not Python.
And I know that on comp.lang.lisp there are some people who find Python a better Lisp, but I have done some small projects in Python, and I am now doing a large project in Common Lisp, and though I am still learning Common Lisp, I just like it better in every way.
I cannot explain it completely, it is a combination of factors, starting with the fact that the things I do in Perl now, have been influenced by "How To Design Programs", the fact that Common Lisp always has a compiler, that through type assertions a Common Lisp program can be highly optimized by the compiler, that there are two nice Emacs environments for Lisp, SLIME and ILISP, that it is a relief from the line noise that is needed in Perl (but Python has also line noise : I hate the fact that dictionary keys have to be quoted (that is also why I do not like PHP)), that the lambda functions in Perl and Common Lisp are equally powerful, and not restricted as in Python.
So it seems that PMD is something like lint, splint or QAC, but then for Java.
Where I work we use QAC on C code (embedded development), to obtain information and statistics on such things. However, there is also an extensive code review practice set up.