_c_

https://archive.org/details/utzoo-wiseman-usenet-archive

Since we are joking, assuming that the MOV instruction exists on many CPU's, could the input for this compiler be considered a needed "portable assembly language"?

http://cr.yp.to/qhasm/20050129-portable.txt

In theory it should not make a difference but my scripts seem to run faster when I use exec after pipe.

Normally I would only add exec to the last command in the script, as djb does. But then I started experimenting with using it after pipes.

If you or anyone can explain why this could make scripts "seem" to execute faster, I would be grateful.

Here's the shell source: ftp://ftp.netbsd.org/pub/NetBSD/NetBSD-release-7/src/bin/sh

Incidentally, have you ever tried execlineb? I use that sometimes too.

Thanks for taking the time to comment.

Multiple arguments could be added if you want that. I personally do not need it as I search the cmdline patterns I need without using spaces. I use dots instead. Quick and dirty.

I write 100's of these small scripts for my own use only so I have my own style, peculiar as it may be. I never need indentation because I always keep scripts short; I only use it occasionally and randomly.

I do not use -e with sed, unless I'm using branches or loops.

The execs seem superfluous but actually make a difference, at least on the UNIX I use. Try it with and without and see if you notice.

All my scripts are portable to Bash, but they're also portable to the most basic of Bourne-compatible shells too. I do not use Bash.

s/Unix/Linux/

The following can be adapted to provide other information: whatever procfs provides. This is a rough equivalent of "pgrep -fl .|less". Work-in-progress. Don't know if Linux grep has "-a" option.

  #! /bin/sh 
  # Almquist clone, not Bash
 
  case $# in
  0)
  exec grep -a . proc/[0-9]*/cmdline \
  |exec tr '\000' '\040' \
  |exec sed '
             /grep -a .* proc/d;
             #parent: '"$$"';
             s/proc./ /;
             s/\/cmdline:/ /;
 ' \
  |exec less
  ;;
 
  *)
  exec grep -a . proc/[0-9]*/cmdline \
  |exec tr '\000' '\040' \
  |exec grep $@ \
  |exec sed '
             /grep '"$@"'/d;
             s/proc./ /;
             s/\/cmdline:/ /;
 ' \
  |exec less
  esac

Why do programmers try to convince others which programming language to use? Why should they care what languages others are using?

I do not understand your argument.

To give an example, there is a lot of free open source software mirrored all over the internet, mostly on ftp servers, but also on http, rsync, etc.

If you use Linux or BSD you probably are using some of this software. If you use the www, then you are probably accessing computers that use this software. If you drive a new Mercedes you are probably using some of this software. There are a lot of copies of this code in a lot of places.

Is that centralized? Does anyone hosting a mirror ("repository") "own" the software? Is it the same person or entity hosting every mirror?

Compare Google's copies of everyone else's data, also replicated in a lot of places around the world. Who "owns" this data?

So you are admitting you have not tested this and you are just going by what you read.

When was the last time you used any "smaller Unices"?

Anyway, even if the problems with -nographic on x86 have been fixed on other non-FreeBSD BSD's (and I have my doubts), my comment that compiling qemu has become a substantial undertaking still stands. I suspect you've probably never even tried compiling it yourself but that will not stop you from commenting.

I compile Bochs statically on low powered computers with no problems. Cannot say the same for Qemu. Even you're not using x11 they expect you to have x11 libraries at compile time. As with most programs that grow so large, there are more than a few dependencies one can do without.

Worse is that Google tries to stop scraping. It's like they don't want anyone to see past the first page of results.

They could scrape your website and then they prevent you form scraping your own data back.

The whole process is silly; it reflects the duct tape and chicken wire nature of the www.

No one should have to "scrape" or "crawl".

Data should be put into a open universal format (no tags) and submitted when necessary (rsynced) to a public access archive, mirrored around the world.

This to bridge the gap until we reach a more content addressable system (cf. location based).

Clients (text readers, media players, whatever) can download and transform the universally formatted data into markup, binary, etc. -- whatever they wish, but all the design creativity and complexity of "web pages" or "web apps" can be handled at the network edge, client-side.

"Crawling" should not be necessary.

No one should have to store HTML tags and other window dressing for data.

Dream on.

Are you saying you yourself do this? You're using BSD, running in VGA textmode, from which you run qemu with -nographic to load an image of another OS? You yourself are doing this?

Most of "major VPS providers" I know use Linux, not BSD. (Yes, there are some exceptions but the reliance on Linux is almost universal.)

I would love it if you were right and I am wrong, but I seriously doubt you have tested this recently. I will happily give Qemu another go if you have tested this recently and it worked.

I was referring to how long it takes to build from source and how much RAM and CPU it uses while building. The interface is fine. I love Qemu. Bellard writes great software. My early experiences with it were very good. But it has grown to become a whale of a program. I had to switch to Bochs.

What OS are you using?

Is it working for you in VGA text mode (no x11)?

Is this now working on other UNIX-like OS besides Linux?

I have had problems with -nographic in the past and I know others who have as well, but maybe it works reliably now?

From Rob Pike quote at the end, after the Ryan Dahl quote: "... the UNIX/POSIX/Linux systems of today are messier, clumsier and more complex than the systems the original UNIX was designed to replace."

"Messier, clumsier and more complex" are adjectives that could describe almost all of today's software vis a vis software from the 1970's. This is not a criticism of today's software it is just the evolution (or devolution) as it happened, an objective observation.

By and large, programmers do not attempt to make software more clean, more efficient or less complex. Most do not spen all their time cleaning up messy code, fixing bugs, or sacraficing inefficiency at the expense of usability or abundance of "features". And almost none spend time removing code and reducing complexity.

They do the opposite: add features, pursue "ease of use" at the expense of common sense and incessantly generate and commit code believing that any decline in commits or "software updates" signals a project is "dead", not "modern" and probably in need of a "replacement". Again, I'm not critiquing this, I am just stating the facts. This is what they do.

Not sure about Pike, but the reason I think some older software is higher quality than most newer software is not because it was or is high quality in an objective sense. It's because today's software is so low in quality and in too many cases worse than yesterday's. Indeed, it's "messier, clumsier and more complex."

In an objective sense, 1970's UNIX is nothing to celebrate. But compared to the then-alternatives, what came afterwards, and what we use today, it can be held in high regard. It's only good in a relative sense. Everything else was and still is so bad. (Why is anyone's guess.)

Avoiding the hassles Dahl alludes to[1] brings me a certain feeling of satisfaction. My language of choice is Bourne shell. And if I am just working with text, such as reading and writing, I do not use a graphics layer - no X11.

The question is: Does Pike's comment apply to Plan 9?

1. Not to mention avoiding the needless complexity and obscurity of Microsoft Windows.

+1 for being able to run on Bochs.

There's nothing minimalistic about Qemu. It's an enormous resource intensive program to build. And it's not even easy to run in text mode (no x11). "Qemu-lite" is sorely needed.

"While I wouldn't necesarily call it relevant to HN..."

The song "Are you sure Hank done it this way?" was used in the computer game Grand Theft Auto V.

I have always liked the guitar on that song, I read HN, but I am not a gamer or game developer.

MS-DOS was written for only one processor.

UNIX kernels could run on a variety of processors, including ARM; UNIX was a relative latecomer to x86.

As for Windows kernels, both then and now, UNIX kernels are open source and do not deliberately obscure system calls.

It's not unreasonable for someone to argue the benefits in writing programs for UNIX.

"View this page as what it is..."

It's one of the few pages written about UNIX assembly. That's how I view it. Years later it was put into The FreeBSD Handbook.

"It is simply a matter of familiarity."

Your comment focuses on how fast the compiler generates lines of assembly, after the programmer has constructed a solution.

But unless I have misunderstood the author was focusing on how fast the programmer can construct a solution.

The final step of depressing keys to input the solution into the computer can be sped up by using libraries and perhaps macros.

It's also possible to write programs ("code generators") that generate lines of assembly based on a "template". And that "template" need not be written in C or any other popular computer language.

It could be some "DSL", a shorthand for assembly, that the programmer creates for himself.

djb's qhasm might be considered an example.

While it may be generally true that C requires less key punching than assembly (certainly it requires fewer "lines"), this does not mean constructing a solution in C necessarily comes faster than constructing one in assembly... if the programmer is familiar and efficient working with assembly.

Use int 80h for UNIX

How does Charles handle gzip,deflate?

I use a short shell script for MITM.

It simply runs two socats and netsed in between them.

I create ca.pem and server2.pem with openssl, install ca.pem on my device and sign server2.pem with ca.pem.

I redirect traffic from device to my computer running the script.

Low complexity, works reliably, costs me nothing.

Downside is it only does one remote site at a time.

sslsplit works well too but it does not handle gzip,deflate.

rm only removes OS "metadata" -- it removes the link to the reference. The file's data is not touched.

Here's a stupid but effective way I came up with to delete the data in files when they are too large to be stored in RAM:

Use dd on the device where the file is stored.

Files intended for eventual deletion can be stored on their own dedicated virtual block devices, or "file-backed virtual disks".

Unless things have changed, on OpenBSD these virtual block devices can be created from /dev/vnd.

To create a location to store the file(s) at, create an empty "backing" file with dd, associate it with a vnd, newfs the vnd and mount it.

To delete all the files on the mounted vnd, either umount and dd if=/dev/zero of=/dev/vnd{no}d or dd if=/dev/zero of=rvnd{no}d and umount.

One can also configure a cryptographic disk device over the vnd using a random throwaway password.