eekee
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.
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.
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.
For those wanting to see it today: http://web.archive.org/web/20140209235144/http://harmful.cat...
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?
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.
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.
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.
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.