From: <don...@is...> - 2004-02-22 20:28:46
|
> It isn't ridiculous. First you say that because you don't care about > UDP, no one using CLISP should. Leaving that aside, if only TCP is > suitable for wrapping as a STREAM, and since there is no other access > to sockets programming, as you have made in 'point A', then it is > limited. I had rather expected to find another (conceptual) layer to > let me access non-TCP sockets, on top of which the STREAM would be > layered for TCP, but found no such thing. Do you really want to be limited to only tcp and udp? Don't you want icmp? How about arp? There is a raw socket module for clisp. I understand it's freely available. It might only work in linux so far. This is far less limited than tcp + udp. I see only two small disadvantages of this relative to a built in udp facility. - you have to be root to use it - you have to do your own defragmentation In return for this small (in my opinion) price, you avoid the limitations of the higher level interfaces. > Are you sure your usage pattern is really representative? I don't think he meant this was HIS usage. I think he meant that this was ALL the usage he had seen from anyone, and as the person who is likely to hear the requests of everyone who wants a facility in clisp, this probably represents at least the entire clisp user community. > Maybe it would be not a SOCKET-STREAM but a UDP-STREAM? A udp interface should not even use the term "stream". Maybe something like read/write-datagram-no-hang. |
From: Sam S. <sd...@gn...> - 2004-02-22 21:19:14
|
> * Don Cohen <qba...@vf...3-vap.pbz> [2004-02-22 12:17:39 -0800]: > > Do you really want to be limited to only tcp and udp? > Don't you want icmp? > How about arp? > There is a raw socket module for clisp. > I understand it's freely available. > It might only work in linux so far. > This is far less limited than tcp + udp. never heard about this module. who wrote it? where is it? maybe we should distribute it with CLISP, as, say, "raw-ip" module. > I see only two small disadvantages of this relative to a built in > udp facility. > - you have to be root to use it > - you have to do your own defragmentation > In return for this small (in my opinion) price, you avoid the > limitations of the higher level interfaces. I don't see why you need to be root to use it. (and I don't know what defragmentation is in this context) > > Maybe it would be not a SOCKET-STREAM but a UDP-STREAM? > > A udp interface should not even use the term "stream". > Maybe something like read/write-datagram-no-hang. at any rate, all these UDP, ICMP ARP &c &c objects should be obtainable from SOCKET-ACCEPT and SOCKET-CONNECT - because this is the appropriate existing infrastructure for listening and connecting. whether the returned object will be called `stream' or not is not too important. the reason I suggested `UDP-STREAM' was because it is relatively easy to add a new kind of stream (compared to a new object type). > > Are you sure your usage pattern is really representative? > > I don't think he meant this was HIS usage. I think he meant that this > was ALL the usage he had seen from anyone, and as the person who is > likely to hear the requests of everyone who wants a facility in clisp, > this probably represents at least the entire clisp user community. I don't think Bruno wanted to say a "flat no". I assume that he meant that 1. this is not as easy as it might sound (as Bruno put it, it is not enough to make SOCKET-CONNECT take an extra argument), and 2. it is not obvious how to do this correctly, and 3. there isn't a huge demand for this feature, and 4. nobody have so far offered a clean interface, and 5. nobody have so far volunteered to implement anything. The CLISP developers are open to suggestions on how should exotic sockets be integrated into CLISP. <http://cygwin.com/acronyms/#PTC>; <http://cygwin.com/acronyms/#SHTDI>. -- Sam Steingold (http://www.podval.org/~sds) running w2k <http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/> <http://www.mideasttruth.com/> <http://www.honestreporting.com> Save the whales, feed the hungry, free the mallocs. |
From: <don...@is...> - 2004-02-22 21:59:17
|
Sam Steingold writes: > > Do you really want to be limited to only tcp and udp? > > Don't you want icmp? > > How about arp? > > There is a raw socket module for clisp. > > I understand it's freely available. > > It might only work in linux so far. > > This is far less limited than tcp + udp. > > never heard about this module. > who wrote it? Fred Cohen. He told me it was freely available. [I cc him here] -- Fred - is there an officially released version? If so - Where is it? - Can it be distributed with clisp? - or what alternative do you suggest? If not, what do you suggest? I can send my current copy if you like. Tell me what parts are available. > maybe we should distribute it with CLISP, as, say, "raw-ip" module. It's really not IP - even lower level than that! > > I see only two small disadvantages of this relative to a built in > > udp facility. > > - you have to be root to use it > > - you have to do your own defragmentation > > In return for this small (in my opinion) price, you avoid the > > limitations of the higher level interfaces. Ah, one more small disadvantage - you have to ignore all the packets you don't care about. > I don't see why you need to be root to use it. > (and I don't know what defragmentation is in this context) This is really lower level than what users are supposed to do. But then, that may also be true for some of those UDP applications. I think the following will give an idea of why you need to be root. This lets you read all packets that arrive and send any packets you want to. You control which network interface they are sent from. You control every bit of the packet. You can send false source addresses in IP packets. You can communicate (both read and write) on tcp/udp ports that have never been opened officially (by the OS). You can read the packets that are filtered by the firewall code on this machine. You are bypassing the OS IP code. One thing that code does for you is defragmentation. IP packets can be fragmented - cut into pieces because they're too big to be sent over some wire. The receiver is supposed to collect up the pieces and reassemble them. In the case of udp, that's just about the only thing the OS does for you. In the real network this is not much of an issue. For most real udp applications you can probably just keep your packets under 1500 bytes and throw away all fragments. It wouldn't implement the spec, but it would work in practice. If you want to implement the spec it's not too hard. I'm just pointing out that it may not be worth the trouble. > at any rate, all these UDP, ICMP ARP &c &c objects should be obtainable > from SOCKET-ACCEPT and SOCKET-CONNECT - because this is the appropriate > existing infrastructure for listening and connecting. That's the OS interface that we're bypassing here. For tcp, the OS is doing a lot of work that you would not want to do yourself. For udp, not much. A specific udp interface would therefore save a little work over raw sockets but be much more restrictive. I hope this all makes more sense now. |
From: Sam S. <sd...@gn...> - 2004-02-22 22:44:18
|
> * Don Cohen <qba...@vf...3-vap.pbz> [2004-02-22 13:48:11 -0800]: > > I hope this all makes more sense now. yes, thanks. it is now even more clear than it was before that 1. there is no place for this in the core. 2. it would be real nice to have a module for that. -- Sam Steingold (http://www.podval.org/~sds) running w2k <http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/> <http://www.mideasttruth.com/> <http://www.honestreporting.com> Binaries die but source code lives forever. |
From: <don...@is...> - 2004-02-23 20:51:31
|
Fred Cohen writes: > Here: > call-rawsock.lsp ... > rawsock.c: ... > Maker: ... > thingstofix: Not quite the format I expected, but I guess it'll do. I hereby contribute one more file to that set: lisp interface for sending packets ================ #| usage: all as root, of course - cd ~user/test/fc - /usr/local/lib/clisp/base/rawsock/lisp.run -M /usr/local/lib/clisp/base/rawsock/lispinit.mem -B /usr/local/lib/clisp -i call-rawsock -i R - load this file - do (in-package :rawsock) - do (unless (> (initsock) 0) (error "initsock failed - running as root?")) - call sendpackets Sendpackets sends a specified number of packets at a specified rate, where the packet contents are randomly drawn from a specified space. Originally the packets were sent by (execute "/usr/bin/sendpacket" ...) but this seems to be limited to a few hundred calls per second. Now that fc has supplied a raw socket interface to clisp we can use that at much higher rates. On my 200 MHz machine - empty loop: (compile (defun test1 (n)(loop for i below n do nil))) .6 usec per iteration - (random #xffff) => 3.8usec - (get-internal-real-time) => 3.8usec (16bytes) - (ipcsum) => 2.4usec - basic loop without any random numbers, checksum, sendt ~ 20usec - sendt => 52 usec (which implies a max rate of 20kpps) (time ping -F seems to operate up to about 50kpps) In total, with checksum and sendt but no random numbers I send ~8kpps with one random number ~6.5kpps, 2 random numbers 5.5kpps Sendpackets accepts an arbitrary number of keyword arguments of the following forms. :frequency <number> how many per second to send (default 1) :nsec <number> how many seconds to send (default 1) :npackets <number> how many packets to send (default 1) [if two of above are supplied then the other can be computed, if all three are supplied we ignore one] :nbytes <number> number of bytes to send (default 100) :IPchecksum <t or nil> if t then compute ip header checksum (default nil) :TCPchecksum <t or nil> if t then compute tcp checksum (default nil) :UDPchecksum <t or nil> if t then compute udp checksum (default nil) :ICMPchecksum <t or nil> if t then compute icmp checksum (default nil) :device <string> send on device of this name (default - whatever data was last used) :ip-optlen - number of bytes of ip options, rebind special variable :tcp-optlen - number of bytes of tcp options, rebind special variable :initialize (array from to) initialize the packet contents in positions to thru from (inclusive) to the contents of array in the same positions :bits (index nbits minvalue maxvalue) set the <nbits> bits in the packet starting from <index> to a random number between <minvalue> and <maxvalue>, inclusive. All numbers are interpreted modulo that 2^<nbits>. If the first number is larger than the first (modulo the size) then the range wraps around. If the nbits is 4 then (3 5) or (19 5) means {3 4 5} whereas (15 17) or (15 1) means {15 0 1}. :bits (index nbits value) means same as :bits (index nbits value value) :bytes (index nbytes minvalue maxvalue) means same as :bits (<8*index> <8*nbytes> minvalue maxvalue) :bytes (index nbytes value) means same as :bytes (index nbytes value value) [notes: use of :bytes is more efficient than :bits smaller values of nbits/nbytes are more efficient than larger numbers single values are more efficient than ranges ] For convenience a number of constants are defined: macto = 0 - position of (6 byte) to-address in mac header macfrom = 6 - position of (6 byte) from-address in mac header mactype = 12 - position of (2 byte) type in mac header default-ip an argument to :initial-contents that initializes mactype = #x800 (= IP) IP version = 4 IHL = 5 TOS = 0 total length = 40 id = 0 flags = fragment offset = 0 ttl = #x40 protocol = 6 (tcp) IP-version = 14 - position of version, IHL IP-tos = 15 - position of tos IP-length = 16 - position of (2 byte) total length IP-id = 18 - position of (2 byte) id IP-frag = 20 - position of (2 byte) fragment flags and offset IP-ttl = 22 - position of ttl IP-proto = 23 - position of protocol IP-checksum = 24 - position of (2 byte) checksum IP-source = 26 - position of (4 byte) source address IP-dest = 30 - position of (4 byte) dest address IP-options = 34 - position of IP options (variable length) All of these tcp constants assume zero length IP options. You can, of course use (+ tcp-source <ip option length>) TCP-source = 34 - position of (2 byte) source port TCP-dest = 36 - position of (2 byte) dest port TCP-seq = 38 - position of (4 byte) sequence # TCP-ack = 42 - position of (4 byte) acknowledgment # TCP-offset = 46 - left half of this byte is length of tcp header TCP-bits = 47 - right 6 bits are urg,ack,psh,rst,syn,fin TCP-window = 48 - position of (2 byte) window TCP-checksum = 50 - position of (2 byte) checksum TCP-urg = 52 - position of (2 byte) urgent pointer TCP-options = 54 - position of TCP options (variable length) Example: (sendpackets :device "eth0" :bytes (list macfrom 6 #x00e0291cb909) :bytes (list macto 6 #x00045a417537) :nbytes 54 ;; minimal tcp packet :initialize default-ip :ipchecksum t ;; a good idea for most IP packets :bytes (list ip-id 2 #x1234) :bytes (list ip-source 4 #x0a000102) :bytes (list ip-dest 4 #x0a000103) :tcpchecksum t ;; a good idea for most IP packets :bytes (list tcp-source 4 #x22223333) ;; from port 2222 to port 3333 :bytes (list tcp-seq 4 #x55555555) :bytes (list tcp-ack 4 #x66666666) :bytes (list tcp-offset 4 #x50107777) ;; offset, bits, window ) [[output from tcpdump -lenx -i eth1 when I do that]] 14:18:48.222010 0:e0:29:1c:b9:9 0:4:5a:41:75:37 0800 54: 10.0.1.2.8738 > 10.0.1.3.13107: . ack 1 win 30583 4500 0028 1234 0000 4006 5298 0a00 0102 0a00 0103 2222 3333 5555 5555 6666 6666 5010 7777 558c 0000 IP spec from rfc791, to help follow above example +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| IHL |Type of Service| Total Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification |Flags| Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time to Live | Protocol | Header Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ and while we're at it, tcp header format from rfc793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port | Destination Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Acknowledgment Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data | |U|A|P|R|S|F| | | Offset| Reserved |R|C|S|S|Y|I| Window | | | |G|K|H|T|N|N| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | Urgent Pointer | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ [[continue tcpdump to show resulting traffic]] 14:18:48.222721 0:4:5a:41:75:37 ff:ff:ff:ff:ff:ff 0806 64: arp who-has 10.0.1.2 tell 10.0.1.1 0001 0800 0604 0001 0004 5a41 7537 0a00 0101 0000 0000 0000 0a00 0102 0000 0000 0000 0000 0000 0000 0000 0000 0000 c4ee 7afc 14:18:48.222880 0:e0:29:1c:b9:9 0:4:5a:41:75:37 0806 42: arp reply 10.0.1.2 is-at 0:e0:29:1c:b9:9 0001 0800 0604 0002 00e0 291c b909 0a00 0102 0004 5a41 7537 0a00 0101 14:18:48.222972 0:4:5a:41:75:37 0:e0:29:1c:b9:9 0800 64: 10.0.1.3.13107 > 10.0.1.2.8738: R 1717986918:1717986918(0) win 0 4500 0028 0213 0000 fe06 a4b8 0a00 0103 0a00 0102 3333 2222 6666 6666 0000 0000 5004 0000 77ba 0000 0000 0000 0000 c4ee 7afc |# (in-package :rawsock) (defconstant macto 0) ;; position of (6 byte) to-address in mac header (defconstant macfrom 6) ;; position of (6 byte) from-address in mac header (defconstant mactype 12) ;; position of (2 byte) type in mac header (defconstant default-ip (list (make-array 24 :element-type '(unsigned-byte 8) :initial-contents '(0 0 0 0 0 0 0 0 0 0 0 0 8 0 ;; mac header #x45 0 0 40 ;; version/IHL, tos, total len 0 0 0 0 ;; id, frag #x40 6)) 12 23)) (defconstant IP-version 14) ;; position of version, IHL (defconstant IP-tos 15) ;; position of tos (defconstant IP-length 16) ;; position of (2 byte) total length (defconstant IP-id 18) ;; position of (2 byte) id (defconstant IP-frag 20) ;; position of (2 byte) fragment flags and offset (defconstant IP-ttl 22) ;; position of ttl (defconstant IP-proto 23) ;; position of protocol (defconstant IP-checksum 24) ;; position of (2 byte) checksum (defconstant IP-source 26) ;; position of (4 byte) source address (defconstant IP-dest 30) ;; position of (4 byte) dest address (defconstant IP-options 34) ;; position of IP options (variable length) (defvar IP-optlen 0) ;; #bytes IP options, rebound by sendpackets ;; tcp constants, to be added to ip-optlen (defconstant TCP-source 34) ;; position of (2 byte) source port (defconstant TCP-dest 36) ;; position of (2 byte) dest port (defconstant TCP-seq 38) ;; position of (4 byte) sequence # (defconstant TCP-ack 42) ;; position of (4 byte) acknowledgment # (defconstant TCP-offset 46) ;; left half of this byte is length of tcp header (defconstant TCP-bits 47) ;; right 6 bits are urg,ack,psh,rst,syn,fin (defconstant TCP-window 48) ;; position of (2 byte) window (defconstant TCP-checksum 50) ;; position of (2 byte) checksum (defconstant TCP-urg 52) ;; position of (2 byte) urgent pointer (defconstant TCP-options 54) ;; position of TCP options (variable length) (defvar TCP-optlen 0) ;; #bytes TCP options, rebound by sendpackets ;; this one to be added to (+ ip-optlen tcp-optlen) (defconstant TCP-data 54) ;; position of TCP data ;; find the minimum time for which sleep actually does something (defun find-min-sleep (&optional (iterations 20) &aux (sleep 1.0) delta (prev-delta 2)) (loop for i below iterations do (setf delta (get-internal-real-time)) (sleep sleep) (setf delta (/ (float (- (get-internal-real-time) delta)) internal-time-units-per-second)) ;; sleep took delta seconds (print (list sleep delta prev-delta)) (unless (< delta (* .6 prev-delta)) (return (* 2 sleep))) (setf prev-delta delta sleep (/ sleep 2)))) (defvar min-sleep (find-min-sleep)) (defun sendpackets (&rest rest &key (frequency 1 f-t) (nsec 1 s-t) (npackets 1 p-t) (nbytes 100) IPchecksum TCPchecksum UDPchecksum ICMPchecksum device initialize bits bytes (ip-optlen 0) (tcp-optlen 0) &aux ptime start elapsed instructions) (cond ((and f-t s-t) (setf npackets (* nsec frequency))) ((and f-t p-t) (setf nsec (/ frequency npackets))) ((and s-t p-t) (setf frequency (/ npackets nsec)))) (setf ptime (/ 1 frequency)) (loop while rest do (case (car rest) (:initialize (loop for i from (second (second rest)) to (third (second rest)) do (setf (b i) (aref (car (second rest)) i)))) (:device (setf (slot from 'SA_FAMILY) 1) ;; AF_UNIX/AF_LOCAL (loop for i from 0 below (length (cadr rest)) do (setf (element (slot from 'SA_DATA) i) (char-code (aref device i)))) (setf (element (slot from 'SA_DATA) (length (cadr rest))) 0)) (:bits (warn "bits not yet implemented")) (:bytes (if (= 4 (length (cadr rest))) (push (cadr rest) instructions) (let ((val (third (cadr rest)))) (loop for i from (1- (second (cadr rest))) downto 0 do (setf (b (+ i (car (cadr rest)))) (logand 255 val) val (ash val -8)))))) ) (setf rest (cddr rest))) (setf start (get-internal-real-time)) (setf instructions (reverse instructions)) ;; original order (loop for i below npackets do (loop for inst in instructions do (let ((val (+ (third inst) (random (- (fourth inst) (third inst)))))) (loop for i from (1- (second inst)) downto 0 do (setf (b (+ i (car inst))) (logand 255 val) val (ash val -8))))) (setf elapsed (/ (float (- (get-internal-real-time) start)) internal-time-units-per-second)) (when (> elapsed nsec) (warn "stopping after only ~A iterations" i) (return nil)) (let ((sleep (- (* ptime i) elapsed))) (when (> sleep min-sleep) (sleep sleep))) (when IPchecksum (ipcsum)) (when TCPchecksum (tcpcsum)) (when UDPchecksum (udpcsum)) (when ICMPchecksum (icmpcsum)) (sendt socket nbytes))) #| more examples (from router2) (defvar zdev "eth1") (defvar zmac #x00a0c97873f400045a41753f) ;; find from tcpdump + ping (defvar zsrc #x0a000204) ;; ip addresses (defvar zdst #x0a000202) (defvar zports #x10000017) (defvar zseq #x1234) (defvar zack 0) ;; to be set when the syn-ack arrives (defun tcpsyn () (Sendpackets :device zdev :ipchecksum t :tcpchecksum t :initialize default-ip :nbytes 54 :bytes (list ip-length 2 40) :bytes (list macto 12 zmac) :bytes (list ip-source 4 zsrc) :bytes (list ip-dest 4 zdst) :bytes (list (+ ip-optlen tcp-source) 4 zports) :bytes (list (+ ip-optlen tcp-seq) 4 zseq) :bytes (list (+ ip-optlen tcp-ack) 4 #x0) :bytes (list (+ ip-optlen 46) 4 #x50020100))) (defun tcpack () (Sendpackets :device zdev :ipchecksum t :tcpchecksum t :initialize default-ip :nbytes 54 :bytes (list ip-length 2 40) :bytes (list macto 12 zmac) :bytes (list ip-source 4 zsrc) :bytes (list ip-dest 4 zdst) :bytes (list (+ ip-optlen tcp-source) 4 zports) :bytes (list (+ ip-optlen tcp-seq) 4 (+ 1 zseq)) :bytes (list (+ ip-optlen tcp-ack) 4 (+ 1 zack)) :bytes (list (+ ip-optlen 46) 4 #x50100100))) ;; usage (tcpsyn) (setf zack #x ...) ;; from the reply (tcpack) |# |
From: Sam S. <sd...@gn...> - 2004-02-25 16:55:33
|
> * Don Cohen <qba...@vf...3-vap.pbz> [2004-02-23 12:42:15 -0800]: > > Fred Cohen writes: > > Here: > > call-rawsock.lsp > ... > > rawsock.c: > ... > > Maker: > ... > > thingstofix: I have not seen any code from Fred. > Not quite the format I expected, but I guess it'll do. > > I hereby contribute one more file to that set: > lisp interface for sending packets what is the license? GPL? LGPL? -- Sam Steingold (http://www.podval.org/~sds) running w2k <http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/> <http://www.mideasttruth.com/> <http://www.honestreporting.com> I don't want to be young again, I just don't want to get any older. |
From: <don...@is...> - 2004-02-25 17:56:19
Attachments:
raw-fc
|
Sam Steingold writes: > I have not seen any code from Fred. Very strange. The message I got contained these headers: Subject: Re: Sockets support... (UDP) To: don...@is... (Don Cohen) Date: Sun, 22 Feb 2004 20:17:36 -0800 (PST) Cc: cli...@li..., br...@cl... (Bruno Haible) From: Fred Cohen <fre...@al...> And yet I don't see it in the mailing list archive. I got it. I wonder whether Bruno got it. I attach it below. > what is the license? GPL? LGPL? If there is no license does that make it public domain? Since it requires clisp to run, is that any different from GPL ? |
From: Sam S. <sd...@gn...> - 2004-02-25 21:08:18
|
> * Don Cohen <qba...@vf...3-vap.pbz> [2004-02-25 09:45:34 -0800]: > > Sam Steingold writes: > > I have not seen any code from Fred. > > Very strange. The message I got contained these headers: > Cc: cli...@li..., br...@cl... (Bruno Haible) if his "From:" address is not subscribed to clisp-devel, his message was discarded. > I attach it below. OK, this is a concatenation of a bunch of files. Someone who is planning on using this should split these into individual files, write documentation and other infrastructure &c. then this will be ready to go into clisp cvs. > > what is the license? GPL? LGPL? > > If there is no license does that make it public domain? > Since it requires clisp to run, is that any different from GPL ? no, absolutely not. it makes it copyright by the author with all the rights reserved to the author. both you and Fred must make an explicit statement that you are distributing these files under a specific license. the same statement will be required of the person who will package these into a module form. -- Sam Steingold (http://www.podval.org/~sds) running w2k <http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/> <http://www.mideasttruth.com/> <http://www.honestreporting.com> Small languages require big programs, large languages enable small programs. |
From: <don...@is...> - 2004-02-26 06:36:58
|
Sam Steingold writes: > both you and Fred must make an explicit statement that you are > distributing these files under a specific license. I suppose GPL is the best for the user? Since this depends on clisp which is GPL, this adds no further restrictions, correct? |
From: Sam S. <sd...@gn...> - 2004-02-26 15:13:45
|
> * Don Cohen <qba...@vf...3-vap.pbz> [2004-02-25 22:25:54 -0800]: > > Sam Steingold writes: > > both you and Fred must make an explicit statement that you are > > distributing these files under a specific license. > I suppose GPL is the best for the user? > Since this depends on clisp which is GPL, this adds no further > restrictions, correct? One might argue that if you release this module under LGPL, then proprietary code will be able to use it. IANAL - and I am sure RMS would be outraged :-) -- Sam Steingold (http://www.podval.org/~sds) running w2k <http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/> <http://www.mideasttruth.com/> <http://www.honestreporting.com> main(a){a="main(a){a=%c%s%c;printf(a,34,a,34);}";printf(a,34,a,34);} |
From: Sam S. <sd...@gn...> - 2004-03-22 22:00:30
|
Don, if you want the raw-sock module to come with the next CLISP version, then the right time to submit it is NOW. thanks. -- Sam Steingold (http://www.podval.org/~sds) running w2k <http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/> <http://www.mideasttruth.com/> <http://www.honestreporting.com> Winners never quit; quitters never win; idiots neither win nor quit. |
From: <don...@is...> - 2004-03-26 07:03:34
|
Sam Steingold writes: > Don, > if you want the raw-sock module to come with the next CLISP version, > then the right time to submit it is NOW. > thanks. I've not been trying ignoring you, but it seems easier said than done. I did manage to build a version from a 2.31 with the modifications for w-b-s nohang and large files, but that was last fall. I now can't find the files that Fred sent. I recall that his posting didn't make it to the list. I thought I resent to the list but now I can't find that posting. If you know where it is, please advise. Maybe I can find the version I built before, but then, that might not qualify as what Fred contributed. |
From: Sam S. <sd...@gn...> - 2004-03-26 14:44:38
|
> * Don Cohen <qba...@vf...3-vap.pbz> [2004-03-25 22:56:10 -0800]: > > I now can't find the files that Fred sent. I recall that his posting > didn't make it to the list. I thought I resent to the list but now I > can't find that posting. If you know where it is, please advise. gmane.org is your friend. http://article.gmane.org/gmane.lisp.clisp.devel:10977 http://article.gmane.org/gmane.lisp.clisp.devel:10983 -- Sam Steingold (http://www.podval.org/~sds) running w2k <http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/> <http://www.mideasttruth.com/> <http://www.honestreporting.com> If You Want Breakfast In Bed, Sleep In the Kitchen. |