 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 16-Dec-08 0:37, Jim Henderson wrote:
> On Mon, 15 Dec 2008 23:27:13 +0100, andrel wrote:
>
>> On 15-Dec-08 23:15, Orchid XP v8 wrote:
>>> Nicolas Alvarez wrote:
>>>> Orchid XP v8 wrote:
>>>>> And then I had to reboot the PC to get out of Vi. :-P
>>>> WTF?
>>> Do *you* know what the keystroke to quit the program is? :-P
>>>
>> q or q! if you made changes. Am I missing something?
>
> technically, :q or :q! - the first will exit and prompt you if you made
> changes, the second will quit and not save your changes. If you want to
> quit and save changes, then :w will write. I prefer shift+ZZ myself, it
> quits and writes changes. :-)
me too. I have been known to type ZZ to exit emacs and a variety of
other editors.
BTW to connect a few treads: Andrew have you ever seen the Turing
machine as implemented in vi? I had it once, it should be somewhere on
the interweb, no doubt, but I can not immediately find it.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 16-Dec-08 9:54, Invisible wrote:
> Jim Henderson wrote:
>
>> User error. He didn't know how to exit vi with shift-ZZ or :q! or :w!
>
> One might argue "designer error" for making the system so non-obvious to
> operate. :-P
If you continue that, you can also claim that it is an even more
fundamental error to assume that anyone can operate that flat beige
piece of plastic with all those buttons. From the designer at that point
in time and also for the first batches of users, that was obvious. You
OTOH have been brainwashed by current technology where even the ^C is
redefined in an horribly backwards incompatible way.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 wrote:
> Surely if you wanted to build an entire game completely from scratch,
> building the game engine would be a *relatively* small part of the
> problem - but it's not trivial by any stretch of the imagination.
Certainly. I'm just wondering about the relative percentages. I think enough
people rebuild engines from scratch when they need to that it obviously
isn't ridiculously undoable.
>>
>> It doesn't have to be identical functionality. It only has to be
>> "correct."
>
> No - has has to be "incorrect" in exactly the same way that Windows
> implements it incorrectly.
It only has to be incorrect in the way that's consistent for all the
programs you want to support. If a virus takes advantage of a buffer
overflow, but no legitimate program does, you don't have to have the buffer
overflow work the same way.
More likely, if Win98 allocates memory on 2-byte boundaries, and WinNT et al
allocates it on four-byte boundaries, and you're happy not supporting Win98
binaries on your WINE, you don't need the code to allocate on 2-byte
boundaries. Anyone who depends on which boundary you allocate on will either
work, or fail in a way that you know isn't supported.
> Every bug and glitch has to be precisely
> replicated, or some lump of software somewhere that depends on those
> bugs won't work right.
Only the bugs and glitches that some piece of software you want to support
depends on needs to be implemented. And when you find that software failing,
you now have a test case to figure out what real Windows is doing that your
code isn't.
--
Darren New, San Diego CA, USA (PST)
The NFL should go international. I'd pay to
see the Detroit Lions vs the Roman Catholics.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jim Henderson wrote:
> On Mon, 15 Dec 2008 22:18:25 -0600, Mueen Nawaz wrote:
>
>> Let's be realistic: Linux could be a huge headache, especially
> for one
>> who's not very computer-savvy.
>
> My wife's not very computer savvy, and she uses openSUSE 11.0
> exclusively. She hasn't touched Windows in years.
>
> Her needs are fairly simple - web browsing, IM, writing tools. She uses
> an older Compaq laptop and has no problems at all (well, the speakers are
> a bit tinny, but you can't blame Linux for that).
>
> So sorry, I don't buy that.
You don't buy that it *could* be a huge headache? If you think a
counterexample suffices to make your case, I can start itemizing quite a
few real cases where it was a headache.
--
BREAKFAST.COM Halted... Cereal Port Not Responding.
/\ /\ /\ /
/ \/ \ u e e n / \/ a w a z
>>>>>>mue### [at] nawaz org<<<<<<
anl
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
andrel wrote:
> me too. I have been known to type ZZ to exit emacs and a variety of
> other editors.
I often got Vim commands in the middle of POV-Ray code; since I was using
POV-Win editor, where the Esc key doesn't really get into command mode :)
And even more often, pressing Esc and noticing before typing a command.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas Alvarez wrote:
> That's how Picasa for Linux was made (a photo organizer by Google).
And I must note: the day Picasa for Linux was released, Google also sent
around two hundred bug fixes to Wine developers.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
> 100% impossible
Stop saying that!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
> I mean, an MP3 player isn't exactly a complex piece of hardware. There's
> a battery, a harddrive, a processor, and a DAC. I would think those are
> all off-the-shelf components. Just stick them in a box, put in the 3
> microswitches for the buttons, and your hardware is done.
Many have special chips to do some steps of MP3 decoding. Or MPEG4 video
decoding!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
> > Every bug and glitch has to be precisely
>> replicated, or some lump of software somewhere that depends on those
>> bugs won't work right.
>
> Only the bugs and glitches that some piece of software you want to
> support depends on needs to be implemented.
Actually, even more. It's obvious that WINE leaves *tons* of stuff
unimplemented. CreateFile() does not update performance counters, doesn't
check group policy, probably doesn't do *any* sort of security checks
(beyond what Linux does), doesn't write audit logs, and maybe doesn't
support UNC path names, probably doesn't support the various flags that
CreateFile() natively supports like surpressing read-ahead or locking the
file from deletion, probably doesn't support compressed or encrypted files,
doesn't update any sort of USN logs, and so on.
So it's clear it's not necessary to duplicate the API precisely. You only
have to duplicate it well enough to fool the software using it. You probably
don't have to distinguish between (for example) not having permission to
open the file and not having permission to traverse the directories above
the file.
--
Darren New, San Diego CA, USA (PST)
The NFL should go international. I'd pay to
see the Detroit Lions vs the Roman Catholics.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mueen Nawaz wrote:
> You don't buy that it *could* be a huge headache? If you think a
> counterexample suffices to make your case, I can start itemizing quite a
> few real cases where it was a headache.
Or, as is common in my circle to say, "The plural of anecdote is not data."
--
Darren New, San Diego CA, USA (PST)
The NFL should go international. I'd pay to
see the Detroit Lions vs the Roman Catholics.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
