Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
×
User Journal

Journal mapfortu's Journal: 121214 (road rage)

This isn't any official system notice, only me musing about security.

So I'm editing this new wiki page. I don't really care for wikis. What I want is plain text editor, emacs, vi, or even something without all of the functionality, load, save, a rudimentary clipboard and with the option for row column box text selection. The target is to generate primarily plain text HTML pages using hyperlinks to fulfill footnote endnote type reference conventions. Nothing big. We're talking the beginning of the web around '90 or so. Should be easy. Every wiki wants to stuff some extra garbage container syntax around the already fubar'd HTML implementation. Not bad, though, I can handle it if really necessary. What I really need is plain served hosted net space with a web based file manager--my access through public use systems at a public library (part of the job description) doesnt give me all the bells and whistles of ssh capability.

So I settle with a wiki, okay, fine, just find one that works and doesn't start hypersupervising. Since when do sysops bother hypersupervising? Any real sysop has a real life or doesn't have time to monkey around with some user's posts in the message section. The point of running a BBS is not to play deity in the message boards; never was. If the sysop needs to play deity in the message board then they're not running much of a BBS to begin with. Okay, so now I've got a wiki, and it has a few of these bells and whistles. Like avatar. Look, some neat pic which I am allowed to configure. Okay. Upload one. Do you mind if I reference that? Is it okay for me to stick my avatar on a page since I took the time to upload the file? Well, try the docs and the getting started and there just isn't anything about it. How about image? You know, this wiki thing has all of these colon separated classes (emacs was bad enough as a programming shell, lisp, ughhhh *shiver*, and now we take this wiki container syntax garbage and chock it full of what looks like lisp? does ANYBODY think about security anymore?), so maybe there's a class for the avatar. Well, if so, I can't find it. Okay, maybe I'll just try to reference it like any other image on the web. Good luck finding the address for that pic I uploaded. I know what name I gave it... but where is it? After much poking around I manage to hack out an address to a php script on the server that will cough up the image that I uploaded (and is likely sitting right there on the top level of my own user home directory, whatever that happens to be). Okay, well, at least the pic is on the page. How about I wrap some of the title text on the left of it. Great idea.

Okay, too much room along the pic and some of the meat of the page is along the pic. HTML sucks ass. br, br, br, br. Oh wait, that won't work, this is that wiki that is more broken than others. HTML is a whitespace eater (since when is "sed" your preferred pager?). Most other wikis mostly pass the whitespace to the HTML parser and it gets eaten just as you expect. The wiki I settled on doesn't quite do that. Sometimes it eats the whitespace like HTML, sometimes it acts in a sane manner and leaves the CR/LF where you thought it was. So maybe I'll just knock a couple extra enters in. Not above the text, though, because that's the top of the page, and that's the whitespace that this wiki eats, too, just like HTML would have. Okay, well, let's look to see if we can just knock some extra lines after the title text. Nope. The wiki sacts sane about leaving the end of line format CR/LF, but extras are eaten like HTML normally would. It's like a contest to see if I'm more surprised by the idiocy of HTML or more surprised by the idiocy of the implemented wiki container overlay. Okay... well, sometimes the wiki will observe <br> the way I expect. Not this one. This one has provided the _FEATURE_ that the user (should feel priveleged and excited) to use these blocks deliberatly designated by a wiki interpreted bracket encase html tag. Well, that's great, but in the consideration of this avatar picture that I took such pains to even put on the page, that HTML block completely acts bipolar against the image, as in the image block and the HTML block are simply never going to be considered to be on the same row without resorting to a different method of placing the picture there.

Okay, so if the whole thing is going to work so hard to completely fubar any attempt at reasonable page layout design (remember Aldus Pagemaker? 20 years ago that program was much better than any WYSIWYG or syntax editor the industry serves up today), then why are we not editing text files and retrieving them by ftp and piping them to a kernel alert notifier?

Absolute crap... but, it beats standing outside in the rain, and the music is good.

Oh, right, the point.

So after fighting with it I have about eight lines on the page. And I have some editing to do, correct a type-o, and then insert a space between two lines (extra CR/LF). Now, tell me, after I place a cursor and insert a CR/LF, is there some reason why the cursor jumps two lines and four columns away to the character type-o that I fixed?

Again, again, and again... delete the extra line, line the page up (with cursoring keys) like I would, place the cursor on the line to be inserted, hit enter, and wait a fraction of a moment and... WHOA! there's the cursor two lines and four columns away on the character type-o which I fixed. Move the cursor back. delete the inserted line. Cursor around a bit and then place the cursor, insert the CR/LF, wait a half a moment, and BOOM, there's the cursor two lines and four columns away on the character type-o which I had fixed. Again, again, and again.

Does ANYBODY know a darn thing about programming security any longer? That's a cursor fault in a text editor, damnit!

This discussion has been archived. No new comments can be posted.

121214 (road rage)

Comments Filter:

Understanding is always the understanding of a smaller problem in relation to a bigger problem. -- P.D. Ouspensky

Working...