View mode: basic / threaded / horizontal-split · Log in · Help
February 22, 2012
Re: Questions about windows support
On Wed, Feb 22, 2012 at 01:21:41AM +0100, Adam D. Ruppe wrote:
> On Wednesday, 22 February 2012 at 00:03:35 UTC, H. S. Teoh wrote:
> >It lets me fire up my (text-based) mail client
> 
> mutt????

Yep!


> I switched to mutt from the terrible webmail in... 2007 I think.
> Rarely look back (only when I need to view images when on a
> separate computer).

Webmail gives me acne. For a while at my job before I figured out how to
download work email onto my Linux development box, I had to use webmail.
No threading, poor folder support, flaky search box, default HTML
formatting (ugh!), it's like Windows 3.0 reincarnated. Eww.


> I handle 200-300 emails a day. I don't think I could handle
> it if not for how awesome mutt is.

Yeah, I saw several people remarking about how unmanageably huge the
Exceptions thread is, but mutt handles it just fine. In fact, without
mutt, I would've lost track of where the discussion was going a long
time ago. (Although, it *is* starting to get to the point where the
threading lines are going past the right edge of the screen...)

Come to think of it, perhaps that's why people started rehashing the
same arguments over and over after a while, 'cos without proper
threading support in your mail client, it's just impossible to keep
track of who is replying to what, much less keep all the different
conversations straight.

Years ago I used to be subscribed to a truckload of opensource mailing
lists. On top of that, if I turned off spamassassin, I'd get about 200
spams a *day*. (My email address is too public, unfortunately.) Only
mutt could handle that sort of mail load. I used to use pine, but it had
no threading, which especially sucked for dealing with mailing lists:
there was no way to delete-entire-thread without manually pressing D 300
times. IIRC it was mailing lists that convinced me to switch to mutt.
Never looked back since.


> >music is finished, run mplayer to start new music, etc..)
> 
> mplayer rox. I also use a play script that runs sox (or timidity) for
> simple files.
> 
> gui music sux.

Yeah, it's just audio, why does it need a GUI interface, right? :) If it
was video that'd be a different story.


[...]
> Aaaand I can run other screens inside!

Nice.


[...]
> Nested screens is pretty amazing. And that automatic
> session means I can open and close it at will, picking
> up exactly where I left off every time.

Nice, I should set that up sometime. I have screen running on a
persistent session, but if I need to reconnect, I have to start over.
It'd be cooler if it was *always* persistent unless the machine itself
went down. Cool.


T

-- 
"Hi." "'Lo."
February 22, 2012
Re: Questions about windows support
"H. S. Teoh" <hsteoh@quickfur.ath.cx> wrote in message 
news:mailman.830.1329870386.20196.digitalmars-d@puremagic.com...
> On Tue, Feb 21, 2012 at 06:01:37PM -0500, Nick Sabalausky wrote:
> [...]
>> Hmm, if that's like Total Commander on Windows, then I don't think I
>> would like it. I do *love* Total Commander's multi-file renaming, but
>> that feature is really the only reason I keep it around.
>>
>> Heh, as bad as this might sound, I think what I basically want is more
>> or less Windows Explorer on linux ;)  (Including the customizations
>> I've installed, like "DOS Prompt Here" and Tortoise*) And yea,
>> Explorer works under wine, but it's kinda like running a GTK app in
>> Windows - but worse since Windows GTK apps at least *know* what OS
>> they're really running on.
>
> Maybe if you write one in D... ;-) Perhaps *that's* the killer D app
> that we've been waiting for, that will take the world by a storm. :P
>

I've seriously been wanting to, but it's one of many things I haven't been 
able to get around to yet.

I suspect, though, it might not end up so popular. Linux people like the 
command line. Although it might help further popularize Linux among WinXP 
fans...

But it's looking like Vlad's D forums might be on their way to being D's 
killer app anyway ;)

>
> [...]
>> > Keyboard/mouse switching is much better when it's a laptop with that
>> > "nipple" thing in the middle of the keyboard. In fact, that's the only
> [...]
>> I like to call it the clit mouse. It beats the shit out of trackpads (I 
>> hate
>> those things with a passion), but I still find them a pain compared to 
>> mice
>> and my trusty Logitech trackball. So I'm the opposite of you there: I
>> actually find it much *easier* to switch between keyboard and trackball 
>> than
>> keyboard and "clit mouse" despite the increased distance. Maybe I'm just
>> weird.
>
> Are you trying to out-weird me? ;-)
>

Heh heh. That's puts me in mind of one of my favorite songs:

"[...]
The so-called weirdos in this country
Stand as completely freaked out by the normal man
As the normal man is completely freaked out
By the weird masses reaction to him

Which came first, you may ask
Chicken or egg, you may ask
Well, the chicken of course
It's time to break this weird-ass chain

The weird masses don't want to be normalized
Weirdos want to be abnormal
The freaks can't be formally normalized
Nor can we normally formalized
What we want is complete weirdification

Basically, we don't want weirdness from the normal man
We don't want to be freaked out by the normal man
We want to out freak the normal man
[...]
Because you are defending our weird women
From the freaky-ass thoughts of the bug-eyed
Bow-legged normal man"
- Butthole Surfers: Weird Revolution

Heh :)

>
> OTOH, ftp.apple.asimov (together with an Apple II emulator) is a
> wonderful resource for those moments of nostalgia, when you're just
> feeling that urge to go boot up with a single beep and see that
> beautiful "]?" prompt staring at you, just like it used to decades ago.
> And then you 'call -151' and geek out on coding some assembly routines
> by typing in opcodes, etc..
>

Yea, I had an Apple II emulator (fantastic!) and some disk images, but I 
think I may have lost them all last time I had a HDD die. Gotta recollect 
that stuff...

>
>> I'm actually a huge Apple hater ever since I got fed up with my 10.2
>> eMac and the whole "Return of Jobs" world and product lines in
>> general. But I *always* consider Woz's Apple II line to be the big,
>> giant, glaring exception in Apple's portfolio.
> [...]
>
> Ah, good ole Wozniak. Wasn't he the one who practically single-handedly
> coded up the entire Apple II ROM? Or am I just mixing up urban legend
> with reality? :)
>

My understanding is that he designed the whole damn machine, period. And I 
have a tendency to believe it, because those older systems really *are* 
simple enough that it's totally possible for one person to understand every 
byte, every clock cycle, every chip and every wire. Hell, that's a big part 
of what makes those machines such a dream to work with anyway. And also what 
made them cheap enough for average consumers - *especially* the Atari 
VCS/2600 - That's just an absolutely beautiful design in it's minimalism 
(had to be, to be useful and only ~$200). Ever coded for it? It makes even 
the Apple II seem enormously complex and powerful. It's sooo fun.
February 22, 2012
Re: Questions about windows support
On Tue, Feb 21, 2012 at 07:27:41PM -0500, Nick Sabalausky wrote:
> "H. S. Teoh" <hsteoh@quickfur.ath.cx> wrote in message 
> news:mailman.826.1329869015.20196.digitalmars-d@puremagic.com...
[...]
> > fg/bg is the best thing on earth since sliced bread. Well, to me. :)
> >
> > It lets me fire up my (text-based) mail client, read mail halfway, find
> > someone mentioning an obscure library function, press ctrl-Z to suspend
> > to mail client, `man obscure_function` to find out on earth they're
> > talking about, then fg to continue reading mail.
> >
> 
> Yea, see I think the reason I almost never use it is because I'm still not 
> used to having it available. "When all you have is a hammer..." So I 
> instinctually just fire up another window, another connection, or another 
> whatever, whenever I need to multitask.

It goes the other way too. When I use my wife's Windows laptop, I keep
trying to ctrl-Z to background what I was doing, and I keep wondering,
how do I get the list of backgrounded tasks so I can get back to that
other thing I was trying to do?? :P  Scarily enough, sometimes ctrl-Z
actually works... 'cos I'm usually on putty when using Windows. :P


[...]
> Not sure if I'll actually end up kicking the habit of avoiding it
> though.  I've spent years on systems (including Windows) with multiple
> desktops available in the taskbar, and I always ended up just using
> one of the desktops. I always liked the idea of multiple desktops, but
> using more than one just meant spending more mental effort on
> organization and "What the hell desktop did I leave that window on??".
> heh :)

Yeah I tried multiple desktops for a while, but after a while it was
just too hard for my little brain to keep track of where things are.
Some WMs try to help by displaying a little desktop map in the corner,
but it doesn't help when you have large windows obscuring small ones
completely.

Eventually I gave up and went the other extreme: ratpoison.  No mouse,
no window title bars, in fact no overlapping windows (except modal
popups), everything is maximized to full-screen, and you switch between
them with keystrokes (which if you keep them <10 in number, you can
address just by doing ctrl-T [0-9]). Remembering a number is easier than
remembering a location, and at least you can see a simple numbered list
when you ask the WM for it, not some jigsaw puzzle that you've to solve
on the spot to find that window you minimized who knows on which other
desktop.

But I wouldn't recommend ratpoison to anyone except rabid hardcore CLI
geeks like myself. Most people cringe when they see my "desktop"
environment. "*That's* your OS?!" they would exclaim. It's just a wall
of text. And then I would flip between a few windows, do some fg's and
bg's, and they'd be completely lost. "What on earth did you just do?
What's all those letters and symbols mean?" My wife sometimes asks me,
"Do you really understand all this stuff?" when the screen is busy
scrolling past during a large compile job. "How do you read all that
stuff so quickly anyway?!" :-)


> > Yeah. And worse yet, I've actually encountered GUI Linux apps that
> > expect input from stdin. I'm not kidding. As they say, fact is
> > stranger than fiction.
> >
> 
> Eww. That's just...wow.

At least it's no worse than this one time, I had a browser plugin go
*really* wrong, and it launches mplayer which somehow believes that it's
being launched from a terminal instead of X11, and then it tries to read
from the *browser's* stdin, causing the browser to get suspended by
SIGTTOU, but when I try to fg the browser, it auto-backgrounds itself
'cos it wasn't designed to read from stdin. Or at least, I *think*
that's what happens.  Who knows. Something in there somewhere has gone
completely wrong, so now *both* the browser *and* the plugin that
launched mplayer are stuck in this limbo of trying to read stdin but
it's not actually possible to type anything into it. :P


> >> The whole Unix philosophy is orthogonality, one tool to do one task
> >> well, no duplicated functionality for slightly-different use cases.
> >> The whole "sudo" vs "gtksudo/kdesudo" thing seems to be some sort
> >> of big ugly hack.
> >
> > It's to prevent people from doing foolish things like logging in as
> > root and doing everyday tasks as root, just because one or two
> > commands *might* require root privileges. It's convenient, it's like
> > Windows and DOS where you can do pretty much anything without this
> > troublesome protection thing.
> 
> Oh, no, that's not what I meant. I understand the need for sudo, and
> I'm totally in favor of it. What bugs me is why we *also* have
> "gtksudo/kdesudo". Ie:
[...]

Ahhh, I see. Mea culpa. :)

The reason is because that monstrosity known as X11 decided to trump the
original Unix design, and implement a security protocol of its own. I
won't get into the gory details here, but basically the usual su/sudo
does give you root access, and the GUI app is actually running as root,
but it needs to connect to X11 via a socket, and the X server has no way
of knowing if the process it's talking to over the socket is running as
root or not. So it asks for authentication tokens which root doesn't
have, 'cos they're sitting in the original user's $HOME somewhere, but
the GUI app doesn't know this, so it tries to look in root's $HOME and
finds nothing.

That's where gtksudo (or whatever it is they call that monstrosity)
comes in: it not only gives you root access, but also sets up some
environment vars in root's environment so that GUI apps launched from
root will actually be able to find the original user's X11
authentication tokens (and possibly some KDE/GTK-specific stuff as
well).

Yeah I know. Wayyy over a newbie's head, for no good reason at all.


T

-- 
Give me some fresh salted fish, please.
February 22, 2012
Re: Questions about windows support
On Tue, Feb 21, 2012 at 07:45:36PM -0500, Nick Sabalausky wrote:
[...]
> Windows's cmd.exe always inserts a newline right before a command
> prompt. So you get the best of both worlds. Only issue is you end up
> with excess newlines. For example, you get:
> 
> C:\>echo Hello > filea.txt
> 
> C:\>echo Hello > fileb.txt
> 
> C:\>
[...]
> Come to think of it, bash should be able to do the same thing if you add a 
> newline to the beginning of $PS1...
> 
> Ha! It does work! Boy is that funny, it makes bash look like windows :) 
> That's just weird.

LOL... yeah that *is* weird.


> But, of course, it does mean a lot of extra blank lines. Which is ugly
> if you're doing a lot of no-output commands. But then, it's also much
> easier to read when there's a lot of heavy-output commands. It's a
> tradeoff :/
[...]

I was going to suggest writing a terminal wrapper to postprocess bash's
output to compress unnecessary blank lines, but then I realized it won't
work, 'cos bash does try to outsmart the outdated terminal concept by
querying the kernel about what kind of stdout it's talking to. If it
decides that the wrapper is a "dumb terminal", then you'll get a
crippled shell with no meta keys, no history, no colors, no nothing
except pure stream output. Which is a lot worse.

And even if you manage to coax bash to work properly, this would
probably also break most text-mode programs that try to do anything more
than just write to stdout as a stream (like anything using ncurses). So
the result would be totally unusable. :-(

Oh well.


T

-- 
If creativity is stifled by rigid discipline, then it is not true creativity.
February 22, 2012
Re: Questions about windows support
On Wed, Feb 22, 2012 at 01:33:56AM +0100, Adam D. Ruppe wrote:
> Thinking about globbing, I think rm * is a mistake
> anyway...
> 
> The way I'd do programs is something like this:
> 
> echo input > program_name options....
> 
> So, you wouldn't rm *. You'd ls | rm.
> 
> You'd implement rm like this:
> void main() {
>      foreach(file; stdin.byLine)
>          std.file.remove(file);
> }

Hmm. Let's implement shell utilities in D! (Pointless, yeah, but a fun
exercise to see how much cleaner D code can be -- if you've ever looked
at that creeping horror that is the source code for 'less'.)


[...]
> This way, options and things to operate on
> are nicely separated, and you can process
> the input with more filters easily.
> 
> glob * | grep 'poo' | rm

Interesting idea. This calls for ... a shell written in D. :-)


[...]
> Windows Powershell actually kinda works this way,
> from what I know of it. You can do
> 
> ps | kill
> 
> and it works.

Nice.


[...]
> I almost *almost* want to write my own custom userland.

Only? Heh... when I was young and foolish, I wanted to trump Linus and
write my own kernel.

But seriously, I *do* contemplate from time to time about writing my own
shell. I have lots of beefs against the way current shells are
implemented, globbing being one of them, or more generally, excessive
implicit interpolation, that turns something simple like \00 into
nonsense like \\\\0000.

My concept of shell is to make it a very thin (but scriptable) layer
over actual syscalls, so you could do something like:

	% open data.txt
	&3: /home/data.txt		# data.txt bound to &3
	% send &3 | grep abc		# pipe data.txt to grep
	abcdef				# output from grep
	% echo @@			# @@ stands for "last output"
	abcdef
	% write &3 @@			# write "abcdef" to data.txt
	% close &3			# detach data.txt

But I haven't actually sat down to think this through, so I don't know
if how practical/usable this will turn out to be. Maybe this will be my
next D project. :P


> But, while I can complain all day about what we have...
> meh it works well enough that I'm in no rush to spend
> a lot of time replacing it.

True.


T

-- 
"The whole problem with the world is that fools and fanatics are always so certain of themselves, but wiser people so full of doubts." -- Bertrand Russell. "How come he didn't put 'I think' at the end of it?" -- Anonymous
February 22, 2012
Re: Questions about windows support
On Wednesday, 22 February 2012 at 02:03:58 UTC, H. S. Teoh wrote:
> Hmm. Let's implement shell utilities in D! (Pointless, yeah, 
> but a fun exercise to see how much cleaner D code can be -- if 
> you've

I'm sooo tempted again.

Though, I don't really like shell utilities.... I'd want many
of them to be accessible through api, and at that point, might
as well just do them all as built ins.

I guess if there's another file available, we can call it
instead to allow easy replacement, but I just think making
the shell there as a library is a really nice thing.

class ShellOperations { /* methods here */ }
then use compile time reflection to build your map for the
command line processing....

Our D shell could be just one program.


though tbh if I was doing a shell, I'd kinda want to do
a terminal replacement too. But, I don't see myself leaving
xterm and rxvt. Nor putty.

idk, should probably limit the scope a bit just to make it
realistic to finish. Use gnu readline too and piggyback on
that pretty nice function for history, editing, completion,
etc.


Actually that makes it fairly doable as a weekend project.

> Only? Heh... when I was young and foolish, I wanted to trump 
> Linus and write my own kernel.

I've tried it before.... but it is terribly boring.

As cool as it is to say "every line of code on that box is
mine and mine alone", that's all it is good for imo: bragging.

The interesting stuff is all user territory.

> My concept of shell is to make it a very thin (but scriptable) 
> layer over actual syscalls, so you could do something like:

Eeeeeeh.... at that point, you might as well just write
your commands in C (or D).

I actually like bash a lot... but only for 1-3 line things.
Bigger than that, and screw it, I'd rather just write C/D.
bash is a huge pain to get anything done for > 3 lines...

But for those 1-3 line things, it is really nice. And, since
it is a command line shell, that's exactly what it should be
optimizing!
February 22, 2012
Re: Questions about windows support
On 22 February 2012 13:06, H. S. Teoh <hsteoh@quickfur.ath.cx> wrote:
> On Wed, Feb 22, 2012 at 12:39:01AM +0100, Adam D. Ruppe wrote:
> [...]
>> Yeah, though I've only seen it suggested for daemon like
>> programs... I think you're the first person who I've seen
>> suggest it for gui apps too.
>>
>> Not a bad idea.
>
> Perhaps I'm just dreaming, but I *think* I've seen one GUI app that
> actually does that. But I could be wrong.
>
>
> T

GVim does it, its amazing, since I normally start it from the terminal
and chronically forget to use '&'. The one downside of this is when
you /want/ the blocking behaviour (git editor for example), gvim gets
around this by providing a '-f' flag that tells it not to fork.

I wish all GUI programs provided that kind of feature set, but I
concede that GVim is made /for/ programmers and launching from the
terminal is a common use case, as is wanting to use it as a drop in
replacement for vim, so here we are.

--
James Miller
February 22, 2012
Re: Questions about windows support
On Wed, Feb 22, 2012 at 03:44:33AM +0100, Adam D. Ruppe wrote:
> On Wednesday, 22 February 2012 at 02:03:58 UTC, H. S. Teoh wrote:
> >Hmm. Let's implement shell utilities in D! (Pointless, yeah, but a
> >fun exercise to see how much cleaner D code can be -- if you've
> 
> I'm sooo tempted again.
> 
> Though, I don't really like shell utilities.... I'd want many
> of them to be accessible through api, and at that point, might
> as well just do them all as built ins.
> 
> I guess if there's another file available, we can call it
> instead to allow easy replacement, but I just think making
> the shell there as a library is a really nice thing.

Totally!! Instead of 500 standalone shell utils, each with the same old
boilerplate command-line parsing, each of which requires fork() and
exec() to use, why not make their functionality directly available as a
library?

It's clear that the trend of computing is toward automation anyway. In
the long-term, it isn't so much about how l337 your CLI skills are in
stringing 20 different commands together in one line, it's about how the
commonly-used functionality in these 20 commands can be reused by
*programs* that call common library functions. Shell-scripting is only a
temporary solution; all those fork/exec calls do add up.

This reminds me of a funny incident at my first job, where there was a
shell script that a coworker was using to generate some reports. It
worked fine up till that point, since it had only been used for
relatively small datasets. That day, someone tried to generate a rather
large report, and it was taking forever. In fact, it took >48 hours to
complete. When the prospect arose that we might need to generate similar
reports again, they approached me to ask if I could do something about
the obvious performance problem of this script.

Turns out the script was really simple, but had to do some amount of
calculations, which it did using code along these lines:

	while [ ! -z "$still_more_data" ]; do
		$data=`cat $inputfile | sed -ne${linenum}p`
		$input=`grep $fieldname $data`
		$result=`expr $result + $input`
		...
	done

There were several *nested* loops like that. I didn't analyze it much
further, but it must had been something like O(n^6) complexity or
something insane like that, due to cat'ing the (same) input file umpteen
times, grepping each line multiple times, saving results to temporary
files and then grepping *those* files (multiple times), and spawning who
knows how many subprocesses along the way.

I rewrote the miserable thing in Perl in a couple of hours, and the Perl
script took 2 minutes to produce the report. :-P

So yeah. A shell utils library would definitely be a big plus.


> class ShellOperations { /* methods here */ }
> then use compile time reflection to build your map for the
> command line processing....
> 
> Our D shell could be just one program.

Yeah, a shell with many commands built-in is a good thing, IMHO. I had
to rescue a remote server using only echo commands (one of the only
commands built into bash). If rm, ls, and friends had been part of bash
instead of needing a fork() and exec() followed by dynamic linking every
single time I typed a command, things would have gone a *lot* smoother.


> though tbh if I was doing a shell, I'd kinda want to do
> a terminal replacement too. But, I don't see myself leaving
> xterm and rxvt. Nor putty.

If you were savvy (or crazy) enough, you could always try your hand at
writing termcap/terminfo entries... :P


> idk, should probably limit the scope a bit just to make it
> realistic to finish. Use gnu readline too and piggyback on
> that pretty nice function for history, editing, completion,
> etc.

True. For a first stab at it, I wouldn't go crazy with trying to rewrite
the terminal. Get some working code first, that's actually usable at the
basic level, then we can get fancy. Nothing more discouraging than a
grandiose uber-design of a utopian system that's sitting in the source
tree with thousands of lines already written but nothing actually
running, and nothing runnable for the foreseeable future.


> Actually that makes it fairly doable as a weekend project.

Go for it!


> >Only? Heh... when I was young and foolish, I wanted to trump Linus
> >and write my own kernel.
> 
> I've tried it before.... but it is terribly boring.
> 
> As cool as it is to say "every line of code on that box is mine and
> mine alone", that's all it is good for imo: bragging.

I dunno, I've always loved low-level coding. I used to keep an eye on
Hurd, because the prospect of moving most kernel functionality into
userspace appealed to me very much. But nowadays I just don't have the
time for highly time-consuming projects like that.


> The interesting stuff is all user territory.

Depends. Linux driver development is a constantly growing area, if
you're into that sorta thing. You won't have fancy graphical sfx to show
for it (unless you're into video driver development), but you'll have
the great satisfaction of knowing that you made that particularly
stubborn piece of hardware actually work nicely with Linux.


> >My concept of shell is to make it a very thin (but scriptable) layer
> >over actual syscalls, so you could do something like:
> 
> Eeeeeeh.... at that point, you might as well just write
> your commands in C (or D).

Well, yes and no. The point was more to play around with syscalls
interactively.

Of course, I also have other shell ideas on the other extreme of the
spectrum, where it's sorta like interactive D, except with a filesystem
navigation / file searching / file manipulation bent, rather than trying
to write a compilable app. (Though it wouldn't hurt if scripting in such
a shell actually was the same as writing an actual D program. :P)


> I actually like bash a lot... but only for 1-3 line things.
> Bigger than that, and screw it, I'd rather just write C/D.
> bash is a huge pain to get anything done for > 3 lines...

For that I use perl.


> But for those 1-3 line things, it is really nice. And, since
> it is a command line shell, that's exactly what it should be
> optimizing!

I can't say I'm too fond of bash syntax. I guess it does the job, and is
relatively expressive, so it's OK. But I'm a programmer-head, so I tend
to turn everything into a programming language. :P (Or Turing tarpits on
bad days.)

On another note, in my first job we had a temp consultant one time, who
had the uncanny ability to write insanely-long bash commands that Just
Work(tm). It's like he thinks in bash, and these insanely elaborate
commands just flow out of him. They are always on a single line, but can
involve 10-15 different programs in a long chain.  They always work on
first try, and work wonders every time. To this day we still don't know
how he does it.


T

-- 
Why do conspiracy theories always come from the same people??
February 22, 2012
Re: Questions about windows support
This is just a guess, since I've mostly used GUI access (VNC, Citrix and 
lately RDP).

I would say SSH use in Windows is quite limited, depending on what you want 
to do,
because historically most Windows developers lack the culture to separate 
application code
from UI, which leads to many applications to be available in GUI form only.

This has been changing in the last years since Microsoft introduced 
Powershell and due
to market pressure created headless versions of Windows. But even if 
Microsoft
would do everything the correct way, programmer culture takes years to 
change.

--
Paulo

"Nick Sabalausky"  wrote in message news:ji0fb2$2hbp$1@digitalmars.com...

"Adam D. Ruppe" <destructionator@gmail.com> wrote in message
news:epzlyfzibmpuoilawaqz@forum.dlang.org...
> On Tuesday, 21 February 2012 at 00:38:46 UTC, Andrei Alexandrescu wrote:
>> ssh into Windows and... well last time I did it it was like "welcome to 
>> Hell".
>
> Oh, certainly!

Does anyone suppose it would work better (or at all) to ssh into MSYS/MinGW?
Anyone tried?

Also I'm curious: what sort of problems were there ssh-ing into win?
February 22, 2012
Re: Questions about windows support
On Wed, Feb 22, 2012 at 08:53:06AM +0100, Paulo Pinto wrote:
[...]
> This has been changing in the last years since Microsoft introduced
> Powershell and due to market pressure created headless versions of
> Windows.

Wow. Headless Windows? Can it even be called Windows anymore? :)


T

-- 
IBM = I'll Buy Microsoft!
4 5 6 7 8 9 10 11
Top | Discussion index | About this forum | D home