The author of this committed suicide a few years ago. To the people making fun of the site for not being able to handle HN's traffic, it's kinda hard to improve your software when you're dead.
That is terrible news and not something I was aware of when I posted this. However, I would not have posted the OP had I not thought the site wasn't being actively updated.
The link you post says the OP committed suicide in 2012. According to the OP's update page, the site has been updated throughout December of 2013:
Edit: for example, there was a page added recently on Node:
`2013/12/05: Added ‘harmful’ page about Node.js.`
(which unfortunately is down)
Edit 2: I think cat-v is now a series of sites, and each domain may be maintained by a separate person (the one under discussion is harmful.cat-v.org), so it may not all be the work and opinion of Uriel: http://webcache.googleusercontent.com/search?q=cache:JL12jkr...
cat-v.org is operated by stanley lieber and hosted by myself; sl is very very careful to limit modifications to things that were either expressly in uriel's todo list or else so obviously uriel-like that their omission would be glaring.
>I don't know what "hellbanned" means, but I'm unsurprised I got banned for posting about malloc() in a web programming forum.
A hellban is a more insidious kind of ban, where the user is allowed to log on and post as if everything is normal, but in reality most users can't see their posts, and no one can reply directly to them. There's also something called a slowban, where the site purposefully communicates extremely slowly and randomly drops connections, just for a certain user.
>I'm unsurprised I got banned for posting about malloc() in a web programming forum.
Hey, not all of us are web programmers! No idea what was hellban-worthy about your post though.
The page linked is part of a community wiki hosted on the site; while it has accumulated changes since then, I'm pretty sure the original "considered harmful" list was his creation.
EDIT: khm, you've apparently been hellbanned, for some reason.
To piggyback: thanks for the context khm and sorry for giving you server maintenance issues on a Saturday morning...I've come across cat-v entries in random Google searches (today I was looking for UNIX books) and I figured it was a site that had been used to getting Slashdotted.
You definitely weren't banned for posting about malloc. Posts about malloc are good! But yes, the account was banned, and I just looked through the log and I can't figure out why. The IP was banned as well, which suggests to me that your account might have gotten caught by a spam filter that had previously tagged that IP. I'm sorry. We've unbanned the account, obviously.
(If it was a spam filter, I have an idea about how to fix the problem which I haven't yet had time to get to.)
If his primary criteria for "suckage" is non-reliability through unnecessary complexity, he has some decent points.
But such lists are a slippery slope from insightful reflection to axe grinding. It's one thing to debate simplicity and the qualities that emerge in simple software solutions. That is valuable. It is quite another to say that all software sucks and "features" are useless. That's in the eye of the beholder.
Perfectionists tend to be frustrated by the observation that if you want to get paid to build software (as opposed to coding for artistic purposes), the market really doesn't care about internal simplicity, they care about features and qualities. Even more frustrating, the market doesn't value reliability over all other qualities: people have, can, and will pay for something that only works some of the time. Otherwise we wouldn't have had much of an automobile or early PC market.
I am saddened to hear the author is no longer with us, due to suicide. I would have enjoyed him debating his claims on HN.
I've been meaning to ask this about some of the less harmful software listed:
1. What advantages and disadvantages would you say rc has for daily use as an interactive shell over {ksh,bash,zsh}? How does it compare for scripting to those shells and Tcl? I don't know if this is historically true for the latter but both rc and Tcl strike me as regularizations of the Bourne shell syntax and semantics, albeit ones that went different ways (everything including code is a string in Tcl but not in rc, which leads to further differences).
Edit: 3. A downside to PostScript is that it is a Turing-complete programming language. Defining a subset of it that gets rid of flow control would make it too verbose and harder than necessarily to write by hand. By contrast, in SVG it's easy to never use the <script> tag unless you want animation. Is there a (semi-)standard vector graphics markup format simpler than SVG that's purely declarative? I couldn't find one.
>A downside to PostScript is that it is a Turing-complete programming language. Defining a subset of it that gets rid of flow control would make it too verbose and harder than necessarily to write by hand ... Is there a (semi-)standard vector graphics markup format simpler than SVG that's purely declarative? I couldn't find one.
I was under the impression that PDF is a Turing-incomplete subset of PostScript in a pre-processed form. No idea how fun it would be to manually create PDFs, but apparently you can convert PostScript documents to PDFs easily by recording the drawing commands that your document produces as it renders/executes.
The section of the Fount of All Truth (Wikipedia) to you refer to doesn't seem to say that PDF is in fact Turing-complete. In fact it makes it sound like PDF is the result of running a PS document to completion and then taking a "screenshot" of the result. ("Screenshot" as in a snapshot of all the rendered primitives, curves, text, etc.)
I used to use rc on Linux. The details are hazy, but the two main things I remember are:
1. There were lots of little compatibility problems. ssh-agent and gpg-agent can output either Bourne shell or csh. rc can't parse either. I also had trouble with using rc as shell in Vim, something to do with the different quoting rules of rc IIRC.
(This wouldn't be problems when using rc in its native Plan 9 environment of course.)
PostScript is dangerous as a vector of attack. You can create an infinite loop as a DoS. Way back in the NeXT days, you could get remote control a system with an invisible block of postscript put in an email, turning on microphones and cameras and dumping that data to hosts. It became a nightmare to secure. The DOD physically destroyed those inputs on their black hardware to deal with it. Apple moved to DisplayPDF for license cost reasons primarily, but security and performance were also factors.
But the only one of those problems that is due to it being a Turing-complete language is the infinite loops, the other ones are just a question of the mail client exposing sensitive capabilities to untrusted code (which it should not do, of course).
As for infinite loops, SVG allows you to make definitions and refer back to them, so you can write documents which take exponential time (in the document size) to render --- in practice that is as big a DoS attack. And the way to deal with it is the same, you need to impose resource limits when rendering files given to you by an untrusted attacker.
It seems that Postscript the language got an bad reputation for kindof unfair reasons: the toolset was written assuming that files were generated by friendly people, and then those tools were run an arbitrary code from the internet. But it is totally possible to write a Postscript interpreter which runs code in isolation, just as you can for Java or Javascript.
I totally agree that all software sucks, but, unfortunately, we have to use something and the list of alternatives isn't really impressing (maybe because it's outdated, idk).
> C, Go, Limbo.
It reminds me of some story about OpenSSL and… well. Yeah, Python sucks, Ruby sucks, but we have to use something for scripting and everything else sucks more, so… Also, Rust is more appropriate in list of alternatives, I guess.
> Perl, Ruby. ->> rc, awk.
I guess it's only about text processing inside of shell, so, ok, but it's only because our best shells still are awful. I guess shell of the future is something more like iPython, that is, something that allows to do real programming, so there won't be need for cryptic-syntax text processing tools. Yeah, not unix-way. Rc? I doubt.
> GCC. ->> 8c, tcc.
clang, you mean?
> Tk, textual interfaces.
Just no. Textual interfaces are the best, surely, but not always enough. And Tk is simple, sure, but cannot do everything Qt can. So, again, everything sucks.
> 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?
> 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.
> IM
Everything sucks, alternatives aren't any better. Well, may be only a little.
> PDF --> PS(PostScript), DjVu.
What about copying text?
> EPUB --> DjVu.
Really? What about editing? What about reflowable content? What was he thinking wen writing it? FB2 is an "alternative" (but sucks too).
>> 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.
Harmful things Less harmful alternatives
<thing that is > <thing that is >
<not Plan9 / OpenBSD > <Plan9 / OpenBSD >
Most interesting thing which sheds some light on the list is: "At the moment a detailed rationale is not provided for most of this, so figuring out why some things are considered more or less harmful than others is left as an exercise for the reader. Here is a hint: complexity is the bane of all software, simplicity is the most important quality"
I do have to say I agree with a large part of the Harmful list, but I recognize those things are not actually harmful but just personal preference.
Given that many of OpenBSD decisisons turn out to either be the right ones or the de-facto best choices (sudo, openssh, pf, bounds checking string functions, 64 bit time, etc.), it's hard to argue with the general concept.
(This applies to Plan 9, to a much lesser extent - concepts and people who worked on Plan 9 tend to disseminate, but there's less direct code sharing).
I suspect that is selective memory at work to some extent. You are first to arrive sometimes, and the rest of the time you can say "well, we just didn't have the manpower" or something.
Harmful: GPL, LGPL, Apache Software License, MPL, CC.
Less Harmful: ISC, MIT/X, BSD, CC0, public domain.
Yes, giving users even a smidgen of freedom like the GPL does is harmful. Who could say the terrible things that would happen if we don't keep the peasants well whipped and in their place.
People like him have gone on to be so circumpolitical in their defense of letting developer do anything they want that their licences have ended up recreating the huge inefficient Soviet design bureaus of the 1960's. Places where you had 5,000 people doing the work of 50.
You needn't look further than the closed source juggernauts like google, apple and microsoft to see how inefficient and wasteful they are with the human capital at their disposal. Open source projects still manage to beat them much of the time with 1/1000th the personnel and virtually no funding.
>Yes, giving users even a smidgen of freedom like the GPL does is harmful
The point is that it does not give them enough freedom. Notice how "public domain" is in the less harmful category? And all the licenses in that category as more free than the GPL?
> Notice how "public domain" is in the less harmful category? And all the licenses in that category as more free than the GPL?
That's a very odd definition of "free". Can you explain to me how my computing freedom is enhanced by using a binary that's licensed under the Free BSD licence without the source being released? Compared to a GPL binary where I must be supplied the code as an end user and can vet it to make sure the vendor has not put tracking software/other malicious code inside?
I can see why people like the GPL, but it definitely and intentionally restricts some freedoms (such as the ability to link to non-GPL code, or make proprietary changes) so it can guard others. It's a trade-off not everyone's happy with.
Here's how I look at it: say a company takes some BSD-licensed code, extensively patches it, then releases it under a proprietary license. I haven't lost any rights from this—I can still use the original code without their changes. The difference is the company isn't legally forced to grant me the same rights to their modifications. They're also able to incorporate outside code that can't be legally re-licensed under the GPL—the GPL instead forces them to find or write an alternative.
It's in that sense that the GPL is less free. Its supporters argue that's a good thing; its detractors argue it's a bad thing.
Which has nothing to do with what I asked about my freedoms as a user.
Developers think that licences that let them charge for binaries, restrict resales and keep competitors out are wonderful. The same way that banks think that debtor prisons were a wonderful idea and billionaires want a flat fixed dollar tax rate is the solution to every problem. There isn't much surprise there.
But for the majority of the people, who do not work in the one company releasing the binary, the GPL is infinitely freer than any of the anti-user licences he's listed as "less harmful".
So let me ask again: From the point of view of a user how is the MIT or BSD licence freer than the GPL?
As a pure user (someone who isn't going to modify and redistribute the software), I see no difference in freedom between BSD and GPL licensed software—I am just as able to download, install and run FreeBSD as Ubuntu. I can even burn a stack of DVDs of either to hand out to my friends.
The fact someone else can fork FreeBSD and start selling OppressionCorpBSD doesn't change this at all. Sure, I can't hand out free copies of OppressionCorpBSD, but that doesn't hinder my use of FreeBSD any more than the existence of Windows does. (And I do love my freedom to not use Windows!)
Neither license prevents the existence of proprietary software, but the existence of proprietary software doesn't force me to use it.
It's the modify-and-redistribute case that's interesting, which is why I focus on that. (Why would you care about having the source code at all if you don't plan to change it?) The nice thing about open source is it lets you blur the lines between user and developer—it lets you change existing software, then give that new version to anyone who wants it.
Even as a mostly user sharing minor tweaks, the GPL limits my options—I can only incorporate code I can legally distribute under the GPL. That doesn't hurt me when my patch is entirely my own original code, but it does hurt me if I want to re-use code from a (4-clause) BSD-licensed project, or from any other GPL-incompatible license.
The GPL envisions a world where all software is GPL'd. Simpler licenses co-exist in a world where a lot of software isn't GPL'd.
> The fact someone else can fork FreeBSD and start selling OppressionCorpBSD doesn't change this at all. Sure, I can't hand out free copies of OppressionCorpBSD, but that doesn't hinder my use of FreeBSD any more than the existence of Windows does.
The point of the GPL is that your use of FreeBSD wouldn't be hindered today, but might be hindered in the future.
Whether you accept the possibility of that scenario as valid or not is up to you, of course, but it's not simply a theoretical threat (after all, RMS witnessed it happen before his very eyes in the days of Lisp machines).
In the defense of the original poster, he does provide a reason to want the source code without changing it: "[I] can vet it to make sure the vendor has not put tracking software/other malicious code inside".
(Of course, if the vendor did that I'm sure they'd just hand me code that didn't match the malicious binary.)
True, but you can inspect BSD-licensed source just as freely as GPL'd code too.
Not that that's much use against a malicious distributor, who could disguise malicious code so that it passes inspection: http://underhanded.xcott.com.
(Oh, $DEITY I don't want to get involved in another BSD vs. GPL thread, but I just can't help myself...)
You can't inspect the source of something BSD-derived that's distributed as a binary (which I suspect is the point of the parent poster).
Interestingly the GPL sort-of stipulates that the recipient of the software should be able to build the software from source. This would allow a sufficiently paranoid recipient to inspect all the source and compile said source.
(Ken Thompson's caveat notwithstanding.)
Paranoid me is stuck between a rock and a hard place—I don't want to have to trust a ton of third parties with my security, but I'm unlikely to be able to ensure it on my own and still benefit from modern technology.
That's not just because I depend on proprietary software—frankly, there's no way I could audit every line of code that runs on a Linux system that solves the problems I want it to solve, and even if I could, it's almost guaranteed I'll still miss something critical in the process.
But that's another topic. If I think it'll buy me something, I'm free to audit the source to both GPL and BSD-licensed software. I can't audit the source to proprietary derivatives of BSD-licensed software, but if I choose not to run it that doesn't hurt me any more than it hurts me that Windows continues to exist despite my refusal to use it.
In other words, I'm still free to make choices that preserve my freedom, no matter what another group chooses to do with their derivative works of software I run.
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.
Why do you discriminate against developers? Many of the GPLs' restrictions have everything to do with propagating freedoms that enable users to be developers. In fact for mere users who have no intention of developing or hiring someone to do it, many of the freedoms granted are just plain useless.
Coincidentally, many of the people who prefer permissive licenses are users and developers (and because they share their work, distributors!) at the same time. That is why they go with licenses that respect freedoms relevant to all these roles equally, without discriminating.
Even if you are not developing software, the GPL (v2 in particular) has a nice trap in it should you decide to use your, ehm... freedom to share the software with a friend who needs it. In case you forget to comply with all its petty obligations..
Disingenuously, from the point of view of an average user it's all the same, since the average person doesn't audit source code.
If you're in possession of some GPL-licensed source code, then it clearly restricts your freedom to do things with it, compared to BSD/MIT-licensed code.
If you're arguing otherwise, I think you're being purposefully obtuse.
>Which has nothing to do with what I asked about my freedoms as a user.
Yes it does. The hypocrisy inherent in this line of reasoning is that the GPL exists specifically because the distinction between "user" and "developer" is a false one. The GPL seeks to protect so called "developer freedoms" for all users. But then misguided GPL advocates turn around and present the false dichotomy of user vs developer in an effort to spread FUD about BSD/MIT/ISC/etc licenses.
>But for the majority of the people, who do not work in the one company releasing the binary, the GPL is infinitely freer
No it is not. Sqlite (public domain) is totally free. I can do literally anything with it. That is maximum freedom. Postgresql (BSD) is less free, I have to follow certain restrictions in order to do certain things with it. Mysql (GPL) is even less free. I have to follow more restrictions. This is trivially simple and obvious, which is why lying about it tends to earn downvotes.
Care to elaborate? Because from reading what you just wrote, I have absolutely no idea what you mean by group freedom here. But one thing I know is that a restriction is still a restriction whether it's one, five, or fifty people who want to do a thing with the code. That is probably not what you meant by group.
From the point of view of someone more sympathetic to the GPL, I'll say that for some it's about sustainability of freedoms. If a proprietary fork draws away the user base (and maybe hires away key developers), I don't lose access to existing code, but updated code becomes substantially less likely and un-updated code (often) becomes gradually less useful. This situation is by no means impossible for GPL software but it's less likely (it can't be an actual fork, so there's more work to be done at the outset).
In the short term, it's reasonable to say that BSD is "more free" in that it permits things that GPL does not. In the long term, the usable versions of that code may not be free at all.
The one arguable caveat regarding BSD's short-term win (which would make it a short-term tie not a short-term win for the GPL) is that the only restrictions the GPL applies are against infringing on the rights of others. In which case, we're not talking about "freedoms" but "powers" being impinged - I'm not "less free" because I don't have the right to kill people, we're all (individually!) more free for not having to worry as much about arbitrary threats to our lives. To the degree this is the case, there's an argument there; the degree to which this is the case is not 100%, though - there are corner cases - but it is pretty typically the case. Whether you buy the argument is of course up to you.
"The difference is the company isn't legally forced to grant me the same rights to their modifications. "
Yes, so GPL fans go by "today me, tomorrow you" and this BSD-fans go by "freeeeedooom" but then dont really put their code in public domain - instead maintain their copyright over it - which grants them the rights to revoke or change their license at any time.
BSD-license can be revoked by the copyright holder you know.
So if all these BSD fans really are "freeedooom", please public domain everything.
Can it be? Specifically, can someone release software under the BSD license, then later legally prevent others from using that version under that license?
Also:
"Few if any legal systems have a process for reliably donating works to the public domain. They may even prohibit any attempt by copyright owners to surrender rights automatically conferred by law, particularly moral rights. An alternative is for copyright holders to issue a licence which irrevocably grants as many rights as possible to the general public, e.g., the CC0 licence from Creative Commons." (Source: http://en.wikipedia.org/wiki/Public_domain#Dedicating_works_...)
There's some sort of legal doctrine to the effect that you can't be punished for taking an action that someone led you to believe was authorized. This would protect you in cases where you use the licensed software when the license was still in effect.
I suppose the better question is whether someone can rescind their license for their work and prevent future legal use of that software. I'd like to think that's not possible either, but I have no clue to be honest.
As per the Berne convention, some rights are inalienable. In practice this means that there are many countries where you simply cannot put your work in the public domain, or otherwise try to disclaim these rights.
The rights which matter can be, see for example many musicians and artists fight against the copyright holders of their music despite them being the originator or creator.
>BSD-license can be revoked by the copyright holder you know.
No it can not. Someone can stop releasing their previously BSD licensed code under the BSD license, but all the existing copies people got under the BSD license are still governed by it. This is exactly the same as with the GPL, or any other license.
The copyright holder grants you a license, and that license can be revoked, wether it be GPL, BSD or Apache or whatever, and it applies to _all_ the softwares the copyright holder has rights to - ie all previous versions.
That is the reason why FSF and GNU encourage copy-right-assignment to the Free Software Foundation - as a kind of guard against any one hacker messing with a project.
BTW this copy-right-reassignment to FSF is similar to how Record Label companies reassign the copyright from their slaves, erm sorry, musicians/artists onto themselves and then govern them.
You can stop granting new licenses, IANAL but ability to revoke licenses you've granted (without allowance for this in the terms of the initial granting) would hugely surprise me. Of course, with the GPL that is still potentially messy.
Well go check it out, the license that you grant can be revoked.
The only reason this doesnt happen more is that most freedom software has many authors and a change in license would require consent from them all. But a really nasty person could still decide to rip his copyrighted pieces out of any previous version thus crippling the whole project.
But nobody is an asshole like that, but legally the possibility exists.
Yes they are, any licenses are revokable. The GPL as well.
I could release software under GPL, not accept any patches, see the software grow and 2-3 years from now when a lot of people are using and depending on the software, bam I revoke the GPL from all previous versions and impose a special EULA in its stead. I can because I am copyright holder.
My silent downvote means "discussions about which licence is more free are really tedious. I've probably heard all the arguments people are going to make and I really don't need to hear them again in this thread. One group prefers this licence; another group prefers that licence. They are not going to agree and no-one is going to change their mind so why the fuck can't people just accept that sometimes people make a different choice and move on".
>Can you explain to me how my computing freedom is enhanced by using a binary that's licensed under the Free BSD licence without the source being released?
That isn't a thing. I find it hard to believe you are genuinely as confused as you appear to be. I suspect the "silent downvotes" reflect the likelihood that you are being deliberately dishonest to spread FUD, as your particular example of FUD is older than a lot of the people posting here, so it is hard to believe anyone genuinely doesn't know better at this point.
A proprietary program that is a derivative of a BSD licensed program is not a BSD licensed program. It has literally nothing to do with what the BSD license offers you. The GPL is less free than the BSD license because it imposes more restrictions on you. This is incredibly simple and obvious. Many people believe those restrictions are important and good, and you may well believe that yourself. But that doesn't make those restrictions an increase in freedom. Just as some countries prohibit speech they deem objectionable, they may well believe that is better than free speech, but it doesn't make them freer than countries with free speech. Free speech includes the right to say things I don't like, just as free software includes the right to create software licensed under licenses I don't like.
The title drew me in, but I didn't find this very insightful. I clicked on it expecting a righteous rant; instead, I found a list of things the author likes and dislikes, framed by some clever quotes.
Yeah, disappointing. It's just a "list of things I hate and you'll just have to trust me I have good reason to". It's a bit childish, actually.
Some of the things have links to rants explaining why they apparently suck, but that's just more adolescent ranting mixed with quotes.
I like a good rant occasionally, but those are well-written, make a point worth making and actually show some effort to convince the reader. This is just not it.
A lot of his rationale doesn't follow the simplicity argument he makes.
I'm not a Rubyist, but replacing Ruby with awk sounds like a terrible idea: suddenly means you're treating things which are not strings as strings, which can get very complex very quickly. Also: few people know awk beyond print $1, and using two languages (bash and awk) is more complex than one.
>and using two languages (bash and awk) is more complex than one.
If the two languages are combined still simpler than the one language, then it is not more complex. Note that bash is not what you would be using if following his lists. Using rc+awk is way simpler and easier than ruby for any typical unixy scripting stuff (text mangling, process wrangling, etc).
Really? I think any language with string methods, regexs, arrays, sets, and hashmaps (which IIRC Ruby has) is a much cleaner approach than sed + awk + (bash|rc). Data is serialized as strings in config files, but for simplicity's sake, should be manipulated as actual data.
This is coming from someone who built an OpenDocument generator in bash that's still in use at IBM today.
Also: who names something new on Unix 'rc'? Simplicity is not using existing names.
You might want to learn awk and rc before making claims about them. In particular, awk is significantly more powerful than you seem to realize, it is not analogous to sed at all. It is a specialized programming language for manipulating tabular text data.
And nobody names something new on unix rc. It is the plan 9 shell.
I've used awk extensively and am aware of everything you've told me. I never said awk was analogous to sed, they're quite different, which is why you'd use both, as I mentioned.
I've not used the rc shell, but have used Bourne shell, bash, csh, various versions of ksh, and zsh. My comments apply to all of those, and unless rc is significantly different to every other Unix-like shell I imagine they apply to rc as well.
Also: plan 9 is Unix-like, rc shell is newer than the Unix concept of rc that dates back to 1965 http://en.wikipedia.org/wiki/Run_Commands. So yes, it's a new(ish) thing with a naming conflict with something already well-known.
>I've used awk extensively and am aware of everything you've told me. I never said awk was analogous to sed, they're quite different, which is why you'd use both, as I mentioned.
I can't see any way to parse your statement such that it matches your claim of being experienced. Either you feel sed is on the same level as awk and rc, hence mentioning it together with them (unlike say, ls or grep or any of the other commands you didn't mention) as being one of the tools you would use instead of general scripting languge X. Or you meant using them together for one specific task rather than as a general "sometimes you would use one, sometimes you would use the other". In which case you don't realize that there is no reason to ever do that since awk can already do everything sed can.
>I've not used the rc shell
That's precisely what I pointed out was a problem. "I have no knowledge of one of the things I am comparing" is not a rebuttal to "you have no knowledge of one of the things you are comparing".
>My comments apply to all of those
And all of those are listed in the same category. This makes it rather self-evident that yes, he considers rc to be significantly different. Hence my suggestion that you try it and find out how you feel about it, rather than just assuming it is the same as bash.
>Also: plan 9 is Unix-like
No it is not. Linux is "unix-like". Plan 9 is a completely different OS, designed as a spiritual successor to unix, which was seen as having been corrupted. It is no more unix-like than windows is dos-like.
>So yes, it's a new(ish) thing with a naming conflict with something already well-known.
I never said otherwise. You asked "who names something new on Unix 'rc'?". I pointed out the obvious fact that it simply isn't the case. It is not something new on unix. Being upset that an operating system has a two letter command that another operating system also has is silly.
Twice now you haven't read the post you're responding to. I don't think sed is the same thing as awk, nor do I think it is the same as bash, I have never said that, in fact I have said quite the opposite: that you'd likely use all of those together. This is incredibly common behaviour in Unix scripts: you might not like stream editing but many find it cleaner than awk's less well known language.
You seem to have gone out of your way to attribute some kind of conspiratorial malice or gross incompetence to a simple, TESTABLE fact: shell scripts plus text manipulation languages are frequently replaced by single language scripts, which have a unified, consistent syntax and high level data structures.
Since you're not reading my posts, I'm not going beyond your first sentence. This is end of my participation in the thread.
I have in fact read them. I have even been very explicit and clear about my reading of them in the hopes that you will either understand what I am saying, or correct my misunderstanding. It is unfortunate that you wish to do neither. I made a very simple point: you do not know rc, and are comparing bash to ruby and then blindly assuming that comparison applies to rc vs ruby. It does not.
Yes, cat-v. I've wasted plenty of time on there, as well as other werc sites.
As a previous poster pointed out, these guys are hardcore Unix elitists and so their perspectives on software are written from a standpoint of an ardent follower of the Unix philosophy, and one who values minimalism and simplicity over all. The real form of simplicity, not the one of dumbing things down.
It's just a totally different world from your average HN user, or even Bay Area "techie", for that matter.
Their IRC channel is also pretty amusing to lurk around, though of not much use unless you're involved with 9front to one degree or another.
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?
cat-v.org runs werc[1], a minimalist web not-framework written by Uriel in the rc shell[2], served by rc-httpd[3], a web daemon also written in the rc shell, by eekee.
The site is served by a single plan 9 virtual machine hosted by myself and maintained by stanley lieber. Further website optimization is not particularly high on our to-do list. Anyone who wants to donate CDN services or front-end varnish machines is welcome to get in touch.
I can't image how you'd write a web server that couldn't cope with that low load (actually I can but not for a mostly static site like this).
Even if we consider that it would be an additional page view every 5 seconds, this is barely believable that this would put the server under a stress load.
Either this one is wildly more popular or maybe something else is going on as well.
Cat-v is under "page view every five seconds" load basically continually. You don't have to imagine how to write the web server, because the source is available for your perusal, in friendly, easy-to-read shell scripting.
The site has trouble because we have devoted our meager resources to other tasks. If someone wants to donate beefier servers I'd gladly replace the aging, asthmatic machines that comprise 9cloud.
It's been my experience, however, that people generally don't want to spend that thousand dollars.
Remember, every page view also loads images, CSS, JavaScript, etc. So a single view can add up to a dozen hits. Depending on how powerful the machine is, how aggressively cached the content, and what else it is being used for, that can consume significant resources.
Yeah, I agree with your examples aside from the ability to validate XML; I'm not a heavy user of json but I don't believe it's possible to tell whether a document is well formed. Anyway, the lack of rational means it doesn't address essential vs accidental complexity. Are the harmful items harmful because they have lots of accidental complexity? Or are the problems they exist as a solution for simply hard problems? If complexity of a harmful entry is mostly essential it would be interesting to know why it was still considered harmful. For instance, Bash is considered harmful but is nice as a user shell compared with say, sh.
Yeah with XML, there was a period there probably late 1990s to early 2000's when it was supposedly the silver bullet that was going to glue disparate software and systems together. When used well its fine, but it was probably over used, especially in things like configuration files where a simple key + value pair text file would have sufficed.
I love that flat files are considered less complex, but SQL DBs are bad.... I would love to know under which criteria that is true for the author. Is it "music I listened to last week"?
Because it wasn't made in Murray Hill. grep is also a single command in sed, but since it was in Unix v6 it's okay. There's an extreme case of NIH syndrome that pervades the Plan 9 community.
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.
The OP was so opinionated about solid software principles that I kind of did not expect his server to go down...Mostly, I thought his table of "Good" and "Bad" (example, Python, Ruby, C++ is bad; Go is good) was amusing, and his dedicated rants to the software I agreed with, in part.
In 2002, the DjVu file format was chosen by the Internet Archive as a format in which its Million Book Project provides scanned public domain books online (along with TIFF and PDF).[8]
Fair enough but the main usage of my ePub files is reading them on an e-ink device. DjVu isn't an alternative to ePub then.
I think quite a few people are missing the use of the term "harmful".
His words are from a developer standpoint with unix philosophy.
One tool does one thing well, those tools are licensed in a way that means you can contribute safely without being a lawyer and the code is not needlessly complex.
The Suckless crew have software that suits such philosophies perfectly, check out dwm and ii.
upvoted based on the sentiment of the title (because what to do with things that suck? make them better.) and domain name alone. there are similar listings at http://suckless.org/sucks and http://suckless.org/rocks . i found a pdf viewer called zathura as a result of that site, and it's been really useful (despite pdf sucking as a whole vis. djvu).
Software complexity either comes from people not doing the hard work, or contemplation, to pan down their ideas to the simplest possible construct... or later allowing cancerous developments. It has little to do with tools used for implementation. Pretty much everything on the left side of that table can be used to produce beautiful, simple, elegant software.
There are people who find that complexity and bloat matter across the entire stack, from the lowest level to your piece of software on top of it all. With such philosophy, it does not matter that your product might be simple and elegant, if it stands on the shoulders of a wild behemoth.
Then those people better not be programming on x86 hardware because that platform is so bloated the mov command is Turing complete by itself: http://www.cl.cam.ac.uk/~sd601/papers/mov.pdf
You are right. We actually have all the resources needed to overcome this problem and we've fabbed our own chips in our garages. Some of us play with sparcs, vaxen, arms, weird mips based toys and other such things to stay inspired and maintain sanity.
Now you just need to design a balanced ternary computer which uses lambda calculus instead of Boolean logic and you will be a quarter of the way to getting rid of the gunk left over from the birth of computers when people were arguing if relays or vacuum tubes were the way of the future.
The one thing I have noticed all the people with "philosophical" objections to bloat have in common is that they are largely ignorant of the real hardware and software they are coding on. This was brought nowhere better to the front than in this video https://www.youtube.com/watch?v=Nbv9L-WIu0s where they showed that the tools written because gnu tools were too big when measured in a running computer take up just as many resources.
There appears to be some discrepancy in the interpretation and use of some terminology.
To clarify, what many of us refer to as bloat has nothing at all to do with run time resource usage, but instead relates to unnecessary features and complexity. We see freedom and beauty in short, clean, simple code, small utilities and terse specifications. These are seldom the most efficient (computationally) solution to any particular problem, but these tools are small (in terms of code, possibly binary), and therefore easy to implement and maintain as well as understand. And we can easily replace such tools if necessary; we don't become excessively dependent on giant code bases. When computational resources permit it, we prefer to get rid of optimizations to simplify these tools internally.
A bloated tool might have a million features, it can be many times as efficient at some things, it can probably do more. But it is likely to be hard to modify, a pain to maintain, difficult to port, and diagnosing problems gets harder with more complicated tools. As soon as you start using half of its features, you become very dependent on that particular tool. And you probably cannot replace it, it would be too much work. Your freedom suffers.
More often than not, we can get our jobs done with simple and small tools. Thus the big and complicated tool is filled with unnecessary things; it is bloated.
>This was brought nowhere better to the front than in this video https://www.youtube.com/watch?v=Nbv9L-WIu0s where they showed that the tools written because gnu tools were too big when measured in a running computer take up just as many resources.
At what time in the video does that happen? I didn't have time to watch the whole thing, but it doesn't appear that what you are suggesting was even brought up much less demonstrated?
They're just measuring code size and such. Kilobytes that do not really matter, unless you're embedded.
Right near the end they present some minimal tools that are supposed to have no bloat because they're written in assembly and don't need libc. Turns out these aren't any better than gnu tools with dietlibc, after some shaving.
Not really worth watching through, if you were expecting discussion about real bloat. I think they're just setting up a straw man, a bad one at that too.
Since I have been using rc as my interactive shell since approximately 2001 and since I tend to have a PERFECTIONISTIC attitude towards the software that I use every day like the OP has, I will give a list of what I like and dislike about rc (relative to bash) in order of decreasing importance or significance. (Specifically, since about 2001, I have been using the port of rc by Byron Rakitzis on Linux and OS X.)
If you like Unix shells, then you probably want to skip this comment since it is my opinion that all unix shells including rc suck for interactive use.
The original meaning of the word "shell" was a interface layer between the core Unix system and the user. I now consider Emacs my shell, and I try to replace interactive use of rc, bash or other traditional Unix shells with interactive use of Emacs whenever practical.
E.g., to escape from the hassle described below caused by equal signs in Youtube URLs, I defined an Emacs Lisp function M-x youtube-dl so that I no longer need to use a Unix shell to interact with the command-line program youtube-dl. (This works for me because 99.9 percent of my interactions with rc are through Emacs. Consequently, I do not need to switch from Terminal.app to Emacs.app to type M-x youtube-dl because Emacs.app already has the focus even when I am interacting with rc, and Terminal.app is not even running most of the time on my system.)
I tend to define new commands and wrap/redefine existing commands like ls a lot, which of course means writing some code. Consequently, the list below includes problems I encountered (in bash and in rc) in writing and maintaining code that defines new interactive commands and defines wrappers around existing interactive commands. (My .rcrc file -- which is rc's analog to .bash_profile and .bashrc -- is currently 704 lines long and contains 112 definitions of rc functions, but about half of those 112 are "of historical interest only". I.e., maybe I should have deleted most of them by now.)
Here starts the list.
Backslash does not quote the next character in rc like it does in bash.
Consequently, to refer to a file name with space in it, you have to do it 'like this' rather than like\ this.
Unfortunately, all the softwares I am aware of that do tab completion of file names quote spaces and pound signs like\ this, which makes it tedious in rc commandlines to type file names with spaces and pound signs in them. This has been for me the biggest disadvantage of rc relative to other shells. It has been especially painful OS X where spaces in file names are not rare, but even on linux it was painful for me to specify file names like #long_name_here# which Emacs was in the habit of leaving around until I figured out how to get it to stop doing that.
Parenthetically, I ran into the same basic problem with all the Plan-9 and Plan-9-inspired software I tried to embrace (e.g., Wily, Acme via plan9port): namely, although the design decisions work okay for people who use only Plan 9, the mismatch between the Plan 9 way of doing things and the OS X or Linux way of doing things makes it unworthwhile to use a Plan-9-inspired tool or a tool ported from Plan 9 on OS X or Linux. E.g., on Plan 9, file-name completion via the tab key is simply unavailable, which works on Plan 9 because everyone including the providers of the basic system keeps path names nice and short.
In bash et al, you can have an equal sign in a file name or a URL without needing to quote it. In contrast, in rc, you need to quote it. this is a hassle for me since youtube URLs have equal signs in them, and I am in the habit of pasting them into shell commandlines a lot.
The thing I like most about rc relative to bash is that a function definition begins with the characters "fn foo" where "foo" is the name of the function. This makes it easier to use plain old "find in page" functionality to navigate to a function definition in a file full of function definitions. In other words, in bash et al, you have to type "foo()" to search for the start of the definition of the function foo whereas in rc you can type "fn foo " which is easier to type.
Moreover, in the process of writing this, I used grep to determine the number of function definition in my .rcrc file (rc's analog to bash's .bashrc file). specifically, I used "grep '^fn ' .rcrc". the analogous operation for bash is harder to express.
Since this thing I like most about rc is a relatively small thing, you would be correct in concluding that I do not believe it is worth it to switch from a normal shell like bash to rc.
Another thing I like about rc: unlike bash, newlines are not somehow in subtle ways significant in "multi-line constructs" like if statements. in other words, if statements, switch statements and for statements in rc resemble statements in normal languages like C more than if statements, etc, in bash do.
The quoting rules are simpler in rc than in bash. Although I found that very appealing in theory before I started using rc, in practice, I still struggled with "quoting-related issues" in rc. for example, the definition of the rc function I used as a wrapper around /bin/ls contained the following code whose purpose is to "print" (cat to stdout) its contents whenever there exists a file named .hdr in the directory being listed.
the code loses whenever the full path to the directory I want to list contains a space. in particular if I cd somehow to /0/library/saved application state, then invoke my wrapper command, the error message
test: application/.hdr: unknown operand
test: application/_darcs: unknown operand
test: application/.alpha: unknown operand
appear in the output, and the .hdr file is not printed. For those readers who know how to fix that bug in the code below, please do not feel you need to educate me about the fix. To write code in rc you have to know some "shell lore", and although some people might take pride in learning shell lore, I'd rather avoid the need to learn it. In most languages (e.g., Python, Ruby, Lisp), there is no special lore one has to learn to ensure that path names with spaces in them are handled correctly.
# set dirname2 to the directory portion of the last argument.
# make that directory name an absolute file name.
# make sure it ends in a slash.
if (!test -d $*($#*)) {
dirname2 = `{cd `{dirname $*($#*)}; pwd}^/
} else {
dirname = `{cd $*($#*); pwd}
switch($dirname) {
case */
dirname2 = $dirname
case *
dirname2 = $dirname^/
}
}
# if a .hdr file exists, print it now:
if(~ $#* 1) {
if(test -d $1) {
if(test -r $dirname2^.hdr) {
cat $dirname2^.hdr
echo
}
}
}
in summary, for me switching to rc was probably a waste of my time, and I would have been better off sticking with bash (and better off starting sooner on my slow mission to replace interactive uses of traditional Unix shells with interactive uses of Emacs).
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.
Could someone explain the advantages of sam and/or acme over emacs or vim to me? reading that it's from the plan 9 team I get the feeling there must be something good there so I was wondering if someone could help me realise what it is? extra points for a comparison of sam and acme or explanation about ed. ;)
Meanwhile, traditional UNIX users all developed subconscious phobias of their mice, because they use focus-follows-mouse and therefore moving their mouse caused them to accidentally type in the wrong window. This is why they like to so rabidly claim to be super-efficient typing wizards by using keyboard chords for all their text selection needs.
Acme is also more UNIX-like (Plan9-like?) than EMACS, which is just an alien Lisp image invading your machine and seeking to become an email reader/rampant AI/planet conqueror. I always assumed Hurd failed as a project because, once it ran Emacs, nobody ever really needed to develop the rest of the OS.
hahaha. I love this answer! So rob pike wanted a vim that used the mouse? did he follow the vim paradigm of having composable/repeatable/whatever you want to call vim commands (you know what I mean) or the emacs version of "oh, just throw a programming language in there and they'll be fine"? also is it modal like vim?
Finally, don't speak ill of the emacs, I've got it on my machine and I worry it's listening, I swear after I wrote that last lisp function I heard it whisper, I grow more afraid every day. it can hear us. we are not alone, I type three escapes and it merely laughs at my naivety these days.
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.
He does at least put down Tutorial D as an alternative to SQL, which is Chris Date's relational language.
The issue is not the relational model, which is pretty simple and powerful. The issue is that SQL reflects a more complicated multi-set multi-valued logical model.
Why not indeed. Many times all that is required is a few files written to /tmp atomically mv'd in place. Also, see git's design[0] and how it makes operations like fetch/push completely trivial. Also, how redis reliably dumps and appends.
http://www.cs.bell-labs.com/wiki/plan9/Uriel/index.html
https://groups.google.com/forum/#!topic/comp.os.plan9/xEb4wY...