ised

It is the Ubiquiti "OS" that keeps me away.

https://www.ietf.org/mail-archive/web/tcpm/current/msg08204....

Read this first: phttp://www.osnews.com/story.php?news_id=10929

Source code: ftp://ftp.tw.freebsd.org/pub/ports/distfiles/empty-0.6.18b.tgz

Perhaps it was something like a PUT command to append to a user's "mail" file on the recipient computer?

This seems to suggest email was always envisioned as something to be "received" rather that voluntarily "retrieved".

In retrospect, knowing what happened to email, the later idea (e.g., djb's proposal) makes more sense.

The funny part is that even though the "receive" idea is still the core part of the email process, that is not what email users do in practice.

Users "retrieve" their mail from some third party who receives it for them.

First there was "POP" then there was "webmail".

Back in the Stone Age when email was "invented" computers were too expensive for the users to own.

Each user shared the computer with other users.

Each had an email account, usually administered by the organization that owned the expensive computer.

Today computers are inexpensive and seemingly all users own one but they still do not have control of their email accounts.

Some organization is still receiving all their mail before they do. And keeping a copy of course. :)

Then, in more recent history, the domain name "business" (a monopoly run by an organization that derives its "authority" from nowhere), fueled by the popularity of the "www", became the gatekeeper to email.

When was the last time you sent an email to user@[ipaddr]? Originally if my memory of the old RFC's is correct that was how it worked. No domain name needed.

Today, if there is no purchased, monopoly-blessed "domain name", then according to the people who control users' email there is no "valid" email address. No pay, no play. Even if port 25 is open.

Assuming a user who has paid for access to the "internet" wants control of their own email (seems reasonable), then "email" is still an addtional fee.

http://cr.yp.to/proto/taiclock.txt

I am just a dumb user. I use clockspeed (sntpclock, clockadd and clockview) with a short list of compatible servers I consider "reliable". As far as I can tell, it works.

http://cr.yp.to/time.html

Question: Why does the software need to be updated?

Vendor: "Bug fixes."

Question: Can I look at the source code?

Vendor: No.

I agree with agwa that this phenomenon of "automatic updates" goes well beyond root certificates and browser authors such as Microsoft. It is pervasive and seems to be growing.

Perhaps a related line of thought, I find it interesting that we are seeing some again pushing for enabling browsers to have more control over the user's computer. Simply put, as I see it, a user visits a webpage and someone else gets to run their code on the user's computer.

Why stop there? Why not have email attachments that open and execute automatically?

Originally there was the "Java applet" idea in the early days of the www. Then there was Adobe Flash. These days the idea it has several different working names. Obviously neither Java nor Flash is the language of choice. And the browser authors have something to try to put users' minds at ease: "sandboxing". But I see no difference in the issues this raises for users.

Is there any "sandboxing" for the browser itself? The browser and its authors are inherently trusted?

In the same way that root certificates installed on users' computers are "pre-approved"? Who approved them? Are users involved in that approval process?

If the certificate/code in question comes from the browser authors then it must be both necessary for and desired by each and every user?

The problem with automated updates from my perspective is that there are very few software authors who will not try to give me more than I actually need; if I am not careful I end up with the "kitchen sink". Without user intervention, software is like a gas: it will expand to fill space.

As for the CA system, I am my own CA root. The openssl binary is the antithesis of the so-called UNIX philosophy. How many things does it do? Perfect for an example program to include for "testing". This goes to agwa's comment. I use this software but I know it is quality control disaster. Keep those updates coming.

In any event, the only certificates I "trust" are ones which I did not obtain over an untrustworthy network, i.e., the internet. That number is of course zero.

I will sign a certificate to satisfy a browser, but that does not mean I "trust" any part of the process. In practice, outside of organizational use, I see the whole CA scheme as a joke. (But not that its implementation has impeded the success of e-commerce.)

As a user, I play along with SSL/TLS and certificates only to get today's software to work. That's it. A nuisance more than anything else.

Do long load times, visual distractions and page clutter matter?

I posit only when you are accustomed to _not_ experiencing these things.

For me, it is difficult to voluntarily choose 38 connections (how many DNS lookups is that?) and 11 second load times after experiencing 2 second load time and connection to one IP only.

I still find it shocking how many connections today's "average" webpages make to third party domains. It was not always this way. I doubt it would have been feasible with yesterday's bandwidth and memory. Somehow things ramped up to the point of absurdity and it's as if no one noticed.

If there is a "moral dilemma" it should amongst with the ad/tracking folks.

Rather than attach a keyboard, I connect to the RPi via ssh from my laptop. Compiling on the RPi itself is painfully slow in my experience.

I suppose eventually I will ditch x86 and my "laptop" will be ARM too for whatever that is worth. Then I can just focus on ARM assembly.

I never write to the SD card except when I am writing a new image with dd which is not very often. The root filsystem is in RAM (tmpfs). I can remove the card after boot so the slot is free.

I run this way from RAM on x86 too, even when I have a HDD. I like a diskless environment removable external storage for long-term data storage.

The only time I worry about USB stick or SD card read/write speeds is when I am putting a new image on the media with dd. I still wish there was something like a next generation Jornada on the market. A rugged palmtop with Ethernet, WiFi, and USB slots that boots from CF card.

But in 2015 it looks like a development board on scrap plywood with wood screws is the only choice.

But when you mention "wall(1)" it makes it sound like you want to connect to some internet accessible UNIX host via ssh and chat to others who are also connected to that host.

Option 2 would be less complex.

Depending on what software is installed on the host you connect to, there are many possibilities. Back in the old days, talk(1) could be used for split screen chats. Today, tmux(1) would be my choice. Anything that uses UNIX domain sockets could work.

Proof of concept:

Does Darwin have logger(1), syslogd(8) and /etc/syslog.conf(5)?

Decide where to log the messages, e.g., /var/log/messages

Edit /etc/syslog.conf

Start syslogd

logger "your message"

less /var/log/messages

less -F /var/log/messages

tail -f /var/log/messages

Messages have date, time, priority (if any) and hostname.

You said "something basic"; this is about as basic as it gets.

Where in the comment is this statement?

Personally the primary reasons I would want the source code for the kernel and utilities would be 1. to assess its quality and, assuming the quality meets my standards, 2. to modify it to meet my own ends. In my case, the less I have to write things from scratch the better.

Let me know if you still have questions.

But when compared to how large, slow, complicated and opaque the "alternatives" are, UNIX is the clear choice for me.

I can modify and recompile UNIX to meet my own ends. That is all but impossible if I chose an alternative such as Windows.

For example, if I do not want ls to have 30+ options, I can trim it down to just a few options and recompile.

There are other utilities besides ls for viewing file information, e.g., BSD stat(1) or mtree -cp. The later displays mode information in octal which is something ls, despite its 30+ options, does not do.

Or I can write my own simple utility. I am given the full UNIX source code. Where is the source code for Windows?

Personally I keep my filenames short and never use spaces, so I sometimes use the shell's echo builtin and tr(1) to get a quick list of files.

   echo * |tr '\040' '\012'

Because I have become very comfortable with UNIX, any alternatives that others suggest have to be comparable with UNIX on size and simplicity before I will take them seriously.

Currently, I use a kernel source tree that compresses to under 40MB; I can compile kernels with about 200MB of RAM and fully loaded kernels are about 17MB. Userland utilities are usually around 5MB as I prefer to put them in the kernel's embedded filesystem. I do not like to rely on disks. My "IDE" is the same system I am compiling. There is no GUI overhead, everything can be done in textmode. The importance of the preceding two sentences cannot be understated.

I am always willing to consider non-UNIX alternatives that can offer the same or better flexibility, size constraints and simplicity.

But after decades of being open to alternatives, I am still not aware of any.

This seems a truism with respect to many "high value" software products/projects across the computing world. The ones that attract large investment.

The only time I ever use Java is when I use something made by someone else who uses Java. And when their software slows to a crawl or crashes, what can I do? It was not my decision to use Java. It is so pervasive, there's Java on a SIM card, what can a user do? Impossible to avoid.

But as for computers where I can open them up and install my choice of kernel and utilities, I have no need for Java. There is not a single file of Java anywhere in my source tree. I can find code written in terse languages that does everything I need to do with the computer. Code that out-performs Java, easily.

Maybe something written by a small team or even one person. :)

I think that is what makes the ITC field so entertaining. No matter how much cash and how many engineers a company can accumulate, a small team of dedicated people with little to no money, sometimes just one incredible mind sitting at a keyboard, can still create something that wins on performance. Is that not "success" of some sort?

As for Java, I guess it depends on how one defines success.

I like brevity, conciseness, performance and reliablity. Not sure I would label Java as a success under those criteria, but that is just my personal opinion as a user.

In terms of mindshare, Java is a tremendous success.

You mentioned Go. Rob Pikes' OSCON 2010 talk introducing Go had some criticisms of Java with examples. I think he said Java was a symbol of bureaucracy or something to that effect. Let us celebrate the success of bureaucracy. Congratulations Java.

Or UNIX became the embodiment of the concept of "run anywhere"?

The Windows kernel is based on the VMS kernel, right?

And NTFS is based on the VMS filesystem?

http://en.wikipedia.org/wiki/David_cutler

I would have been happy with VMS on the PC.

Instead we got Windoze. How much of our lives has this monstrosity wasted? Just let it die.

Do daemontools' supervise and svscan need fork()?

I hate using Windows and I have never been one to follow MS "recomendations". Are you kidding? I do not work in an IT department.

I used MSYS and Cygwin for many years. Now I use SUA.

The less I have to use Windows the better. It dulls the mind.

If I am forced to use Windows in an Enterprise setting, then I just go to Control Panel and enable the POSIX layer ("SUA"), then download the SDK and install. With some minor changes to the %Path, it just works.

SUA has older versions of tcsh, ksh, vi and many other utilities, including an older Perl and an old GCC toolchain that does work. It is 4.2BSD based. If you are at home on BSD, it is like going back in time.

netcat, tmux, emacs, etc. you would have compile yourself. Maybe OpenSSH would compile and run. I have not tried.

Perhaps an alternative to Cygwin, etc. Not "better" but different. It generally "seems" faster and I find it's more difficult to "break" than Cygwin which in my experience can be very "delicate". The SUA White Paper says SUA comes to within 10% of the speed of native Windows.

The main advantage though, for me, is that this is not "unauthorized third party software" to the extent it comes with Windows and the SDK download comes from Microsoft's Akamai account.

But I am as green as it gets when it comes to Javascript.

I am sometimes forced to use a Windows workstation.

So I installed "super sed" (ssed.exe), a Windows sed, from sed.sourceforge.net.

It is painfully slow. Ridiculously slow.

I'd like to try using Javascript to do some sed-style editing on text that comes through the browser.

Let's say I open up the Javascript console in a browser, e.g., Chrome.

I know little of Javascript but I do know about window.location() and XMLHttpRequest().

Assuming I can get the text I want to edit into the browser window... what do I do next?

Well, you could also ask why do some developers choose to write applications that retrieve HTML but do not process Javascript?

If I recall correctly, for a while the links and elinks browsers experimented with processing Javascript but eventually if I'm not mistaken the developer decided to drop it in future versions.

Why? I do not remember but I know that he did offer an explanation.

I have always thought Javascript generally benefits web developers more than users. And this is not a quality inherent of the language, but it has to do with how this particular language is used in practice.

When I download someone else's C code, compile and run it, I generally have a rough idea of what that code is going to do.

When a "modern web browser" (=not a text-only one) runs any and all Javascript from any web resource, I generally have no clue what that code is going to do. These browsers will automatically load resources from many sources other the one hosting the page to which the user navigates. They will make numerous connections to other addresses (to retrieve "third-party resources") instead of just one to the address the user specifies. Often the Javascript code is coming from a third party. Imagine a pop-up asking for permission each time the browser wants to run Javascript code from somewhere. In the early days of browsers, if I recall correctly, you could require the browser to do this (and the same goes for accepting cookies). I never considered this practical back then and it is certainly not a solution that would be practical today.

And today, when the company that writes the "modern web browser" assures me that it will protect me from malicious Javascript, I have no clue what the "modern web browser" itself is going to do to try to accomplish that. Because I cannot easily compile the "modern web browser" myself. It is not meant to be compiled by users. There is a large amount of implied trust.

It's somewhat like downloading random Windows applications one finds on the www, installing them and running them. Do you trust that Microsoft or some anti-virus company will protect you? That is a tall order.

Whereas if you merely refrain from downloading and installing such programs, if you refrain from blindly opening attachments in email, then you avoid that risk.

By not running Javascript, the user avoids the risk of malicious Javascript, and may even avoid the need for a "modern web browser"... and thereby the high complexity (=higher risk of insecurity) that comes with it. Keeping the user safe from malicious Javascript is a tall order for any browser to fill.

All that said, if I the user can get the information I want from the www without having to run Javascript and hence a "modern web browser", then I will always choose the non-Javascript option simply because _it is often faster and more efficient_, regardless of any possible security benefits.

Thankfully, I rarely need the "modern web browser", even for webmail. It is true that Javascript is frequently an impediment that stands between the user and fast and efficient computing but in my experience it is rarely a show stopper for the user who disables it.

To answer the OP's question: No, as a developer, I do not think you should care. Javascript is a fun language and people will pay you to write in it. For the Javascript developer, life is good. Carry on.

2. Ever tried to read/skim 100's of PDF's in rapid succession? (A common task if you are doing academic research.) It's near impossible. By comparison to reading text documents or viewing images, reading lots of PDF's is SLOW. Need a viewer that can view PDF's as fast as we can view text documents in pagers like less or images in viewers like feh. My suggestion: a viewer that extracts each page as an image and then views the PDF's as a series of images. (Essentially making reading them the job of an image viewer.) The trick is getting the sizing and resolution right, and dealing with hundreds if not thousands of extracted images.

PDF is great for printing. It also looks great on a screen (e.g. for casual, occasional reading, or presentations to an audience). But for reading lots of academic papers or any sort of document in bulk, PDF is absolutely terrible.

Postscript development is really an underappreciated area, I think. How does Apple achieve such lovely text on their displays? I could be wrong but I have always had a hunch their expertise in Postscript plays a role. They were once Postscript pioneers... remember the LaserWriter?

1. Reduce the attack surface, i.e. total LOC. My base system is super small. More complex things can be run on top of it (e.g. via chroot), but the system I boot into is only about 16MB. With some effort, it could be shrunk to about 1/4 of that size.

2. Use only open source software; and refine your methods for searching through code for suspicious things. There's no shortage of open source solutions and folks right here on HN (e.g. Russ Cox) have been kind enough to share some decent methods for efficiently searching through code.

3. Boot from read-only external media, use a memory disk for the root filesystem and use tmpfs for all writable directories/partitions. This way boot times are fast and consistent, more so than with harddisk drives. And with the rootfs in memory, you can remove the external media after booting, freeing up the USB or SD card port for other things. It's very easy to replicate (clone, image, whatever you choose to call it) this system and transfer it to more external media. It takes only a short time to compile from scratch, even on underpowered computers. There is no "software installation". You insert the media and boot. That's it. You get the same pristine system every time you boot.

To anyone who injects doubt and insinuates that such an approach to evading malware as betterunix suggests is infeasible or unachievable: I'm happy to prove you wrong.

For example, producing high quality C code (e.g., arthur whitney or djb's, imo); this is difficult or tedious when done "by hand" but can be made easier by using code generation. There is a beautiful conciseness and consistency to the "model" C code I prefer (e.g. by the above authors). It is well-suited to being generated by a "custom interpreters" and a "DSL". Next to Flex, LISP is my personal favorite for constructing such a code generation system.

Python devotees already follow a similar path when they use Cython. But what do you think the quality of the generated C code is like? Have a look at it.

2. LISP is also a great prototyping language. The final application may not be written in LISP. Or at least parts of it might be in other languages.

Selecting from a limited collection of libraries written (perhaps poorly) by others, as is done with many popular languages, strikes me as a "top-down" approach, not building from the ground up. The collection of libraries defines what you can and cannot do. Now, if you just want to do what everyone else is already doing, this is perfectly acceptable. However if you want to break new ground, you will likely have to write some functions yourself. And, personally, I'd rather do this in LISP.

Maybe it's better to learn to use SWIG or a similar codegen tool and wrap any C library function of your choosing for use in LISP, or Lua, or another language that lacks "batteries"? It's encouraging to me when I see programmers express dislike for LISP in online forums. Because I take it as a sign that this is a worthwhile language to master. I've seen similar expressed distaste for what I know to be good quality C code. It goes something like this: Programmer at large in online forum can't understand [insert code/language], therefore [said code/language] is somehow defective.

The job of fmt could be done with sed, of course. As many of HN'ers know, sed can perform the functions of many other UNIX utils. If used as an "all-purpose" program, perhaps it raises the possibility of the typical mantras about "the right tool for the job". But consider this: editing/transforming text (e.g. output from other programs) as a "job" is somewhat all-encompassing under UNIX. Everything can be a "file" and every file can be represented as "text" (e.g. ASCII, hex). What varies is the context in which you do this job of editing/transforming. It might be preprocessing source code (text) for gcc or maybe it's preprocessing a resume (text) for groff.

"When all you know is a sed, everything is a text." - Unknown