Re: [osol-discuss] OpenBSD donation request
Darren J Moffat [EMAIL PROTECTED] wrote: Lars C wrote: I think that a significant donation by Sun would not only help the OpenBSD project in sustaining the development of OpenSSH, but would also be a good public relations opportunity. Sun already has in the past made donations both to OpenSSH and to OpenBSD. If this is true, then the claim from Theo de Radt seems to be really bad to Sun. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] RFE: New version of |strcat()| ...
James Carlson [EMAIL PROTECTED] wrote: Joerg Schilling writes: I have a re-implementation in my libschily [...] * WARNING: a NULL constant is not a NULL pointer, so a caller must * cast a NULL constant to a pointer: (char *)NULL How's that? This is a conclusion from the C standard If you have #define NULL (char *)0 there is no problem but if you have #define NULL 0 as usual on UNIX, then you are able to do this correctly: char*p; p = 0; but you cannot place a NULL pointer in a vararglist this way as the compiler does not now the type of the lhs. For this reason, you need to cast in order to make your code work correctly on LP64 systems. If Sun did not check this already, I recommend to do this. I did 3 years ago for my code after an alert from the FreeBSD people. strcatl(char *to, ...) Sigh ... not safe from target overflow problems. It hasn't learned the lessons of strcpy(3C) and gets(3C). I'd recommend at least fixing Well, this is an interface from 1982 and at that time there was no strncpy() either ;-) that: strcatl(char *to, size_t tolen, ...) but, then, that calls the return value into question. The return value probably shouldn't be a pointer to the last char if a bounded output array is supplied because it then becomes impossible for the caller to detect overflow. Could you explain this please? Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] RFE: New version of |strcat()| ...
James Carlson [EMAIL PROTECTED] wrote: Alan Coopersmith writes: Also, as I noted on IRC, strlcat() is close to this, and much safer. snprintf is simpler still and just as safe. This does not work in case the call to strlcat() would be done from within a loop. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: From On build to DVD ISO - how?
Rainer Orth [EMAIL PROTECTED] wrote: Keith M Wesolowski [EMAIL PROTECTED] writes: Ask the Belenix or Nexenta guys. The stuff that Solaris RE uses isn't available and probably never will be (and won't work anyway since ON packages don't work yet). Note that you'll likely want more than just Speaking of ON packages, I just tried a build of 20060320 with nightly -pz on x86, and most of the packages built. There are a few exceptions due to missing files, and I haven't tried the packages for anything yet. Should I file bugs for the problems and try to track them down, and what's the plan for this going forward? I did create a hack to workaround this problem before Christmas. I plan to actualize it this week and to publish an intermediate SchilliX that include a populated package database. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Anyone still using Sun's csh ?
Hi All, I was wondering if people still use Sun's csh. I began to work on a bug found in the bug database about csh ( http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=4635088 ). After I have fixed it, I thought maybe I could fix some other csh bugs since I was inside its code. I then asked the bug database search engine to retrieve csh related bugs (only those with state=open), and it found 1403 entries ! Of course not all are csh related, since if the bug report contains the word csh, it appears even if the problem is not about csh. I had a look at many of these bug reports about csh. Some seem to be really anoying, some show csh has strong limitations (compared to other shells), some are very old ... So, is there still a large number of people using it and does it worth to work on csh bugs or have people switched to another shell ? Cheers Yann This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] 2 new request-sponsor putbacks: 47 total
Jim Grisanzio [EMAIL PROTECTED] wrote: Thanks to Rich Lowe for these two fixes below and to Sarah Jelinek for sponsoring the work through to putback. -- Jim Putback 46 ID: 4759320 Desc: Read-only UFS global mounts should not try to turn on logging Submitted by Richard Lowe on 12/07/05 Sun Sponsor: Sarah Jelinek Putback to Nevada 37 on 3/23/06 How does fsck now flush the log trail? Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] RFE: New version of |strcat()| ...
Joerg Schilling writes:
How's that?
This is a conclusion from the C standard
I should have been more explicit. It seemed like a strange place for
a comment like this.
that:
strcatl(char *to, size_t tolen, ...)
but, then, that calls the return value into question. The return
value probably shouldn't be a pointer to the last char if a bounded
output array is supplied because it then becomes impossible for the
caller to detect overflow.
Could you explain this please?
One may check for overflow of the target buffer (and thus truncation
of the result) using strlcat(3C) like this:
if (strlcat(dst, src, dstsize) = dstsize)
string_is_too_big();
The same works well with snprintf. With the formulation of strcatl
you've proposed, it's not possible to check for this error condition
in any reasonable way following the call. The user must do something
like this instead:
if (strlen(dst) + strlen(src) = dstsize)
string_is_too_big();
(void) strcatl(dst, src, (char *)NULL);
... and that seems unfortunate to me.
Joerg Schilling writes:
James Carlson [EMAIL PROTECTED] wrote:
Alan Coopersmith writes:
Also, as I noted on IRC, strlcat() is close to this, and much safer.
snprintf is simpler still and just as safe.
This does not work in case the call to strlcat() would be done from
within a loop.
Seems to work fine for me:
remlen = dstsize;
while (--things = 0) {
seuss(thing1, thing2);
added = snprintf(dst, remlen, %s and %s, thing1, thing2);
if (added = remlen)
too_many_things();
dst += added;
remlen -= added;
}
I think you're considering something like:
while (--things = 0) {
seuss(thing1, thing2);
if (strlcat(dst, thing1, dstsize) = dstsize)
too_many_things();
if (strlcat(dst, and , dstsize) = dstsize)
too_many_things();
if (strlcat(dst, thing2, dstsize) = dstsize)
too_many_things();
}
... but I don't see how that's necessarily more usable, maintainable,
or flexible.
--
James Carlson, KISS Network[EMAIL PROTECTED]
Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
[osol-discuss] MPLS project proposal
The MPLS project is an effort to support Multiprotocol Label Switching (as described in IETF Standards-Track RFCs 3031, 3032, and others) on Solaris. This protocol is roughly like X.25 or ATM, but in an IP-centric context. It's useful for creating VPNs (Virtual Private Networks), remote bridges, and traffic engineering, and it's closely related to other IP networking technologies such as the Quagga routing suite. In the short term, the project aims to provide the MPLS label stack encoding mechanisms and a basic framework for MPLS support. In the longer term, the project will provide basic MPLS tools (such as LDP) and programming interfaces suitable for higher-level protocols. (Whether other MPLS-related protocols such as RSVP-TE or CR-LDP might be part of this project or a follow on remains to be determined.) This is being proposed as an open project; anyone willing to participate is welcome. The initial leadership will be Pedro A. Aranda Gutiérrez and myself. -- James Carlson, KISS Network[EMAIL PROTECTED] Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] SXCR/onnv status
SXCR is on track to be released on Friday (3/31). Steve is working on a nightly sync up with onnv_37 that he will post in the next day or so. Thanks, Karyn ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] hwdb is ported to NexentaOS
Hi Guys, I just wanted to let you know that I fully ported (fixed some bugs, added some features) and integrated HWDB client and server backend into NexentaOS. It will be an integral part of upcoming Alpha 4 release. Screenshots: http://www.gnusolaris.org/gswiki/ErastBenson/HWDB_screenshots -- Erast ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Creating new device node in device tree at system startup.
This is in fact how its done. The important step is to add the set pci_allow_pseudo_children=1 to the etc/system file, otherwise PCI will not load the information. When I first tried to add device node information to the dot-conf file pci wouldn't read it, but it was not evident why it wouldn't. Thanks for all you help. Lou Jan Setje-Eilers wrote: You'll want to take a look at the driver.conf(4) man page and translate all the bits of information you previously decorated the node with via boot.rc into your .conf file. So, something like: name=ipmi_lpc parent=/[EMAIL PROTECTED],0 device-type=pci unit-address=1f ... You'll also need to tell pci that it's OK to pick up .conf enumerated nodes. You can do this by setting pci_allow_pseudo_children to 1 in etc/system. Just add a line line this: set pci_allow_pseudo_children=1 To etc/system. Please let us know this goes for you. -jan I have tried this too, but when you try and map the registers with the ddi_regs_map_setup() there's nothing to map and the call fails. There is also the secondary problem of writing to the 6300ESB register space so that LPC configuration can provide access to the IO space. Lou Artem Kachitchkine wrote: Instead of creating a node, you could install your driver as a pseudo driver, by creating a /kernel/drv/ipmi_lpc.conf (or whatever's you driver name) file containing the line: name=ipmi_lpc parent=pseudo instance=0; The system will load the driver even if there isn't a hardware node for it. Then access any I/O address you like, considering that *you know* that no other driver on the system accesses (or at least doesn't write or read-with-side-effect) this same address. -Artem. Louis Gagne wrote: I have implemented a character driver under X86 based Solaris 10 release 3/05 that interfaces with a device on the ISA/LPC interface using Intels 6300ESB I/O controller Hub. This device is not defined by the system BIOS at boot time, so we had to do this manually by modifying the boot startup script in boot/solaris/boot.rc to create a device node and open up the relevant address space we needed to access our device. We have a package that installs all the necessary pieces for the new driver and this has worked just fine under the 3/05 version of Solaris 10. It does not work under X86 based Solaris 10 Update 1 - which is what our customer is using. The driver itself is very simple and only accesses 3 bytes in LPC space. The relevant changes in boot.rc made to allow access to this space are shown below. I have tried to add these changes to bootenv.rc, but /usr/sbin/eeprom generates error messages on the mknod, cd and setbinprop lines. Does anyone have any suggestions on what I might try? Lou # Set node for IPMI LPC SMIC interface space in PCI IO space. mknod /[EMAIL PROTECTED],0/ipmi_lpc cd /[EMAIL PROTECTED],0/ipmi_lpc setprop device-type pci setprop name ipmi_lpc setprop unit-address 0x1f setbinprop assigned-addresses 0xf800,0x0,0x0,0x0,0x0,0x8100f8ec,0x0,0x0ca0,0x0,0x0010 setbinprop device-id 0x25a1 setbinprop vendor-id 0x8086 setbinprop class-code 0x060100 setbinprop reg 0xf800,0,0,0,0,0x0100F8EC,0x0,0x,0x,0x0010 This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org -- Louis R. Gagne Momentum Computer Inc. 1815 Aston Ave. Suite 107 Carlsbad, CA 92008 (760) 431-8663 X-104 (760) 431-7571 (FAX) [EMAIL PROTECTED] ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org -- Louis R. Gagne Momentum Computer Inc. 1815 Aston Ave. Suite 107 Carlsbad, CA 92008 (760) 431-8663 X-104 (760) 431-7571 (FAX) [EMAIL PROTECTED] ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] RFE: New version of |strcat()| ...
James Carlson [EMAIL PROTECTED] wrote: This is a conclusion from the C standard I should have been more explicit. It seemed like a strange place for a comment like this. If you did see the modifications done to my software by people from SuSE or Debian, you would understand why I put a lot of such comments into my sources ;-) One may check for overflow of the target buffer (and thus truncation of the result) using strlcat(3C) like this: if (strlcat(dst, src, dstsize) = dstsize) string_is_too_big(); The same works well with snprintf. With the formulation of strcatl you've proposed, it's not possible to check for this error condition in any reasonable way following the call. The user must do something like this instead: if (strlen(dst) + strlen(src) = dstsize) string_is_too_big(); (void) strcatl(dst, src, (char *)NULL); ... and that seems unfortunate to me. OK, there are still places where I use strcatl() although it is much less than my usage for strcalt() in 1985. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] MPLS project proposal
James Carlson wrote: This is being proposed as an open project; anyone willing to participate is welcome. The initial leadership will be Pedro A. Aranda Gutiérrez and myself. I second the proposal. -Seb ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] hwdb is ported to NexentaOS
Hey Erast, On Tue, 2006-03-28 at 13:15 -0800, Erast Benson wrote: Hi Guys, I just wanted to let you know that I fully ported (fixed some bugs, added some features) and integrated HWDB client and server backend into NexentaOS. It will be an integral part of upcoming Alpha 4 release. Screenshots: http://www.gnusolaris.org/gswiki/ErastBenson/HWDB_screenshots This is very, very cool - nice work dude! It'll be interesting to see what hardware people are running NexentaOS on, and hopefully it'll encourage more people to install the distribution knowing that X, Y and Z will work before they try. FWIW, I'd like to see this type of thing being installed by default in mainstream Solaris too... Glynn ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: Anyone still using Sun's csh ?
I was able to reproduce this bug id 4635088 on my Solaris 10u1 AMD XP chip 2000mhz, I do know of users that still use the csh and I still do as well! I thinkg it's great that someone has intrest in these old outstanding issues, that drives everyone nut's but never say's anything! # csh Server# if -f Segmentation Fault - core dumped # This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] B35 install: Entire Group + OEM Size correct?
Hey All, I am just installing B35 (X86), and noticed that the installer reports that Entire Group and Entire Group Plus OEM are the same size at 3376.6 MB. I guess that this is not quite correct...? Regards... Sean. This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [Fwd: [osol-discuss] RFE: Replace /usr/css/bin/make with dmake inSolaris/OpenSolaris]
Roland Mainz wrote: Do you have any idea who may be interested in implementing the proposal below ? No, I don't, unfortunately. I get the feeling though that it is an idea whose time has come. Original Message Subject: [osol-discuss] RFE: Replace /usr/css/bin/make with dmake inSolaris/OpenSolaris Date: Tue, 21 Feb 2006 03:14:28 +0100 From: Roland Mainz [EMAIL PROTECTED] ... A small proposal for discussion: RFE: Replace (Open-)Solaris's /usr/ccs/bin/make with dmake (from Sun Studio 11) * Why would it be usefull to replace /usr/ccs/bin/make with dmake ? - dmake allows parallel, distributed and grid (e.g. distributed via grid) builds, making it a perfect application for Sun's new multicore chips such as Niagara1/2 + Rock, dual-core Opterons and racks filled with Sun machines (e.g. in either distributed or grid mode). My team already has anecdotal experience that builds on niagara boxen take ~20% of the time that they do on US-IV machines. This, we like! - Jörg Schilling said a while ago that dmake and make are quite similar (and I guess maybe even share the same codebase): http://groups.google.com/group/comp.unix.solaris/browse_frm/thread/cdbe46c1bd8bf40b/e413cb17650f4c53?lnk=stq=dmake+make+solaris+j%C3%B6rg+schillingrnum=2hl=en#e413cb17650f4c53 Originally it made sense to charge customer for the advanched functionality in dmake (compared to the normal make in Solaris) - but now Sun Studio 11 is available for free - so there is no need to have two versions of make floating around. I agree. - Having only one version of make around in Solaris/Studio products will likely lower the engineering costs in the long term. Definitely. And we as a company do not like to spend our money on duplication of effort. - Sun did already lots of efforts to enhance the parallelism in Solaris, including the introduction of the all-new SMF startup system which starts services in parallel. Stuffing dmake at /usr/ccs/bin/make's place would just be the next logical step to explore parallelism in Solaris. A bit of a long bow to draw, but I get the point. We are in general moving from serial to parallel execution of just about everything. - Sun is moving to a product line where almost every computer has multicore chips. Having a make binary which makes use of such a feature would be quite usefull (if anyone from Sun is looking for a business case... :-) ). For example the Niagara-based T1000/T2000 machines would get another usefull application - for free. - The switch may be quite cheap to implement (looking at engineering time) - dmake already exists, is maintained and fully documented. Now look, you're going to have to stop stating the obvious here! JimG/Bonnie/StephenH/ Roland is right - we should make this happen, and sooner rather than later. I give this proposal my +1 seal of approval. * Contra arguments: - Testing needs to be done whether dmake is 100% backwards-compatible to /usr/ccs/bin/make (except that there is new functionality) We have regression testing fiends in Ireland PerfPIT. I doubt that this would be a real problem. - Lawyers will have to check the dmake sources. *shrug* actually, I think it'll be _engineers_ who check the dmake source. One who are suitably qualified and experienced. - Sun Studio's value will decrease since another functionality gets integrated into the base operating system. One might argue that since Sun Studio has a $0 cost, that this doesn't really matter. best regards, James C. McPherson -- Solaris Datapath Engineering Data Management Group Sun Microsystems ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [Fwd: [osol-discuss] RFE: Replace /usr/css/bin/make with dmakeinSolaris/OpenSolaris]
James C. McPherson wrote: Roland Mainz wrote: Do you have any idea who may be interested in implementing the proposal below ? No, I don't, unfortunately. I get the feeling though that it is an idea whose time has come. Well, the idea was already proposed a couple of times in the last years and noone really cared... ;-( [snip] - Having only one version of make around in Solaris/Studio products will likely lower the engineering costs in the long term. Definitely. And we as a company do not like to spend our money on duplication of effort. And I think makeing dmake open source and stuffing it into ON may result in some bugfixes and/or enhanchements ... :-) - Sun did already lots of efforts to enhance the parallelism in Solaris, including the introduction of the all-new SMF startup system which starts services in parallel. Stuffing dmake at /usr/ccs/bin/make's place would just be the next logical step to explore parallelism in Solaris. A bit of a long bow to draw, but I get the point. We are in general moving from serial to parallel execution of just about everything. Well, it isn't really a long bow to draw when you think what make/Makefiles can be used for. I know at least one company who just purchased Sun Workshop to have a version of make which can run distributed builds (or in their case: process giant amounts of input data where only a fraction changes each for each rebuild). Beyond that point there are AFAIK OS facilities which use make for normal work (was that YP/NIS (cannot remember anymore, we're using NIS+ :-) ) ?) and could benefit from a parallel version... - Sun is moving to a product line where almost every computer has multicore chips. Having a make binary which makes use of such a feature would be quite usefull (if anyone from Sun is looking for a business case... :-) ). For example the Niagara-based T1000/T2000 machines would get another usefull application - for free. - The switch may be quite cheap to implement (looking at engineering time) - dmake already exists, is maintained and fully documented. Now look, you're going to have to stop stating the obvious here! I fear the answer has to be yes since otherwise people may not listen... ;-( And there is also the (IMO important issue) that opening dmake under a free license may help other OSes (such as FreeBSD, NetBSD, DragonFly etc.) to adopt it als default make version. gmake doesn't have many fans (and lacks distributed and grid build modes) outside Linux (at least in the *BSD variants listed above) and spreading the Workshop/Forte/Studio dmake may help lowering the porting efforts when porting software from those operating systems to Solaris. JimG/Bonnie/StephenH/ Roland is right - we should make this happen, and sooner rather than later. I give this proposal my +1 seal of approval. Well, I guess we need tons of +1 here from the right managers... ;-/ * Contra arguments: - Testing needs to be done whether dmake is 100% backwards-compatible to /usr/ccs/bin/make (except that there is new functionality) We have regression testing fiends in Ireland PerfPIT. I doubt that this would be a real problem. Ok... [snip] - Sun Studio's value will decrease since another functionality gets integrated into the base operating system. One might argue that since Sun Studio has a $0 cost, that this doesn't really matter. Well, it did matter in the past. And I guess it still has some kind of internal value even if the product itself is now free for customers (Ok Ok... this is WILD guessing... I have absolutely no clue about how to calculate the value of immaterial goods such as software... ;-/ ). Ok... what are the next steps ? Should I write an opensolaris.org project proposal ? Bye, Roland -- __ . . __ (o.\ \/ /.o) [EMAIL PROTECTED] \__\/\/__/ MPEG specialist, CJAVASunUnix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;) ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] B35 install: Entire Group + OEM Size correct?
Sean Sprague wrote: I am just installing B35 (X86), and noticed that the installer reports that Entire Group and Entire Group Plus OEM are the same size at 3376.6 MB. I guess that this is not quite correct...? Wild guessing: There are no OEM packages in this build so these install clusters have the same size... Bye, Roland -- __ . . __ (o.\ \/ /.o) [EMAIL PROTECTED] \__\/\/__/ MPEG specialist, CJAVASunUnix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;) ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
RFE: Mailman list for genunix Wiki diffs / was: Re: [osol-discuss] Changes to the Genunix Wiki
Ben Rockwood wrote: If there are any further issues, annoyances, requests or general Genunix comments please, as usual, address them to Al Hopper and/or myself. Is it possible to get a mailman list to which the diffs (gdiff -u) of the changes are posted (similar to a CVS commit list most opensource projects have) ? Yes, I know... there is the RSS feed - but that requires special machinery (e.g. RSS client), has no archive (mailman has all the postings archived) and does not allow easy searching (mails from mailman can simply be searched in your local mail folder (or GMail)). This could greatly help tracking down malicious changes, allows quick reactions when the spambots attack again (well... emails from commit lists are usually near realtime... :-) ) and even allow better communication within the community (e.g. it would be possible to comment on diffs and debate them...). Bye, Roland -- __ . . __ (o.\ \/ /.o) [EMAIL PROTECTED] \__\/\/__/ MPEG specialist, CJAVASunUnix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;) ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: Trouble with ON's perl when building from a SVN-based sourcerepository...
Alan Burlison wrote: and so on... at various points (not only in the perl subdirs) the private files of the SVN repository (e.g. .svn*) are touched (AFAIK this will likely happen with .cvs/ dirs, too) - IMO a bad thing... ;-( This is a OpenSolaris B35 build, checked-out from svn://svn.genunix.org/on/branches/ksh93/gisburn/prototype001/m1_ast_ksh_imported/ (= http://svn.genunix.org/repos/on/branches/ksh93/gisburn/prototype001/m1_ast_ksh_imported/) ... Does anyone have a clue what could be done here ? The perl build scripts assume that nothing other that perl puts files in the source directory, and when a SCM is in use this isn't the case. Is this harmfull or can I ignore the issue ? There are exceptions for various SCM files in the appropriate places, but 5.6.1 predates svn I think, so that will be why it is happening - see http://cvs.opensolaris.org/source/search?q=SCCSpath=%2Fon%2Fusr%2Fsrc%2Fcmd%2Fperl%2F5.6.1%2Fdistrib 5.6.1 is due to be ripped out anyway, so it's probably not worth fixing. ... and you will replace it by what (or better: which perl version will be the new one ?) ? Bye, Roland -- __ . . __ (o.\ \/ /.o) [EMAIL PROTECTED] \__\/\/__/ MPEG specialist, CJAVASunUnix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;) ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Re: 4113420 (request for ksh93 integration)
Stefan Parvu wrote: We should think to have /bin/sh as ksh93. It is elegant and simple to do. Are there any objections why /bin/sh cannot be a ksh93 ? This is unlikely to happen in the forseeable future. It's already difficult enougth to convince Sun to switch /bin/ksh from ksh88 to ksh93 (even that tiny project caused serious UPROAR + tensions between Sun vs. customers - that's why I requested a seperate mailinglist (see http://mail.opensolaris.org/mailman/listinfo/ksh93-integration-discuss) to play the ball very low, avoid the flamewar in the main list and have a place to work on the technical details). Bye, Roland -- __ . . __ (o.\ \/ /.o) [EMAIL PROTECTED] \__\/\/__/ MPEG specialist, CJAVASunUnix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;) ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Re: 4113420 (request for ksh93 integration)
Stefan Parvu wrote: Uaau, I see we have now a dedicated ksh93 migration forum: http://www.opensolaris.org/jive/forum.jspa?forumID=103 I hope folks will agree and get this fixed somehow. stefan This project has the goal to integrate ksh93 into (Open-)Solaris including the update of /bin/ksh from ksh88 to ksh93 standard. Once this has been completed (and all side-effects solved) we can look around for more prey - but IMO this will not happen within the next two years... Bye, Roland P.S.: No flamewar, please... -- __ . . __ (o.\ \/ /.o) [EMAIL PROTECTED] \__\/\/__/ MPEG specialist, CJAVASunUnix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;) ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] [Fwd: Funding OpenSSH]
James Carlson wrote: Roland Mainz writes: Beyond that point this issue it does not only affect Sun, it also affects OpenSolaris and the related distributions which makes it a valid email for this list. It's perhaps worth noting that the ssh in Solaris is deliberately SunSSH. Though it is a derivative of OpenSSH, it's certainly not the same thing. Yes... but you still depend on OpenSSH.org and their work (including updates), right ? Bye, Roland -- __ . . __ (o.\ \/ /.o) [EMAIL PROTECTED] \__\/\/__/ MPEG specialist, CJAVASunUnix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;) ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] [Fwd: Funding OpenSSH]
Alan Coopersmith wrote: Felix Schulte wrote: Yes. And Sun SSH is still vulnerable to X11keyboard sniffing. open ssh has untrusted X11 forwarding for that - Sun SSH does not. And how many people use it? No clue. But it makes sense in some environments. And it's not openssh.org's or ssh.com's fault that GTK+-based applications are too dumb to deal with untrusted X11 mode. Most discussion of it I've seen is advice to use -Y instead of -X with new OpenSSH to get the old behaviour back. Unfortunately yes. But then scripts cannot be portable since there is no -Y switch in SunSSH. Bye, Roland -- __ . . __ (o.\ \/ /.o) [EMAIL PROTECTED] \__\/\/__/ MPEG specialist, CJAVASunUnix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;) ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: RFE: Mailman list for genunix Wiki diffs / was: Re: [osol-discuss] Changes to the Genunix Wiki
Roland Mainz wrote: Ben Rockwood wrote: If there are any further issues, annoyances, requests or general Genunix comments please, as usual, address them to Al Hopper and/or myself. Is it possible to get a mailman list to which the diffs (gdiff -u) of the changes are posted (similar to a CVS commit list most opensource projects have) ? Yes, I know... there is the RSS feed - but that requires special machinery (e.g. RSS client), has no archive (mailman has all the postings archived) and does not allow easy searching (mails from mailman can simply be searched in your local mail folder (or GMail)). This could greatly help tracking down malicious changes, allows quick reactions when the spambots attack again (well... emails from commit lists are usually near realtime... :-) ) and even allow better communication within the community (e.g. it would be possible to comment on diffs and debate them...). This sort of thing will be more plausible in the future when a proper SCM is in place and each individual putback/commit is made, rather than the current en mass drops. A variety of mechanisms will grow up around the infrastructure. That said, in the meantime, your free to undertake such a task as you propose now, yourself. This is a community, feel free to contribute. benr. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
