The hard limit is to do with practicalities of low-volume production when you're not sure if enough people will buy them. All ten boards need to be funded (one way or another) for production to go ahead at all.
Another practicality is the EU's draconian electronics-approval laws. The USA exempts prototypes from approval, but the EU doesn't. The board designer is German, so EU laws mean he can't legally sell or even give away these boards himself, unless he first sinks thousands of dollars and more time than he spent on the board itself into regulatory paperwork. That's the reason it's on IndieGoGo at all; He needed a USA resident to both handle the financing and get the board produced all within the USA. IndieGoGo was the least bad financing option he found.
The point was for this one guy (aiju) to see if he could design and build a whole working computer. If I could afford one, I'd get one as much for the purpose of supporting heroic individual effort -- I witnessed some of his struggles -- as for any other reason.
haha! I love this comment. I have to disagree with one point though, I use mouse-focus and I love Acme. I've written my own thoughts elsewhere on this page, but they're less conclusive than yours.
I agree interactive shells suck. I like to use Acme which has been called Plan 9's Emacs, but it uses the shell tools instead of Lisp. In Acme I can enter a shell command -- I can write it directly in the appropriate dir list if I want -- then to execute it either drag over it with the middle button, or select the whole line (by double-clicking after the end; nice and easy) and then middle-click. It's much nicer than groping around blindly in a regular shell window. I've not found it so good when I wanted to use environment variables, but I've just thought on Plan 9 I could edit the files in /env directly. Not sure if that will work correctly though.
>> GCC. ->> 8c, tcc.
> clang, you mean?
I think I'm safe in answering "No" for uriel here. I think he was probably watching clang warily to see how it would develop, but he didn't pay so much attention to software for a couple of years before he died, and it's been a couple of years since then. For my part, Gcc 4.x has done a lot to put me off Linux development or even bug fixing, but I've no experience worth mentioning with Clang. 8c is Plan 9's C compiler for x86, along with 5c (ARM), 2c (68020), kc (SPARC), etc etc. The set was written by Ken Thompson. It's stable, it's got some sensible extensions (which Gcc didn't have until the GccGo project), and it doesn't kick up a fuss for nothing. Tcc is a "tiny C compiler", and as such I assume it also doesn't raise errors over nothing.
I'm pretty sure Rust didn't exist when uriel last touched that page, too.
I have to agree everything sucks in interfaces. Tk was one thing I never agreed with uriel on. I suspect he only put it there to have something proper-GUI-ish in the right-hand column.
>> Vim, Emacs, nano, Eclipse, ->> Acme, Sam, ed.
> So why it happens I never heard of Acme or Sam before? Maybe "ed" in that list could provide some insights?
Because text editor freaks revile the mouse. Sam and Acme both require a mouse. Did you know the mouse was invented for text editing? I have fairly serious motor control issues; in non-medical terms I'm so clumsy they call it a medical condition, but despite that I really can't understand why some people can't just use a mouse to place the text cursor, or even select. I wonder if they're put off by "proper" GUI programs, many of which require really excessive switching between keyboard and mouse. Acme requires the mouse for all editing operations other than inserting text but surprisingly I find it doesn't require nearly as much switching between mouse and keyboard as many "proper" GUI programs. Sam requires even less, it's basically a much-enhanced ed with the option to place the cursor or select text by the mouse if you want. Sam also has this funky feature of running the 'terminal' on a different machine to the back end, so you can have mouse-based editing over slow networks.
>> UTF-8.
> Sure, but unfortunately it's slow as you don't have static offsets, so sometimes you have to use UTF-32 while processing.
You can use any internal format you like without need for byte order marks, which I think is what uriel particularly hated about UTF-32.
On document formats I have to agree with you, copying editing and reflowing text do matter. I think pocket-sized devices just weren't a part of uriel's world. Someone did buy him an iPhone at one point, but that was late in his career.
Sed existed for many years before head, and head only exists for symmetry with tail. There's no other reason for it to exist. It's not that sed is complex, sed isn't nearly complex enough to matter. The more you look into Plan 9 and Bell Labs Unix, the more you'll find the decisions made in Bell Labs 1152 were all very carefully reasoned. They didn't do things out of an artistic need for symmetry or because it felt good, they made the best decisions they could and they wrote no more software than they judged necessary. (Games excepted, of course.)
To answer bbanyc too, grep existed before sed. Grep showed off the power of pipes, but sed came along after pipes were well-established and people thought "Wouldn't it be great to use ed between pipes?"
The argument in harmful.cat-v.org seems to be "don't add pointless junk," but for my part I'd be happy to use a unix with sed but no grep. I plan to look a little deeper than that though. For one thing, although I like the Plan 9 shell and shell tools, when writing scripts I often find myself dipping into awk because it's a more normal programming language and as such it's just easier for so many tasks. I also respect Rob Pike's opinion; when asked what happened to unix's tool-oriented approach, he replied, "That approach is dead and the eulogy was delivered by Perl." I guess like many others I want a language which also happens to function as a decent shell.
aI wrote rc-httpd; it's a CGI-capable web server written in rc shell script. I started the project with the idea that I could probably write a whole web server from scratch, learning the shell tools ant HTTP protocol as I went, in less time and effort than learning how to configure Apache 2.2. I reckon I was just-about right. ;) I wrote it for myself, and I never thought it would need to handle the kind of traffic cat-v.org gets.
werc (the CMS for cat-v.org) is also written in rc shell. It's bigger and does more work than rc-httpd, but rc-httpd always seems to be the point of failure. I suspect it fails where I used awk to parse the HTTP headers; plan 9's awk is very slow.
What's amusingly ironic, considering the content of the site, is werc and rc-httpd perform well on Linux and only Linux. The two together have been used on Linux of course, OpenBSD, Mac OS X, and the 9front fork of Plan 9; Linux is the only one where they perform well. It seems Linux the only operating system optimized for shell script performance, and yes, I laugh every time I say "optimized for shell script performance!"
On 9front werc and rc-httpd perform a role beyond serving pages: they exercise the system, and have exposed some nasty bugs. They were first used when 9front had barely diverged from Bell Labs Plan 9. Back then the system could barely handle the load of a far less trafficked site than cat-v.org. It wasn't just rc-httpd, the whole system would go down when just a few pages were loaded at once! 9front has come far enough that it's serving cat-v.org today, but it still has some way to go. werc and rc-httpd also still have some way to go, today there was talk of making werc cache pages which would help a lot, and I plan to improve rc-httpd a bit too, but I'll only take it so far. I don't really think 9front would be improved by prioritizing shell script performance. :D I might try to write a web server in C, I think I could do it now, or there was mention of maybe porting Varnish, too. I've never looked at Varnish... might do that tonight.
Trailing thought: If I do write a web server, I don't think I'll take it as far as Tom Duff did. Tom Duff's httpd keeps all the web pages in the executable; changing a page means recompiling!
... and having written all that, can I say how much I HATE form cookie timeouts?
You as a user may work for a company which feels it can't afford the risk of GPL-licensed code getting into their products, and may thus forbid you working on GPL-licensed code while you're working for them.
Or somewhat lighter but no less bad is the case where your workload could be eased or better results achieved by incorporating BSD-licensed software into your company's product where your company feels it couldn't allow GPL-licensed software.
These cases show the GPL is better for hobbyists than working people.
Then there's the fact that the GPL doesn't restrict the authors of the software. Some companies release under the GPL to get fixes, features, and kudos from the open source community without making life too easy for their competitors.
Overall the GPL does do some good, but it's certainly not freely giving to the world in the way MIT and BSD licenses do.
the maintainer was busy with work for quite a while, so it might pick up now he's not. i don't care too much myself though, linux has become little more than a web browser platform for me, and i'm sure sta.li would struggle to provide that.
many people in uriel's cat-v community don't either. part of the problem is go's community and its web focus. the other part is cat-v is now focused on a plan 9 fork, and go solves problems which don't come up much on plan 9, or which are already largely solved.
that one paragraph... if i were you i'd be wishing i could edit that comment! you most certainly do not "cut down on file load time." the linking process is a complex task, especially if it's to be performed with any efficiency. i remember when starting a large dynamically linked executable was a glacial process on linux, far slower than the time necessary to read the entire executable from disk. no sensible system loads the entire executable when it's statically linked.
your claim of running two library versions at the same time is downright hilarious! this is far harder with dynamic linking, where you need to be sure of loading the right library on every launch of the affected programs than it is with static, where the libraries are just built in to the executables.
i don't know about leaner, but static linking is faster. symbol resolution is a heck of a task to be run on every program load, especially for larger programs. i remember before linux optimized its dynamic linking, starting a gnome or kde program was a glacial process.
as for static linking being leaner, i have been told an entire shared library needs to be loaded if so much as 1 program needs a part of it, but i doubt it. i don't see why shared libraries can't be demand loaded just like executables are. then again, demand loading a shared library would be a more complex task, and i have reservations about complexity just like the suckless community does.
There's one thing I can't stand in many of these comments: The blithe assumption that just because something is open-source, it -- and any fork of it -- could be maintained. I can't emphasise enough how wrong this is.
Look aorund you in the open-source world. Do you see dozens of forks of every worthwhile project? Hardly! The greatest diversity is probably that between Linux distributions, and for the most part they're only trying to make all the packages play nicely with each other.
Maintaining any software that's even half as complex as webkit, (or half as complex as any modern browser engine needs to be,) requires a ridiculous amount of work. Each fork would need to be supported by many people, each of which would have to be convinced that the ideas of one innovator are worth supporting. Then what happens is the really worthwhile ideas are often very hard to explain, while ideas which can be made to sound wonderful and which attract much help may be of very poor quality.
Another practicality is the EU's draconian electronics-approval laws. The USA exempts prototypes from approval, but the EU doesn't. The board designer is German, so EU laws mean he can't legally sell or even give away these boards himself, unless he first sinks thousands of dollars and more time than he spent on the board itself into regulatory paperwork. That's the reason it's on IndieGoGo at all; He needed a USA resident to both handle the financing and get the board produced all within the USA. IndieGoGo was the least bad financing option he found.