>As long as the usernames are the same (for the salt) you should be fine.
Ummm. No. I copy passwords to and from users all the time, and the username doesn't matter either... the first 2 bytes of the 13 character password are the salt.... I'm going out on a limb here but, the salt is NOT derived from the username, that would be inherantly insecure. It must (should, at least) be randomly selected.
Q: Is this going to be a custom version of Perl for Microsoft?
A: In a word, no. We will always use the mainstream version of Perl as our core technology. All potential work we undertake to do on the mainstream Perl source code will be achieved through open development with the community.
Q: Why is Microsoft doing this?
... FOR IMMEDIATE RELEASE
FAQ - ActiveState and Microsoft Vancouver, Canada - Update June 2nd, 1999
We want to make sure that you, as members of the Perl community, are informed on our latest efforts to advance Perl technology for Windows. We are quite excited about this development, and see it as a truly winning proposition for Perl.
Below we have attempted to answer the questions that many of you will have about this development. If you have further questions or concerns, please send them to Press@ActiveState.com
Q: What is the scope of the work that is being done?
A: ActiveState proposed many potential areas of work to Microsoft, based on feedback we have had from Perl users over the years. Microsoft accepted the items of work listed below as being important enough for them to support with funding. As a result, there are four main areas of development, all of which target the Windows platform.
The interfaces and implementation of all parts of the work that have a chance of being generally useful will be discussed amidst the Perl development community (perl5-porters@perl.org, archived at www.deja.com) for inclusion in Perl.
fork()
This implementation of fork() will clone the running interpreter and create a new interpreter with its own thread, but running in the same process space. The goal is to achieve functional equivalence to fork() on UNIX systems without suffering the performance hit of the process creation overhead on Win32 platforms.
Emulating fork() within a single process needs the ability to run multiple interpreters concurrently in separate threads. Perl version 5.005 has experimental support for this in the form of the PERL_OBJECT build option, but it has some shortcomings. PERL_OBJECT needs a C++ compiler, and currently only works on Windows. ActiveState will be working to provide support for revamped support for the PERL_OBJECT functionality that will run on every platform that Perl will build on, and will no longer require C++ to work. This means that other operating systems that lack fork() but have support for threads (such as VMS and MacOS) will benefit from this aspect of the work.
Microsoft Installer Support
Microsoft is moving towards providing improved package management facilities in Windows 2000. This aspect of the work will make the ActivePerl installer compatible with the new MSI DB, which is an important requirement for easy management of the Perl installation process on Windows 2000 systems.
Globalization
The Unicode support that Larry Wall created for Perl extends to Perl operations but not to system calls. Windows NT supports Unicode at the system-call level, and it would be natural to provide a way to enable the Unicode variants of the system calls. This allows users to create files that have names comprised of Unicode characters, for example.
This aspect of the work covers extension of the existing Unicode support to all Win32 system calls in the Perl core, for such things as file names, environment variables, command-line arguments, etc. This functionality will only be available on Windows NT and Windows 2000 systems (not on Windows 98 or similar).
The implementation for this is Windows-specific, but the interface to enable it from Perl will be general and portable to all platforms that support Unicode. This interface will be decided based on discussion with the development community. The implementation will be built over Perl's existing abstraction for system calls, which means other platforms that need to support Unicode system calls can follow the same model if they wish to do so.
It must be noted that support for Unicode will have no effect on the default behavior of Perl. It will continue to be enabled only when explicitly requested by the script with a pragma. Other existing internationalization features like locales will continue to work as they have done before.
PerlScript Performance Enhancements
Caching and cloning of compiled scripts in memory will significantly boost the performance of PerlScript running under IIS/ASP.
The implementation of this aspect will utilize the facilities for creation of multiple interpreters, but will be otherwise independent of the Perl core.
Q: Is this going to be a custom version of Perl for Microsoft?
A: In a word, no. We will always use the mainstream version of Perl as our core technology. All potential work we undertake to do on the mainstream Perl source code will be achieved through open development with the community.
Q: Why is Microsoft doing this?
A: Microsoft knows first hand that Perl is an important tool for their customers, since they are a heavy user of Perl internally. They want Perl to work well on the Windows platforms and to take advantage of platform features on Windows.
Some people have expressed fears about a potential "embrace and extend" manoeuvre by Microsoft. We would like to reassure the Perl community that we see no danger of this ever happening with Perl. Perl's development model is based entirely on open discussion of changes, and is one of the most important reasons for the dynamic evolution that Perl has enjoyed over the years. To change this would be counter-productive to any commercial entity that may have a stake in Perl's success.
It seems more to be like Microsoft is FUNDING them to code on Win32 related perlcode, in the official perl release... I don't think we have to worry about anything...
Nortel has done testing in the UK for these type of communicatons. As I recall they took advantage of the fact that most powercables there run underground, so they are pretty well shielded from the start. As someone else pointed out, you can't get the signal past the nearest transformer. The point is that most newer transformerstations already have optic fibre installed. Most underground cableinstallations today lay down optic fibre together with the power cables out of foresight.
Because the control box supplies standard scan codes into the keyboard port, no resident software driver is used. If the user accepts the default " Ctrl - Alt - Shift " configuration, no software is needed - just plug in the pedals and play! The only purpose of the supplied software, is to reassign the pedals (if desired) to keys other than the default keys. (To do this, DOS or Windows must be running.) After the reassignment is completed, the pedal software can be removed from computer memory. The new configuration will be stored by the control box, even when the power is turned off.
Slashdot Mirror
>As long as the usernames are the same (for the salt) you should be fine.
Ummm. No. I copy passwords to and from users all the time, and the username doesn't matter either... the first 2 bytes of the 13 character password are the salt....
I'm going out on a limb here but, the salt is NOT derived from the username, that would be inherantly insecure. It must (should, at least) be randomly selected.
/olle
Q: Is this going to be a custom version of Perl for Microsoft?
A: In a word, no. We will always use the mainstream version of Perl as our core technology. All potential
work we undertake to do on the mainstream Perl source code will be achieved through open development
with the community.
Q: Why is Microsoft doing this?
...
FOR IMMEDIATE RELEASE
FAQ - ActiveState and Microsoft
Vancouver, Canada - Update June 2nd, 1999
We want to make sure that you, as members of the Perl community, are informed on our latest efforts to
advance Perl technology for Windows. We are quite excited about this development, and see it as a truly
winning proposition for Perl.
Below we have attempted to answer the questions that many of you will have about this development. If you
have further questions or concerns, please send them to Press@ActiveState.com
Q: What is the scope of the work that is being done?
A: ActiveState proposed many potential areas of work to Microsoft, based on feedback we have had from
Perl users over the years. Microsoft accepted the items of work listed below as being important enough for
them to support with funding. As a result, there are four main areas of development, all of which target the
Windows platform.
The interfaces and implementation of all parts of the work that have a chance of being generally useful will be
discussed amidst the Perl development community (perl5-porters@perl.org, archived at www.deja.com) for
inclusion in Perl.
fork()
This implementation of fork() will clone the running interpreter and create a new interpreter with its
own thread, but running in the same process space. The goal is to achieve functional equivalence to
fork() on UNIX systems without suffering the performance hit of the process creation overhead on
Win32 platforms.
Emulating fork() within a single process needs the ability to run multiple interpreters concurrently in
separate threads. Perl version 5.005 has experimental support for this in the form of the
PERL_OBJECT build option, but it has some shortcomings. PERL_OBJECT needs a C++ compiler,
and currently only works on Windows. ActiveState will be working to provide support for revamped
support for the PERL_OBJECT functionality that will run on every platform that Perl will build on,
and will no longer require C++ to work. This means that other operating systems that lack fork() but
have support for threads (such as VMS and MacOS) will benefit from this aspect of the work.
Microsoft Installer Support
Microsoft is moving towards providing improved package management facilities in Windows 2000.
This aspect of the work will make the ActivePerl installer compatible with the new MSI DB, which is
an important requirement for easy management of the Perl installation process on Windows 2000
systems.
Globalization
The Unicode support that Larry Wall created for Perl extends to Perl operations but not to system
calls. Windows NT supports Unicode at the system-call level, and it would be natural to provide a
way to enable the Unicode variants of the system calls. This allows users to create files that have
names comprised of Unicode characters, for example.
This aspect of the work covers extension of the existing Unicode support to all Win32 system calls
in the Perl core, for such things as file names, environment variables, command-line arguments, etc.
This functionality will only be available on Windows NT and Windows 2000 systems (not on
Windows 98 or similar).
The implementation for this is Windows-specific, but the interface to enable it from Perl will be
general and portable to all platforms that support Unicode. This interface will be decided based on
discussion with the development community. The implementation will be built over Perl's existing
abstraction for system calls, which means other platforms that need to support Unicode system
calls can follow the same model if they wish to do so.
It must be noted that support for Unicode will have no effect on the default behavior of Perl. It will
continue to be enabled only when explicitly requested by the script with a pragma. Other existing
internationalization features like locales will continue to work as they have done before.
PerlScript Performance Enhancements
Caching and cloning of compiled scripts in memory will significantly boost the performance of
PerlScript running under IIS/ASP.
The implementation of this aspect will utilize the facilities for creation of multiple interpreters, but will
be otherwise independent of the Perl core.
Q: Is this going to be a custom version of Perl for Microsoft?
A: In a word, no. We will always use the mainstream version of Perl as our core technology. All potential
work we undertake to do on the mainstream Perl source code will be achieved through open development
with the community.
Q: Why is Microsoft doing this?
A: Microsoft knows first hand that Perl is an important tool for their customers, since they are a heavy user
of Perl internally. They want Perl to work well on the Windows platforms and to take advantage of platform
features on Windows.
Some people have expressed fears about a potential "embrace and extend" manoeuvre by Microsoft. We
would like to reassure the Perl community that we see no danger of this ever happening with Perl. Perl's
development model is based entirely on open discussion of changes, and is one of the most important
reasons for the dynamic evolution that Perl has enjoyed over the years. To change this would be
counter-productive to any commercial entity that may have a stake in Perl's success.
It seems more to be like Microsoft is FUNDING them to code on Win32 related perlcode, in the official perl release... I don't think we have to worry about anything...
/olle
I don't mean to be snotty but, get a transciver...
Actually, go to your uni's network/computer dept. staff and ask for an old one, I bet you they have lots just lying around...
It's the only sane way to get any use out of the old relic....
/olle
Nortel has done testing in the UK for these type of communicatons.
As I recall they took advantage of the fact that most powercables there run underground, so they are pretty well shielded from the start.
As someone else pointed out, you can't get the signal past the nearest transformer. The point is that most newer transformerstations already have optic fibre installed. Most underground cableinstallations today lay down optic fibre together with the power cables out of foresight.
/olle
From their webpage:
Because the control box supplies standard scan codes into the keyboard port, no resident software driver is used. If the user accepts the default " Ctrl - Alt - Shift " configuration, no software is needed - just plug in the pedals and play! The only purpose of the supplied software, is to reassign the pedals (if desired) to keys other than the default keys. (To do this, DOS or Windows must be running.) After the reassignment is completed, the pedal software can be removed from computer memory. The new configuration will be stored by the control box, even when the power is turned off.
Check out my summary of streaming to Shoutcast servers at: http://members.xoom.com/olle_101/
It's really pretty easy..
/olle