Slashdot Mirror

I've got a 1995-era BURKS (Brighton University Resource Kit) CD around here somewhere - as luck would have it, it's still preserved on the web in all its Web 1.0 glory at

http://burks.brighton.ac.uk/burks/

I know you're exaggerating, but didn't browsers do that for forms submitted via POST?

I'm not really exaggerating; check out the error message FF3 throws up for a self-signed cert:

http://centrim.mis.brighton.ac.uk/more/h/tutorial/sscert-freeman-ff3/resolveuid/e90db9262cef2ca16bd4d9d16a939fa3

It really does say "Get me out of here!" and very nearly the other nonsense I suggested...

http://burks.brighton.ac.uk/burks/linux/rute/node1 7.htm quotes it as etcetera configuration files. others who are quoting it as an acronym may also double as alternative logical viewpoints, however, all unix configuration files are 99% of the time plain text files by default. that's just the way it is.

reading too much into the naming can be dangerous. consider /usr, generally i see it as abbreviation for "user customised files", reason being that /bin is obviously going to be very similar on all unix-like systems. /usr/bin is generally used for customised install files, things that are created after install.

but what about reading this name as "/user files", which then creates the awful /use/home layout, yuck!

An excerpt from a bit longer essay I wrote:

In August 1980, Byte magazine published its issue on the Forth programming language

At that time, I was working with Control Data Corporation's PLATO project, pursuing a mass market version of that system using the Intelligent Student Terminal (IST). The IST's were Z80 processor terminals sporting 512*512 bit mapped displays with touch sensitive screens and 1200bps modems that went for about $1500. We were shooting for, and actually successfully tested, a system that could support almost 8,000 simultaneous users on 7600-derived Cybers (the last machine designed by Seymour Cray to be marketed by CDC --with 60 bits per word, 6 bits per character, no virtual memory, but very big and very fast) with under 1/4 second response time (all keys and touch inputs went straight to the central processor) for $40/month flat rate including terminal rental. Ray Ozzie had been working at the University of Illinois on offloading the PLATO central system to the Z80 terminal through downloaded assembly language programming, doing exotic things like "local key echo" and such functions.

I was interested in extending Ray's work to offload the mass-market version of the PLATO central system. In particular I was looking at a UCSD Pascal-based approach to download p-code versions of terminal functions -- and even more in particular the advanced scalable vector graphics commands of TUTOR (the "relative/rotatable" commands like rdraw, rat, rcircle, rcircleb, etc.) if not entire programs, to be executed offline. Pascal was an attractive choice for us at the time because CDC's new series of computers, the Cyber 180 (aka Cyber 800) was to have virtual memory, 64 bit words, 8 bit characters and be programmed in a version of the University of Minnesota Pascal called CYBIL (which stood for Cyber Implementation Language). Although this was a radically different architecture than that upon which PLATO was then running, I thought it worthwhile to investigate an architecture in which a reasonable language (you should have seen what we were used to!) could be made to operate on both the server and the terminal so that load could be dynamically redistributed. This idea of dynamic load balancing would, later, contribute to the genesis of Postscript.

Over one weekend a group of us junior programmers managed to implement a good portion of TUTOR's (PLATO's authoring language) advanced graphics commands in CYBIL. Our little hunting pack at CDC 's Arden Hills Operations was in a race against the impending visit of Dave Anderson of the University of Illinois' PLATO project who was promoting what he called "MicroTUTOR". Anderson was going to take the TUTOR programming language and implement a modified version of it for execution in the terminal -- possibly in a stand-alone mode. Many of us didn't like TUTOR, itself, much. Indeed, I had to pull teeth to get the authorization to put local variables into TUTOR -- and we were determined to select a better board from our quiver with which to surf Moore's Shockwave into the Network Revolution. CDC management wasn't convinced that such a radical departure from TUTOR would be wise, and we hoped to demonstrate that a p-code Pascal approach could accomplish what microTUTOR purported to -- and more. We quickly ported a TUTOR central sy

An excerpt from a bit longer essay I wrote:

In August 1980, Byte magazine published its issue on the Forth programming language

At that time, I was working with Control Data Corporation's PLATO project, pursuing a mass market version of that system using the Intelligent Student Terminal (IST). The IST's were Z80 processor terminals sporting 512*512 bit mapped displays with touch sensitive screens and 1200bps modems that went for about $1500. We were shooting for, and actually successfully tested, a system that could support almost 8,000 simultaneous users on 7600-derived Cybers (the last machine designed by Seymour Cray to be marketed by CDC --with 60 bits per word, 6 bits per character, no virtual memory, but very big and very fast) with under 1/4 second response time (all keys and touch inputs went straight to the central processor) for $40/month flat rate including terminal rental. Ray Ozzie had been working at the University of Illinois on offloading the PLATO central system to the Z80 terminal through downloaded assembly language programming, doing exotic things like "local key echo" and such functions.

I was interested in extending Ray's work to offload the mass-market version of the PLATO central system. In particular I was looking at a UCSD Pascal-based approach to download p-code versions of terminal functions -- and even more in particular the advanced scalable vector graphics commands of TUTOR (the "relative/rotatable" commands like rdraw, rat, rcircle, rcircleb, etc.) if not entire programs, to be executed offline. Pascal was an attractive choice for us at the time because CDC's new series of computers, the Cyber 180 (aka Cyber 800) was to have virtual memory, 64 bit words, 8 bit characters and be programmed in a version of the University of Minnesota Pascal called CYBIL (which stood for Cyber Implementation Language). Although this was a radically different architecture than that upon which PLATO was then running, I thought it worthwhile to investigate an architecture in which a reasonable language (you should have seen what we were used to!) could be made to operate on both the server and the terminal so that load could be dynamically redistributed. This idea of dynamic load balancing would, later, contribute to the genesis of Postscript.

Over one weekend a group of us junior programmers managed to implement a good portion of TUTOR's (PLATO's authoring language) advanced graphics commands in CYBIL. Our little hunting pack at CDC 's Arden Hills Operations was in a race against the impending visit of Dave Anderson of the University of Illinois' PLATO project who was promoting what he called "MicroTUTOR". Anderson was going to take the TUTOR programming language and implement a modified version of it for execution in the terminal -- possibly in a stand-alone mode. Many of us didn't like TUTOR, itself, much. Indeed, I had to pull teeth to get the authorization to put local variables into TUTOR -- and we were determined to select a better board from our quiver with which to surf Moore's Shockwave into the Network Revolution. CDC management wasn't convinced that such a radical departure from TUTOR would be wise, and we hoped to demonstrate that a p-code Pascal approach could accomplish what microTUTOR purported to -- and more. We quickly ported a TUTOR central sy

My experience with spreadsheet macro developers (MS and Lotus) who grow bold is that newbies have horrible "prediction" skills and factoring skills. Prediction skills is the ability to guess where future changes are fairly likely and make the code able to handle those without needing total overhauls or lots of rework and digging. That ability generally requires experience in maintenance.

Do not put code in your program that might be used. Do not leave hooks on which you can hang extensions. The things you might want to do are infinite; that means that each has 0 probability of realization. If you need an extension later, you can code it later and probably do a better job than if you did it now. And if someone else adds the extension, will he notice the hooks you left? Will you document this aspect of your program?

What do you think of interaction design patterns or usability patterns?

I didn't know what they were. I ended up looking here. The closest thing in my experience with this is with style guides of various GUI's. But this is better. I think this is very much in the spirit of software design patterns. These are best practices and are well thought out. The ideas are certainly reusable.

But it's tough to run C on that kind of architecture. C wants pointers to be addresses. The "array is a pointer" convention is a bad fit to a true segmented architecture. You can run Pascal just fine, but running C is tough. It can be done, but basically requires allocating all the variables in one big "array" at the hardware level, so you lose the protection. When C came in, the Burroughs machines (by then the Unisys A series) died off.

So it's quite possible to fix this, but you have to dump C. This may happen as Java and C# get more traction.

C++ doesn't help. It's part of the problem.

Oh that's easy.

All you need is a little assembler and you'll be set.

HCF - Halt and Catch Fire

HCF

I don't think Apple wants to start making a Cocoa framework for Windows

And they especially wouldn't want to call it Yellow Box.

(I'm not sure whether it was ever released. The Wikipedia article on NeXT appears to be saying some beta releases might have been made before it disappeared.)

Look up some info. Just because YOU can't think of any other logic doesn't mean it doesn't exist. Now go back to your LEDs.

Is this at all related to the Visix Looking Glass desktop manager for UNIX?

Your "what if's" are utterly devoid of fact and ignore reality entirely. "What if" doesn't mean shit.

This wasn't a "what if". Apple's corporate behavior was a blatant and reprehensible attack on the ability of other people to write software and innovate. The only reason Apple's actions didn't have more serious consequences because Apple didn't even own the intellectual property and because the company eventually just became irrelevant. See here for some background info.

Every company tries to lock in, that's what companies do.

So, you are saying Apple really is just like any other company. But they actually are not: their behavior was far worse. Apple's 1989 lawsuit was a kind of legal attack on the ability of people to write software that has been unmatched to this day.

The '186 was a 16bit CPU which ran at 6MHz (versus 4.77MHz for the 8/16bit hybrid 8088 in the IBM PC), and, among other improvements, had a number of VLSI support chips integrated, which kept the system cost down.

it's http://burks.brighton.ac.uk/

they usually include a linux distro iso with each release.

As memory got cheaper, Moore was prevailed upon by the FORTH community to introduce a more flexible naming system, say, one where the whole names of FORTH words were stored, not just their first three letters. Finally, the magazine FORTH DIMENSIONS posted letters which lampooned the idea by wri---- lik- thi-.

I can't find the originals, but Moore responded in kind:

DEA- EDI---

I AM AFR--- THA- THE LET--- IN THE LAS- ISS-- ABO-- FOR-- INC-- USI-- ONL- THR-- LET--- NAM- FIE--- HAS HAD THE OPP----- EFF--- FRO- WHA- THE WRI--- WAN--. HIS LET--- ( LIK- THI- ONE ) SHO-- THA- SAV--- ONL- THR-- LET---- AND COU-- IS JUS- ABO-- OPT---- IN TER-- OF A TRA-- OFF BET---- SAV--- MEM--- AND KEE---- LEG----. WE STI-- DON- SEE THE NEE- FOR 31 CHA------ NAM-- IN THE GEN---- CAS-.

YOU-- TRU--

CHU-- MOO--

FOR-- INC-

Of course all this is easier in functional languages, because you don't have to worry about state, identical trees will always evaluate to the same value. Not so in Java, if any of the nodes refer to global data.

I wonder how often Gosling talks with Guy Steele, who was pivotal in the development of both Scheme and Java. I'd love to see what they'd come up with if they put their brains together.

Floptical disks were floppies that used an optical tracking mechanism to align the magnetic head with the floppy tracks to achieve increased track density.

Oops. It was an AMD 29K processor. Information on the 29030 Information on the 29000 processor

Now, the IBM 1620 didn't have hardware addition. You had to load in a lookup table that contained the answers to "2+2", "2+3", etc...

Most transmission waveforms do NOT translate 10101 and so on as high-low-high-low-high pulses because of the potential for error. This is true for all transmission lengths, both short and long.

As an example, Ethernet uses Manchester encoding. There are many, many other schemes for this that accomplish the same basic task.

In short, nobody uses straight binary pulses for data transfer because its unreliable. Using shifting voltages would compound the problem.

ISTR that the DEC Alpha's EV bus protocol was named after 'Electric Vlastic' where Vlastic is a brand of pickles. I guess their engineers liked doing this too.

Actually UNIX owes as much to the Berkeley Timeshring System developed for Project Genie running on the hacked SDS 930 that became the SDS 940 as it does to Multics.

The UNIX name pun and the command names like "ls" are Multicisms but fork() is from Project Genie

RAM? This was WAY before RAM was invented! Here are more details on the IBM 1620, this was in 1959. There was 20,000 core memory locations, each capable of holding a digit, so 300 of them, or 1.5%, would be used for the math tables. They wasted a lot more than that because there were 16 possible codes available for each memory location, but only 10 of them were used.

In order to complete this, a set of regression tests were written. For example, if the amount of money collected doesn't match up to our order table, we get notified via our cellphone's text messaging as soon as the cronjob picks it up.

What you describe isn't regression testing. Regression testing "is a quality control measure to ensure that the newly-modified code still complies with its specified requirements and that unmodified code has not been affected by the maintenance activity." More accurately what you've done is paranoid programming. Really, these two things are orthogonal.

My question is, how common is this for the software industry? My company had never heard of this before I came along. Is it the norm? (When you answer, also say whether or not your company does risk management.)

This depends. Every company I've worked for has claimed to be concerned with mitigating risks both in the testing phases and post-release phases of the software development lifecycle. However, the amount and kind of testing and programming actually done have varied wildly and always ends up being determined by the industry for which the software is being built. In your case, money is the biggest factor. Organizations such as banks and other financial institutions are highly risk-averse due to the responsibilities and legal concerns related to handling others' money. It follows that these organizations regularly conduct formal testing of their code as well as "program paranoid" to mitigate screw-ups. In start-up's I've worked at in the past, this wasn't nearly the case since it was more important to get a product out the door and this sort of testing/coding always went out the window with looming deadlines.

So to answer your question, yes, regression testing (and paranoid programming) are highly common in the IT industry and their respective importance is a function of the risk aversion of the intended users/customers. My advice is to always practice good, paranoid, professional programming augmented by formal testing procedures. Vary the time spent on each to achieve the appropriate balance.

Frankly, the best way to enlighten yourself on this matter is to educate yourself in the ways of Extreme Programming. The horribly trendy name aside, this is the truly the only management fad I've seen in 10+ years that holds any merit.

Ran strings on winsock.dll that comes in WinXP Professional.

Only one string referring to BSD popped up:
"BSD Socket API for Windows"

Now, how precisely does this imply use of actual BSD source code? Especially considering that the following website states the above string is a description of the DLL from Win 3.1 days.

To me that reads as "Microsoft implementation of BSD API" with the qualifier "for Windows"

I won't clutter this with too many "I was there" stories nor add my view of the value of PDF to prepress operations. But ever since Sun rolled over on its support from its own Display PostScript-based Network extensible Window System (NeWS) in the face of the tide of X, I have been intrigued by how Adobe has managed to become so important to the Web without ever really getting it.

At its heart, Adobe never quite manages to shake its cultural foundation in the (permanent) placement of dots on paper and take on the very different challenge of realising the potential of interactive displays and ever "under construction" documents. (Nor does much of the printing industry but that is another story.)

Having been seduced by PostScript from the start, how do we now deal with the enigmatic prospect that Adobe also appears to be the driving force behind the great white hope of Scalable Vector Graphics (SVG)?

Hey, it goes way back before that.

This is just a newfangled way of turning a bunch of ICMP packets into "ICBM addresses (Jargon File, 1994), but on a color screen, rather than a humongous plotter ;-)

We have Stephen Cole Kleene to thank for both recursion theory and regular expressions. According to a blurb in Friedl's Mastering Regular Expressions (pg. 60):

"The seeds of regular expressions were plated in the early 1940s by two neurophysiologists, Warren McCulloch and Walter Pitts, who developed models of how they believed the nervous system worked at the neuron level.

"Regular expressions became a reality several years later when mathematician Stephen Kleene formally described these models in an algebra he called regular sets. He devised a simple notation to express these regular sets, and called them regular expressions.

I'm still looking for reprints of Kleene's papers on regular expressions, but they seem to be hard to come by. Maybe I'm just looking in the wrong places.

Too late. I just trademarked "TM" as a means of identifying a trademark. That means you need to put my "TM" after each "TM" you use. (No, you can't get out of it by using a Kleene star.)

Sorry, can't talk now. Got a meeting with my lawyers.

More info: geeky, geekier, geekiest. An interesting tidbit is that the data is interleaved serially, meaning the data and the parity codes are spread across wide arcs of disc. That's why it's recommended to clean discs from the center out, not around the discs (so if you scratch it, you damage unrelated segments).

So, I think the idea of duplicating your CD-Rs and sending them to your relatives is a good one. For more fault tolerance, just send some more copies to some more relatives.