Darren New <dne### [at] sanrrcom> wrote:
> The Linux boot partition today is 
> multiple times the size of the biggest hard drives you could put on 
> "desktop" computers 20 years ago, and orders of magnitude bigger than 
> the disk space available on a mainframe 40 years ago.

  There's no such a thing as "*the* linux boot partition" with regard to
size. You can create a bootable linux partition (with the latest kernel
and many utility programs) which fits on a floppy disk, so that you can
boot with it.

> >   This was rather common especially at universities and other similar
> > academies: You were lucky if you had access to an actual desktop computer.

> Given the power of desktop computers 20 years ago, I'd disagree with the 
> "lucky" part of that. ;-)

  I believe you are old and academic enough to have used VT terminals.
I'm not sure which one I would prefer, an old desktop computer or a
dumb VT terminal... :P

  (Yes, I am old enough that I got to the University here early enough
that VT-220 terminals were still in common use. I read my email, the news,
made programming assignments and even played batmud with those terminals.
The Internet was still a new thing that practically nobody had. Ah, the
memories.)

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
>   There's no such a thing as "*the* linux boot partition" with regard to
> size. You can create a bootable linux partition (with the latest kernel
> and many utility programs) which fits on a floppy disk, so that you can
> boot with it.

Whatever. Fine.  "*My* Linux boot partition."  Happy? Sheesh.

A *floppy* is still more space than most mainframes had available in RAM 
30 years ago.

>   I believe you are old and academic enough to have used VT terminals.
> I'm not sure which one I would prefer, an old desktop computer or a
> dumb VT terminal... :P

Well, there is that. :-) Of course, the hard-copy terminals were handy, 
given we were using a mainframe with a file system sophisticated enough 
you could edit a file you'd printed out and still be able to edit it 
again later without a lot of hassle. (E.g., you didn't get whole new 
line numbers in your compiler errors because you added a bit of code 
near the top.)

I do remember appreciating that the only way to edit on the glass ttys 
was to use the 1200 baud connection in the sys admin's office.

> The Internet was still a new thing that practically nobody had. Ah, the
> memories.)

I don't think there was even internet access around until after I 
graduated. It certainly wasn't cheap enough that a school as small as 
mine was going to pay for it. Wasn't until grad school I got that. Altho 
I did hang out on compuserve for a bit.

-- 
Darren New / San Diego, CA, USA (PST)

Post a reply to this message

Invisible wrote:
> Well, currently a program's arguments are just a giant blob of text. The
> OS does nothing more than hand it over to the program, which may then
> interpret them in any way it pleases. This is LCD; it works for
> everything, but it's not terribly sophisticated.
> 
> How about if, say, the program could somehow "tell" the OS what
> arguments it actually accepts? (In the same way a program file usually
> contains metadata to "tell" the OS all kinds of other stuff about it,
> such as linking information.) Then the OS could report invalid argument
> names without even needing to bother actually starting the program
> itself. And just think of the auto-complete possibilities.
> 
> Hey, let's go one better. The majority of CLI arguments are either
> on/off switches or filenames, right? Well what if we *tell* the OS what
> things are on/off switches, and that their default state should be? What
> if we *tell* it which things are supposed to be filenames? (And whether
> the name in question *should* or *should not* exist when the program is
> run? Or whether it should be a *file* or a *directory*? Or maybe even
> the name of another program?)

You don't need a whole new OS for that.

Recent versions of bash come preconfigured for smart autocomplete. Random
example: 
apt-get remove <tab> completes package names you already have installed.

Or look at fish (my current shell). It colors the stuff you type in real
time. Type ls --srot and it will show red, so you know you
mispelled --sort.

http://www.fishshell.org/screenshots.html

Post a reply to this message

Nicolas Alvarez <nic### [at] gmailcom> wrote:
> Recent versions of bash come preconfigured for smart autocomplete. Random
> example: 
> apt-get remove <tab> completes package names you already have installed.

  I like the smart autocomplete in zsh. For example, if I write this in zsh:

mplayer -su<tab>

it will autocomplete it to "mplayer -sub", but since that's not the only
possible valid completion, if I press tab again, it will list all the
possibities:

mplayer -sub<tab>
-sub                 -- use specified subtitle file
-sub-bg-alpha        -subcp               -subfont-osd-scale
-sub-bg-color        -subdelay            -subfont-outline
-sub-no-text-pp      -subfont-autoscale   -subfont-text-scale
-subalign            -subfont-blur        -subfps
-subcc               -subfont-encoding    -subpos

  The autocompletion of file names is also application-dependent. For
example, if I have three files in the current directory, let's say
test.txt, test.cc and test.pdf, if I write this:

acroread t<tab>

it will directly autocomplate to "test.pdf" because that's the only one
of those files which is valid for acroread.

  Also if I have a bunch of files whose names start with a 't', and all
of them have the access rights "-rw-r--r--" except one, which has the
rights "-rw-------", and then I write this:

chmod og+r t<tab>

it will directly autocomplete to the only file for which that command
makes sense (ie. the file which didn't have the +r rights already).

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
>   The autocompletion of file names is also application-dependent.

FWIW, bash does this too. I suspect perhaps the zsh configuration files 
are more complete, but I've been annoyed by trying to autocomplete the 
destination directory of a "mv" command that wasn't writable and getting 
ticked that the autocomplete just stopped working. :-)

-- 
Darren New / San Diego, CA, USA (PST)

Post a reply to this message

Warp wrote:
> Nicolas Alvarez <nic### [at] gmailcom> wrote:
>> Recent versions of bash come preconfigured for smart autocomplete. Random
>> example:
>> apt-get remove <tab> completes package names you already have installed.
> 
>   I like the smart autocomplete in zsh.

Bash can do that too. It's just stupidly disabled by default.

From fish design document:
"A special note on the evils of configurability is the long list of very
useful features found in some shells, that are not turned on by default.
Both zsh and bash support command specific completions, but no such
completions are shipped with bash by default, and they are turned off by
default in zsh. Other features that zsh support that are disabled by
default include tab-completion of strings containing wildcards, a sane
completion pager and a history file."

Post a reply to this message

Nicolas Alvarez wrote:
> Invisible wrote:
>> Well, currently a program's arguments are just a giant blob of text. The
>> OS does nothing more than hand it over to the program, which may then
>> interpret them in any way it pleases. This is LCD; it works for
>> everything, but it's not terribly sophisticated.
>>
>> How about if, say, the program could somehow "tell" the OS what
>> arguments it actually accepts? (In the same way a program file usually
>> contains metadata to "tell" the OS all kinds of other stuff about it,
>> such as linking information.) Then the OS could report invalid argument
>> names without even needing to bother actually starting the program
>> itself. And just think of the auto-complete possibilities.
>>
>> Hey, let's go one better. The majority of CLI arguments are either
>> on/off switches or filenames, right? Well what if we *tell* the OS what
>> things are on/off switches, and that their default state should be? What
>> if we *tell* it which things are supposed to be filenames? (And whether
>> the name in question *should* or *should not* exist when the program is
>> run? Or whether it should be a *file* or a *directory*? Or maybe even
>> the name of another program?)
> 
> You don't need a whole new OS for that.
> 
> Recent versions of bash come preconfigured for smart autocomplete. Random
> example: 
> apt-get remove <tab> completes package names you already have installed.
> 
> Or look at fish (my current shell). It colors the stuff you type in real
> time. Type ls --srot and it will show red, so you know you
> mispelled --sort.

Does it work if you add some arbitrary new program?

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Invisible wrote:
> Does it work if you add some arbitrary new program?

...and you write the bash/zsh/fish completion script, yes :)

Post a reply to this message

Nicolas Alvarez wrote:
> Invisible wrote:
>> Does it work if you add some arbitrary new program?
> 
> ...and you write the bash/zsh/fish completion script, yes :)

OK, fair enough then.

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Darren New wrote:
> Invisible wrote:
>> Except that (say) GIF supports animation and only 256 colours and 1-bit
>> alpha, whereas PNG supports only single images, but with 24-bit colour
>> and 8-bit alpha, and TIFF supports something else again...
> 
> Um, yes? So? You don't think you can abstract that?  (BTW, GIF supports
> more than that, as you can change the color table after each row. FWIW.)

Not after each row. After each animation frame.

Post a reply to this message