XML isn't a programming language in the same way ASCII isn't a programming language -- in the same way CSV isn't a programming language. Not because of turing completeness, but because they are a completely different thing.
The DTD is just a regular expression, and your document as a string to match. The validator is the interpreter that gives you a yes/no answer for any problem you can represent in those terms.
Actually... hmm. If you look closely at the entity replacement rules, the conditional inclusion entities, and the ability to include external dtd references, you may well be able to get full turing completeness.
From experience (my sister-in-law and a couple of other family members), they have a high return rate. People expect them to behave like a full blown laptop but they don't.
I would be very happy with a 768x1366 10 inch screen. Currently, I use an Acer Aspire One with an 9 inch screen as my main computer. The thing is that, when at my home office, I connect it to a big monitor, a nice mouse and a keyboard.
The only part I dislike is the 600x1024 pixel screen. It's a bit on the small size and lots of programs (and websites) seem to think 768 lines is the minimum.
I use these things at work and I'm getting pretty good at it but frankly the whole non-open source thing kills me and I wouldn't use it on personal projects.
That being said webforms suck man you can use MVC and still have the nice tools.
So, Theo was told around 1999 that the OpenBSD cvs server allowed port forwarding. And then told again, in 2002, by someone else, in a message sent to bugtraq (http://marc.info/?l=bugtraq&m=109413637313484&w=2), about the same problem, and apparently fixed it at that time. And yet in 2009 at least 3 of the OpenBSD cvs servers once again have the same problem.
I assume you're not calling me the idiot? -- Joey Hess
And then told again, in 2002, by someone else, in a message sent to bugtraq, about the same problem, and apparently fixed it at that time.
that bugtraq message says "OpenBSD cvs servers", as in, the anoncvs mirrors that are setup by volunteers, many of whom are not openbsd developers. we don't control any of those servers. an email was sent out to all of the mirror maintainers years ago telling them that they should probably disable the forwarding if they didn't know it was on.
And yet in 2009 at least 3 of the OpenBSD cvs servers once again have the same problem.
the list of mirrors is updated constantly (http://www.openbsd.org/cgi-bin/cvsweb/www/build/mirrors.dat). old mirrors drop off, new ones come on. if new ones are allowing tcp forwarding for anoncvs and they aren't aware of it, email them. clearly it bothers you more than it bothers any of us.
I was just stating that Theo will undoubtably turn up with some hilarity. He will most likely end up whipping the anoncvs mirror administrators into shape.
I do agree with the article.
At the end of the day, it's about as bad as people who used to mess up their sendmail relaying a few years ago. It in no way affects the credibility of OpenBSD, which is how it is worded and discussed.
SQL Server + NHibernate does handle the CRUD stuff, custom fields and DDD-based domain logic very well.
NoSQL (CouchDB in our case) doesn't handle transactions, locking and business rules effectively. However it excels at providing extremely fast views on schemaless data such as our core domain model plus custom fields.
I think he's moaning because he's in the SEO business. Basically, his entire working knowledge is shattered by a viable Google alternative. Now he's got to understand two ways of working (PageRank vs whatever Bing uses). I think that has caused some anti-Bing bias.
Try searching for "visual studio crap" and you'll see how unbiased it is.
Particularly when you go "against the grain" on here. If I dare say anything negative about LISP, Emacs, the environment or business mentality, I get shot down straight away.
Emacs is for people who want to have a versatile do-it-all environment.
Vim is for people who want to process text efficiently.
Typically, software with such a high level of integration sucks. It's a collection of mediocre tools rather than one excellent tool.
My combination of Vim + irssi + mutt + ddd is greater than any emacs tools as they are cherry picked to be the best at their job rather than the most integrated. I know. I binned emacs for them.
Emacs is effectively a somewhat less harsh form of vendor lock in.
Wow, a lot of unsubstantiated "facts" to justify your personal preference. Let me guess, the color green is better than the color orange because your eyes are more sensitive to green? After all, it's your favorite right?
Anyway, I disagree on your comments about integration. Vim, irssi, mutt, and ddd all use separate keybinding semantics. Switch programs, and everything you know about using your software is thrown out the window -- now you are doing something totally new. Repeat several times a day.
Integration affords the possibilities for greater reuse. I wrote an extension for managing "projects". Thanks to eshell, I can easily manage my projects from the command-line now, not just when I am editing files in emacs. (And, there are no hacks involved; no forking a process every time I want my editor to open another file in the project, as would be required if you wanted to do this with vi and bash.)
It's a collection of mediocre tools rather than one excellent tool.
It's all down to opinion, which I chose to share. Now some replies which are all my opinion again.
a) All my keybindings are approximately vim-like. Mutt uses vim as an editor. I use the mouse for ddd (nail me to a cross for my sins). irssi mainly involves: type stuff, whack enter.
b) Blue is my favourite colour (particularly oceandeep.vim).
c) Revelation: I avoid "project management" tools. That is what the filesystem and the related tools are for.
d) Regarding forking, UNIX was designed to be small utilities working together to build systems greater than the sum of it's parts, not one monolithic environment. Otherwise they wouldn't have added the fork() syscall would they? Hence, in vim, whack bang (!) and type a shell command. Pipe stuff in, get stuff out.
The classic "Unix is many small tools and Emacs is one big tool" argument is well known, but rarely substantiated.
Emacs tools are not any more tightly coupled because they're written in Emacs Lisp than your tools are because they're written in C.
In fact, just as all your tools run in a terminal, all my Emacs tools run in buffers (in Emacs). Speaking loosely, Emacs is the embodiment of Unix: it has many tools written by the community, some of which are installed by default, and you can choose which you want to run that best suit your needs. "Integration" doesn't really fit into the picture.
For example, Emacs has both ERC and rcirc. I use ERC, but my point is that there are choices. Emacs has several mail readers (Wanderlust, GNUs, mew, etc) and several terminal emulators. Eshell provides one type of feel, treating your shell as a buffer. Term provides a more classic terminal emulator feel, when you don't want to treat your term like a text editing session.
As to your "! is text in, text out", try M-! in Emacs. I daresay Emacs has fairly robust system integration as well. I have run irssi from term buffers for fun. Even more ironic is running vi in a term buffer. In short, it may be more useful for you to think of Emacs as a replacement for your terminal emulator than as a replacement for vi.
