Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?
Take advantage of Black Friday with 15% off sitewide with coupon code "BLACKFRIDAY" on Slashdot Deals (some exclusions apply)". ×

Comment Re:just plain old xterm, with this (Score 1) 352

I agree with plain xterm. Others tend to annoy me.

It's true there are a number of oddities about xterm that might put off people who've never used it before. By default no scrollbar, and once you enable it, it is kind of odd in that you don't use "modern" conventions to interact with it. Its menus and other features are hidden by keystroke combinations that are probably hard to discover if you don't already know about them. I don't like some aspects of the default configuration. I've heard the code is a mess internally, although I haven't checked. Etc.

But I still think xterm is the best. Some emulators flicker when scrolling; not xterm. It just seems faster, and I'm spoiled: even a small fraction of a second response time seems excessive to me. Uses very little RAM. Very configurable if you actually take the time to search through the man page. No superfluous decorations around the terminal (even a scrollbar) unless you want them. Doesn't depend on any huge modern GUI toolkits; if you can run X at all, then you can run xterm. It's available everywhere; get used to it once, and you aren't constantly getting used to other terminal idiosyncracies. Etc.

My personal configuration:

xterm*saveLines: 3000
xterm*scrollBar: true
xterm*boldFont: 6x10
xterm*foreground: white
xterm*background: black
xterm*font: 6x10
! Very useful to quit out of vi or less, and still refer to
! what you were seeing while typing next command:
xterm*titeInhibit: true
xterm*pointerMode: 0
! works better with the black background I like above:
*VT100*color4: blue
*VT100*color12: lightblue
*VT100*colorUL: yellow
*VT100*colorBD: white

Comment TI-99/4A Basic ... Linux (Score 1) 413

Older people probably have long enough chains that the poll would need literally millions of options to include the right one. For example: TI-99/4A Basic - No persistent storage Apple IIe DOS MS-DOS 3.2 on an 80386 UNIX system V/386 v 2.1 on the same 80386 Linux (various distributions and versions: first Slackware 3.0 on pentium pro; currently gentoo on a core i7)

Comment power of 3 rule (Score 1) 253

From http://ask.slashdot.org/comments.pl?sid=169033&cid=14088668 :

> 1 UOW = program for yourself
> 3 UOW = give it to someone else
> (you install, you copy, etc)
> 9 UOW = give it to local group
> (howto, platform change)
> 27 UOW = shareware/open source
> (configure/make/make install)
> 81 UOW = product
> (real docs, slick UI, support teams)
> 243 UOW = business
> (lawyers, CEO, sales, marketing)

Comment SRP protocol (Score 1) 288

If you can pick or control the overall authentication protocol, it would be even better to only store the s and v parameters from the Secure Remote Password (SRP) protocol. Pick a good underlying hash function H(), such as in the parent post. SRP uses some fancy zero-knowledge proof / public key algorithms (fairly interesting if you study it) to significantly reduce attack cross-sections for a much wider range of attack scenarios than just a hashed password, even when the password is weak.

Unfortunately, the most common situation is a web browser using http or https, and I don't know any way to use SRP properly in that context. Perhaps implement a secure tunnel on top of http in javascript and send all data through that - but that is totally tedious and impractical, probably can't work with images, and doesn't prevent MITM (man-in-the-middle) attacker from replacing the javascript in a way nearly impossible for either end to detect.

Someone ought to define a way to delegate a web apps' password validation to the SSL layer of the https connection, which would then use SRP to do the validation. Find ways to make it hard for attacker to force a downgrade to less secure authentication, for example by making the browser remember what web sites have used SRP in the past, and refusing to use weaker authentication protocols for them ever again. Done well, this would also reduce vulnerability to should-not-have-been-signed fraudulent certificates.

Comment Re:Why? (Score 1) 375

Some ways Windows core OS could be improved:

POSIX filesystem semantics, including removing/renaming open files (continue access until closed), transition away from mandatory file locking by default, transition away from carriage returns in text files (fix notepad, start changing tools to default to leaving the carriage returns out), switch to UTF-8 encoding for unicode by default for filenames and contents (instead of 2-bytes-per-character), transition to case-sensitive filenames (when most people use GUIs instead of typing names, why have the insensitive complexity in there...), etc.

Fix it so POSIX api functions are no longer treated as bastard stepchildren - implement them in the core, and emulate others.

Include a good, standard scriptable command line interpreter by default, where it can be counted on to be installed. /bin/sh and associated commands would be a vast improvement, and it wouldn't be hard support command line editting ala bash or zsh as well.

I could go on for some time, but maybe you see the pattern. Summary: Keep the fancy end user GUI stuff, but fix the underlying foundation.

We all agree on the necessity of compromise. We just can't agree on when it's necessary to compromise. -- Larry Wall