To LUGNET HomepageTo LUGNET News HomepageTo LUGNET Guide Homepage
 Help on Searching
 
Post new message to lugnet.off-topic.geekOpen lugnet.off-topic.geek in your NNTP NewsreaderTo LUGNET News Traffic PageSign In (Members)
 Off-Topic / Geek / 288
  Re: Perl rules!
 
[removed lugnet.off-topic.debate from crosspost list] (...) I'd say, back in 1983, the lack of virtual memory and the 640KB limit was no big deal (in the PC industry). By 1989, it was becoming unfortunate. By 1991, it was getting really bad. And by (...) (25 years ago, 20-Jul-99, to lugnet.off-topic.geek)
 
  Re: Perl rules!
 
(...) And why did IBM stick all the ROM and system stuff in high memory (>640K), rather than low memory? If they had done that, it would have been (more) possible to extend the address space without totally losing backwards compatibility. Or if (...) (25 years ago, 20-Jul-99, to lugnet.off-topic.geek)
 
  Re: Perl rules!
 
(...) Wait a minute. Feel free to correct me if I'm wrong, but the segmented memory architecture allowed you to create absolutely *tiny* programs that did wonderful things. And you could fit tons of these programs on an affordable *floppy* disk. I (...) (25 years ago, 20-Jul-99, to lugnet.off-topic.geek)
 
  Re: Perl rules!
 
Don Heyse wrote in message ... (...) What, Eighteen Megs And Constantly Swapping? Ever tried putting emacs on anything smaller than a CD? (...) Apparently the latest Caldera is quite good for that - all-GUI install, no reboots and autodetection of (...) (25 years ago, 21-Jul-99, to lugnet.off-topic.geek)
 
  Re: Perl rules!
 
(...) Well, I've been running Emacs on a P150 system with 643MB harddisk for three years now. That's smaller than a CD, right? Or were you refering to transporting the Emacs sources on a CD? I've used a set of 1440KB disks to do that. I needed eight (...) (25 years ago, 21-Jul-99, to lugnet.off-topic.geek)
 
  Re: Perl rules!
 
(...) I do, quite regularly. Windows NT 4.0, Service Pack 5. The last reboot was about two weeks ago when I upgraded from SP3 to SP5; before then, my workstation was up for about three weeks. I have a cow-orker who's had Linux up without a reboot (...) (25 years ago, 21-Jul-99, to lugnet.off-topic.geek)
 
  Re: Perl rules!
 
(...) How did the segmented architecture enable the creation of tiny programs? (...) So? This is SVGA, and most video cards seem to not offer 4-bit color modes in resolutions above 800x600. So LDraw will happily work in modes that most video cards (...) (25 years ago, 21-Jul-99, to lugnet.off-topic.geek)
 
  Re: Perl rules!
 
(...) Relative pointers in the same segment take up half as much space as a 32 bit pointer. Depending on what you're doing, the savings here can be considerable. .COM programs used nothing but relative pointers and fit in less than 1 64K segment. (...) (25 years ago, 21-Jul-99, to lugnet.off-topic.geek)
 
  Re: Perl rules!
 
(...) OK, relative-addressing mode is good. But it doesn't require segmented memory. All it requires is an instruction format with a defined result. For example, the conditional-jump instructions on the 6502 microprocessor[1] only used relative (...) (25 years ago, 22-Jul-99, to lugnet.off-topic.geek)
 
  Re: Perl rules!
 
(...) Perhaps you're right, but that jump instruction is relative to the Instruction Pointer which uses a full register. The segmented way you are relative to a segment which only uses half a register. You can take advantage of this half register (...) (25 years ago, 22-Jul-99, to lugnet.off-topic.geek)
 
  Re: Perl rules!
 
(...) OK, at this point I'll have to take your word for it. The segmented address still seems like a high price to pay for a half-register. (...) Maybe this is the case in LEdit -- I don't have knowledge of that source code. But in LDraw, the (...) (25 years ago, 22-Jul-99, to lugnet.off-topic.geek)
 
  Re: Perl rules!
 
(...) That's a good suggestion. Especially because it's something I can make LDAO do. As opposed to some really nifty suggestions I've received which would require changing LDLite, or would be so processing-intensive that they aren't practical. (...) (25 years ago, 22-Jul-99, to lugnet.off-topic.geek, lugnet.cad.dev)
 
  Re: Perl rules!
 
(...) I don't have source to LEdit either, but I used to write CAD software for a living around that time. We used all sorts of colormap manipulating tricks to speed up the rendering. These tricks just don't work in fixed color modes. You have to (...) (25 years ago, 22-Jul-99, to lugnet.off-topic.geek)
 
  Re: Perl rules!
 
(...) You realise what the cost differential you're talking about is, don't you? If IBM had used 68k rather than x86, there's a much better chance today the lucky few would have macs, rather than everybody and his dog having a PC. (...) Yeah. I (...) (25 years ago, 22-Jul-99, to lugnet.off-topic.geek)
 
  Re: Perl rules!
 
(...) Well, there's the cause for your stability: Who would want to use a server named barney? ;-) Cheers, - jsproat (25 years ago, 22-Jul-99, to lugnet.off-topic.geek)
 
  Re: Perl rules!
 
(...) Actually, it would have been a hell of a lot easier, given that you at elast have homogeneous address space. But you do need to rewrite the kernel to be able to access it at all, and we all know how fast MS is at that sorta thing.. (...) And (...) (25 years ago, 22-Jul-99, to lugnet.off-topic.geek)
 
  Re: Perl rules!
 
(...) Uptime wars! barney:/etc$ uptime 9:31pm up 96 days, 9:27, 1 user, load average: 0.13, 0.03, 0.01 barney:/etc$ Jasper (25 years ago, 22-Jul-99, to lugnet.off-topic.geek)
 
  Re: Perl rules!
 
(...) Barney as in "Fred &", BTW, not as in "should die!!1!!!11!". Jasper (25 years ago, 26-Jul-99, to lugnet.off-topic.geek)
 
  Re: Perl rules!
 
(...) Here, lemme help ya... $h0u1d D13!!!!!11!!1 Vb$cR1pT r00L3z!!!111!! hAcK3d bY $uP3r uUaK3 D3aTh K00L hAcK3rZ!!!!!111!!!11!! k3An3U rRE33vE$ 1s g0d!!!...!!!1 :-P Cheers, - jsproat (25 years ago, 26-Jul-99, to lugnet.off-topic.geek)
 
  Re: Perl rules!
 
(...) Your name is Neo, and I claim my 31337 h@x0r toolkit. Jasper (25 years ago, 26-Jul-99, to lugnet.off-topic.geek)

©2005 LUGNET. All rights reserved. - hosted by steinbruch.info GbR