Further, when installing, it would hang at some point without any sign of a prompt but would instantly continue if the mouse were moved. You could easily test this - turn your mouse upside-down during install and wait (to avoid any incidental mouse motion due to desk vibration etc).
Told my IT friend who was loading my machine and he said "you're confused; I've installed hundreds of times and never seen that". So I turned his mouse upside down and waited. Voila! It hung.
I recall quite a few times having to send a message to the message queue in code I'd written for this reason. I forget why though - someone can probably remind me, if I didn't send a message it would just stop.
It looks like you're not the only one! From the comments on the top response:
> "If true, I owe some baby boomers apologies for things I said about 20 years ago"
Me too.
What a humbling slap-in-the-face, no?
Sometimes when an idea sounds silly, and comes from a less technical person, one might disregard it even though it's easily testable/provable.
One thing about the famous "500 miles" post that I realized doesn't make sense:
----
An odd feature of our campus network at the time was that it was 100%
switched. An outgoing packet wouldn't incur a router delay until hitting
the POP and reaching a router on the far side. So time to connect to a
lightly-loaded remote host on a nearby network would actually largely be
governed by the speed of light distance to the destination rather than by
incidental router delays.
Feeling slightly giddy, I typed into my shell:
$ units
1311 units, 63 prefixes
You have: 3 millilightseconds
You want: miles
* 558.84719
/ 0.0017893979
----
But surely for Sendmail to register a "connect" with a remote SMTP server would require at least one (or many?) round trips to the remote server, so one-way speed of light time doesn't seem like it would really be relevant. Am I missing something?
Possibly the introduction wherein the author says:
"The story is slightly altered in order to protect the guilty, elide over irrelevant and boring details, and generally make the whole thing more entertaining."
If memory serves he goes into further detail about the alterations and some common objections to the story in his FAQ:
I believe one version of this story explains that the math (and the situation) has been simplified for the sake of this story in order to make it readable.
Makes sense, I can share this story to people without any computer knowledge, but something explaining how connections are established would be wholly incomprehensible to them.
What in the world could possibly be the reason in that first story for the 'file' program to look for the string 'Tue' and change to the Jam filetype? That's gotta be a very niche case, right?
On that subject, don't make fun of people who paste screenshots into Word docs and email them. On Windows 95, that was a really good idea!
MS Word was one of the few ubiquitous tools that would compress images, and certainly one of the few that people could be counted on to know. MS Paint didn't support PNG until Win98, and even then wouldn't do it by default.
If you didn't go via Word, chances are you'd be emailing a 900kB BMP at a time when people used 28.8k modems to access Hotmail accounts with 2MB caps.
The softness is precisely what made them a useful check, though. Tapping num lock has two important properties: Nothing should ever be blocking that process, and it's harmless to do and should never really affect what's happening.
And this reminds me of when I accidentally figured out playing MOD sound files in DOS 6 with a new and especially beautiful STM/MOD player at the time would sound considerably better from my 486's PC speaker if I pressed the pause/break key to literally lock up the system. Apparently the player would buffer enough of the song that even though everything froze up, the sound would continue playing. I couldn't afford a dedicated Soundblaster/Gravis sound card but I still pined to hear all the amazing music coming out from the demo scene. The quality of course wasn't comparable to a dedicated soundcard but it was still a huge improvement over the typical beeps/bloops of the built-in PC speaker.
Galaxy 2.12 (glx212.zip) is my favorite for pre-386 machines. It'll do remarkable things with a covox or even pc speaker, and realtime FFT (not faux bouncing bars, either!) to boot!
“One danger of the MsgWaitForMultipleObjects function
is calling it when there are already messages waiting
to be processed, because MsgWaitForMultipleObjects
returns only when there is a new event in the queue.“
In order to show the properly random and non-deterministic behavior (e.g. random BSODs) that Windows users have come to expect, MS Windows needs to continuously gather high-quality entropy from its surrounding environment. That's why it stops when you're not wiggling the mouse; it's just waiting for you to provide the additional entropy it needs.
No, it’s actually a little-known feature that allows Win95 to temporarily upclock the CPU during peak loads, using the power generated by vigorous mouse movements.
This wasn't just restricted to COM port based I/O either.
Back then I had a Logitech bus mouse. The mouse was connected directly to an ISA card, and didn't use the COM ports as most mice did back then. (I needed the extra COM port/IRQ for my modems.)
I too witnessed the 'windows is running slow when installing' bug. I often would use the mouse cursor to 'mark' the position of the loading bar (we really are spoiled for speed these days). That way when I would walk-away from an install I could see if the progress meter moved while I was away. More often then not the progress bar would still be where it was when I had left. By moving the mouse activity would return and the installation would continue.
I always assumed it was the graphics that were not being updated. A small bug with the install would keep running but the lack of input interrupts caused the display to get 'stuck'. (That would explain the sudden 'jump' in progress bar movement as soon as I wiggled the mouse.)
But what newbies will bever know the heck of: dip switch settings for IRQ for modems.
Thats what literally got me into computers...
In order to dial up BBSs and play tthe Pit and dl warez.
—-
Ive told this story before, but in about 1992? Or so - i got grounded for a month because i had been calling in long distance to a bbs in san jose to play the pit - and racked up a long distance bill of $926 - my dad was livid.
He yelled at me and said “why are you wasting all this time with computers! Its never going to do anything for you!”
Years later after i became successful with yee olde computerz! He apologized to me and said “im sorry i yelled at you for that time you cost me all that money in long distance charges.”
I also got yelled at by my dad for racking up long distance charges in 1991 or 92 but in my case it was only about $150 for calling the Sierra BBS to download stuff for King's Quest games or something :)
Same here, except it was San Jose to San Jose. However still had a bill because I was in Zone 1 and the BBS was in Zone 3 (phone book tells you which zone) So.. charges. Dad wasn't mad, I think he realized I was going to get a job in the field.
> Ive told this story before, but in about 1992? Or so - i got grounded for a month because i had been calling in long distance to a bbs in san jose to play the pit - and racked up a long distance bill of $926 - my dad was livid.
I had this problem until I discovered a bug in a Major BBS door game (TradeWars 2002) that let me have unlimited BBS credits. No more charges on my moms phone bill and even was able to trade those for other things in real life. Early bitcoin in a way.
Looking back on it, my need to get online overrode my ethics regarding either my moms bank account or the sysops running the BBS. Oh well.
"Years later after i became successful with yee olde computerz! He apologized to me and said “im sorry i yelled at you for that time you cost me all that money in long distance charges.”"
At which point you lit up your Havana Muy Gordo with a $1000 bill and said, "Don't sweat it?"
Similar but earlier story... staying up late at night or waking up early before school to login to BBS's. First with a Practical Peripherals modem that my dad acquired to dial into his business (which still used teletype). I got myself a Hayes 2400[1] and convinced my dad to get the fixed calling within your area code which I mostly paid for with my part-time work. I tried to stay within my LATA which included Sherwood Forest, Camelot, some others with doors and FIDO that can't recall. And then I made a mistake and on the advice of another BBS'er tried one in what I thought was a neighboring LATA. It was great! Active! Doors! gFiles! Warez! But was actually zones away in Texas. I had a good old time until the bill came. My Dad was purple he was so angry and I worked a lot of odd jobs to pay that off.
.
.
[1] somehow just before college I got a used USR Courier HST. Then I sent it in with what was probably all of my hard earned beer money for upgrade to a Courier v.Everything... I still have that one, found it while moving https://v.gd/gF83mM)
One time I was installing Windows 95, I had to move the cursor the whole time because otherwise the installation got stuck. I discovered this after at least 30 tries.
I guess what has changed is me, not the computing environment. When I was young, I easily grew impatient when things were going slow. Nowadays I still kinda feel nervous, but not to the point to warrant such bookkeeping methods.
My urge to measure everything has only grown with age. I don't chalk it up to nervousness though. I'd say it's driven by curiosity and and a desire to forecast.
I find the Progress bar is usually about as accurate as the Time Remaining calculation. Both are better than nothing but more of a fiction than reality.
When I implement progress bars I most often implement "pessimistic progress", so "considering all timeouts, worst case we are 46.5% (of the time) to some result", with an update every few hundreed milliseconds. As possible mix in data from completed subtasks.
Nobody ever complains if the process suddenly speeds up because progress was made before the timeout, as long as your initial estimate wasn't absurd (looks at Windows Explorer). Even a naive progress bar counting down the 60s timeout is more informative and satisfying to watch than an endless spinner.
Windows 95/98 used to occasionally do some particularly insane estimates. I took this screenshot many years ago of copying a tiny NetHack install between drives: https://i.imgur.com/q7tc9R1.png
Vista, I think it was Vista, "fixed" that by adding an estimation pass first, that often took longer than the copy itself, and was almost as bad at estimating. It sometimes took much longer. The fix was far worse than the problem, yet it survived unchanged.
It was so bad I ended up discovering Teracopy which was decent at estimation, and far faster at copying. Was a must-have until I migrated away from Windows.
How exactly do utilities like Teracopy implement high-performance copying? In other words, what are the performance bottlenecks in explorer.exe? Personally, I've observed that:
1. Explorer attempts to do a file enumeration prior to copying, which sometimes could waste a lot of time.
2. It seems tools like Teracopy use buffering aggressively, which can speed up the copying significantly based on my experience on Windows XP with slow HDDs.
Single pass and aggressive buffering seems to cover what I remember, but it worked better than it I expected, even on high speed drives or SSD to high speed drive. They may have had other tricks, it's been a while now.
The other thing that I liked is it's non-blocking - you can continue doing copies while one is in progress, if it's to the same destination it gets added to the queue in progress. If different destination it goes in a new queue that waits for the first to finish.
True! I know some of the people involved in the windows update bar. Since cpu and dusk are so different across devices it’s hard to know actual time it will take. Instead teams divided their packages into theoretical weights and the progress bar showed the percent of total “weights”. That’s why it can be choppy is packages with few subdivisions have little to interpolate.
Progress indicators that moving perfectly and steadily are probably time based, but I'd have thought they've always been work based. Example: you know you have to copy 20GB across the network; update the progress bar with 'percent of data complete' periodically (on a timer, in the byte copying loop, whatever.)
I've seen dual progress bars: one for "overall progress" (each one of five tasks fills this bar 20%) and one for the current task (maybe downloading, maybe unpacking, maybe copying, maybe waiting for hardware to reply...)
I've written progress bars that combine all of the above. Each sub-task had a weight though, and adaptive interpolation was used to animate the progress bar between chunky updates from less granular tasks based on how far they usually increment over which time interval.
With a process that happens on regular intervals like a Windows Update, I always wondered why the system doesn't store metrics on how long the process has historically taken on previous runs, and then just uses a weighted average of historical times as a time-based total estimate, converted into a divisor for work-based progress estimates (i.e. if previous runs took 60 minutes on average, then progress at 25% would say "45 minutes remaining", then if it suddenly jumped to 50% would immediately say "30 minutes remaining." Even if they're choppy, those time estimates would actually be correct if you sampled and averaged them.)
Not sure if anyone's mentioned this yet, but the old original Mac OSX boot screen had a progress bar that was based on the exact length of the previous boot time.
Shit, I think I last used it last week! In my GUI wrapper for rsync while transferring some large files. It took about 45 minutes for one of the files.
>I too witnessed the 'windows is running slow when installing' bug. I often would use the mouse cursor to 'mark' the position of the loading bar (we really are spoiled for speed these days).
Most software doesn't feel any faster compared to Windows 95 (see Wirth's law). Also most shitware does not display a loading bar anymore, instead you get some spinning stuff that's just an animation.
> Also most shitware does not display a loading bar anymore, instead you get some spinning stuff that's just an animation.
In fairness, that's because users constantly complained about loading bars not being accurate (they'd freeze, change speeds, stop right at the end etc.), but having a "true" loading bar that proceeds smoothly basically requires solving the Halting Problem. So out it went.
I mean, I still do the mouse thing all the time, regardless of OS. Not because I actually expect it to go faster, mind you, but rather because I'm bored.
From a comment:
Try opening a large file with Notepad on a contemporary machine. The window must not be full screen. When loaded, mark all text using the mouse (the keyboard works as well, it just needs more manual skill). While still holding the button down (and marking) move the mouse down, so the text gets marked and scrolled. Now compare the scroll speed while holding the mouse still versus wiggling it. Depending on your machine the speed up can be several times faster.
It's not just Notepad :-) I do this often, when I have to mark a lot of things.
It's not clear that this is caused by the same effect. A commenter suggests that this behaviour is actually due to how mouse acceleration affects scrolling speed which I am more inclined to believe.
Yeah there is no way this has anything to do with the same behavior. What's likely happening is there's a delay in auto-scroll, and by generating new mouse events your triggering manual scrolls at a higher rate (or in addition to?) than auto-scroll.
I think you'll find that Shift + Page Down is the fastest way to mark a lot of text, since you're doing it page by page instead of character by character.
I had completely forgotten about the mouse-wiggling trick! It's just one of those things I used to do without thinking about it. It makes sense that an event loop was waiting for an event to fire.
I don't know the reason for that, but like the cursor to mark the progress bar method above, I do this trick to this day. You don't have to highlight first, you can just highlight as you go, wiggle the mouse outside of the bounds of the window, and then deselect when you get where you're going. And it's not just in Notepad, I do this in a programmers editor too.
Isn't it funny that many of us learned these sames ways of interacting with computers without being explicitly taught. If this were on the Internet, I would say it's a way to gauge whether you're a robot, but otherwise, it's just a measure of my impatience. Maybe it's just an acquired skill from growing up playing video games.
Are you suggesting it’s faster or slower when you wiggle the mouse? If it’s slower it could be because you put more events in the event queue that have to be pumped.
This applies to Macs as well. Or at least it used to, in some situations — now that I think about it, I can't really recall the last time I did that. The standard behaviour now seems to be scrolling faster the farther the mouse is from the edge of the pane (which is clearly a deliberate, and useful, UI decision).
I've implemented the behavior of "scroll the field down while the user is holding something selected" before, and my initial implementation had this bug, so I think I can explain a likely reason this happens. My code listened to mouse movement events, and if a selection was present and the mouse was moved into the top or bottom regions of the scrollable area, then the area would scroll a bit, and a recurring timer for some number of milliseconds would be started (if already active, then it would be reset) which would case the area to scroll a bit more. (This timer would be canceled if the mouse was moved out of the auto-scroll region.) If you continually moved the mouse, then it's possible the application would get the mouse movement events at a higher rate than the timer would fire, so the scrollable area would scroll faster. I think I found out that the platform would emit the mouse movement events at up to 60fps, so I just tweaked the timer to match that. Not a perfect solution, maybe I'll update it eventually to check the system time and scroll slower if the mouse move events are arriving faster than the timer.
Its like rage shake for mouse! If you are angry and shake your mouse in rage it moves things faster. I imagine this would be a very satisfying thing to be able to do.
To this day, when waiting for some long or compute-intensive operation, I tend to instinctively move the mouse around. I guess this may be why.
Ironically, even though I grew up on Windows, I don't remember any actual case of "moving the mouse speeds thing up" on this OS - I only remember the infamous Linux cases (mouse move regenerates entropy, unblocking processes that got stuck when generating a random number call). But there must have been something, and I must have experienced it early enough in my childhood.
While running emacs over a modem to arpanet or dialup, I got into the habit of regularly typing ^A ^E to pace my cursor back and forth across the current line, to keep the connection and emacs warm.
(Like a caged leopard or mad scientist pacing back and forth.)
I could feel how responsive the connection and emacs were over time by the delay between typing and seeing the cursor move. Both the network and emacs contributed to the feeling:
There was the overall "weather" of the network: sometimes sunny and fast, sometimes sprinkled with light delays, and sometimes stormy congestion. Then there were occasional incidents that came and went, like network hiccoughs and emacs paging and grinding. And then there was the overall load of the system, which gave you the baseline delay (which gave it a very tactile day -vs- night feeling, since you got more of the machine to yourself during the night when it felt snappy, but it felt sluggish during the day).
It really felt like either the network, emacs, or both would fall asleep if you didn't keep them warm and lavish them with attention.
A VAX 11/780 running Gosling Emacs over a dialup had a very different feel than a PDP-10 running ITS Emacs over the arpanet. The busy VAX was bursty and had a lot of bumpy paging -- you had to keep your buffers warm or they would all get paged out and it would take a long time to wake back up, but there was no network delay from the direct dialup. While the PDP-10 ran smoothly like a well lubricated steam locomotive, sometimes slowing down when busy, but hovering around same speed instead of bursting, and the delay was mostly the feel of arpanet congestion and imps dozing off.
(Or so I imagined. I had a lot of time to sit and think while waiting for the cursor to move again, and the mind wanders and wonders what's happening...)
TOPS-20 had a wonderful ^T keyboard interrupt that you could
type to instantly show the system load and time. (But of course you couldn't use that in emacs, which puts the tty into raw mode.)
Somebody at the university implemented ^T to 4.2 BSD on the cs department's busy VAX 11/780, by modifying the tty driver. But initially, there was no limit to how often you could type it, and calculating the current system load wasn't a trivial operation.
So on a fast terminal, if you held down and auto-repeated ^T, it would bring the entire system to its knees, and you could watch the load go up and up and up as you caused it to! Very satisfying indeed.
Eventually they put in a one-per-second limit on ^T.
> While running Emacs over a modem, I got into the habit of regularly typing ^A ^E to pace my cursor back and forth across the current line, to keep connection warm.
Huh. I got into that habit recently, because over the past year, I've been frequently working on the go, by SSH-ing to my home desktop and using Emacs terminal frame (emacsclient -t)[0]. I do regular "weather checks" with ^A and ^E - because the hardware has its weather, SSH has its weather, and the link I'm on has its own weather too (particularly when using an LTE hotspot, though I've noticed even when being in the same LAN, the response time is not always consistent).
What's old is new again :).
--
[0] - With terminal emulators supporting 256 colors, it looks very similar to the GUI Emacs. This mode of working is really quite good, and lets me use my underpowered sidearm 2-in-1 tablet/netbook to do things that would ordinarily require powerful hardware.
> > While running Emacs over a modem, I got into the habit of regularly typing ^A ^E to pace my cursor back and forth across the current line, to keep connection warm.
> Huh. I got into that habit recently, because over the past year, I've been frequently working on the go, by SSH-ing to my home desktop and using Emacs terminal frame (emacsclient -t)[0]. I do regular "weather checks" with ^A and ^E - because the hardware has its weather, SSH has its weather, and the link I'm on has its own weather too (particularly when using an LTE hotspot, though I've noticed even when being in the same LAN, the response time is not always consistent).
You may find mosh [0] to be useful, as it buffers input client side to remove input lag.
The ^T command is actually still around in Unix/Linux, but only when the program is reading input using canonical/cooked/non-raw mode. That's pretty uncommon these days, since input tends to be wrapped in readline or similar to allow for editing.
You can test it by running `ed`:
ed scratch.txt
2096
^T
load: 0.57 cmd: ed 74469 waiting 0.00u 0.00s
q
Running `stty -a` lists all of the characters that have special meaning when the TTY driver handles input this way, before the program sees it.
Making a huge selection with mouse in LibreOffice spreadsheets even today goes faster if you move the mouse while dragging one endpoint of the selection over the spreadsheet borders which causes the sheet to scroll. Likely the very same cause: there's a timer or other repeating tick to scroll content at a reasonable speed but the sheet is also scrolled when input events wake up the same loop.
I remember this with any selection in windows on at least 3.1/95/98/SE.
This happened if you kept the mouse just inside the window and moved it about 10-20px up and down in/out pf the window in the direction of the selection.
It was a way for me to scroll faster than with the wheel or cursors on web pages if you selected some text and then kept the selection on the end of the screen and moved the mouse wildly in the edge of the screen.
As I was younger then, there was probably a better solution to do this but I was not aware of it.
The mouse isr would cause a loop like this to execute at some point, processing all the messages on the queue. Win95 had preemption, but it ran at 100hz. Moving the mouse caused additional queue processing on top of the time sliced preemption.
Linux's default varies per architecture & platform. For a long, long time on ARM it still defaulted to 100hz. I think it's more like 250hz or 500hz now? You'll also see x86 desktop-focused build set it to 1000hz.
But scheduling happens far more often than this tick rate, too, so it's only preemption for busy threads and controls the timing windows for things like DVFS.
I thought the windows clock defaulted to ~60Hz. I understand it could be pushed up by software to 1Khz for audio players to work correctly. I may be very wrong on the latter point though.
When I used to hang out at Radio Shack in the mall to play on a TRS-80's after school, they would draw a pair of asterisks in the corner of the screen and occasionally flash one of them on and off, as they loaded from cassette tape.
One of the older kids who hung out there would tell us newer kids that we could speed up loading by repeatedly pressing the up arrow key on the keyboard.
Of course us new kids didn't realize that the loading speed was completely determined by the cassette tape speed, which the keyboard couldn't possibly affect.
But at least it gave us something to do while waiting, and the older kids something to laugh at.
Reminds me back in the day using a file sharing/community program called Caraccho (for Mac) - similar to Hotline. Often people would queue up on someone's server (running of their desktop computer) to download a file since the server admin could set how many concurrent downloads from all users were allowed. Folks would send messages to people saying that if they hit Command-Q it makes the client run in "quick mode" which will speed up their download. Of course some folks would fall for this and you'd see their name drop off the server, moving everyone up 1 spot in the queue. Super effective for users that had not setup an avatar indicating they were new to the system and would fall for anything once.
I'm confident that the Alt+f4 cheat-code was around before Runescape ;) It was inevitably told to every new member at our LAN parties in the late 90s - the few who knew were often assigned admin duty to diagnose network/PC problems (which were frequent).
> Reminds me back in the day using a file sharing/community program called Caraccho (for Mac) - similar to Hotline. Often people would queue up on someone's server (running of their desktop computer) to download a file since the server admin could set how many concurrent downloads from all users were allowed. Folks would send messages to people saying that if they hit Command-Q it makes the client run in "quick mode" which will speed up their download. Of course some folks would fall for this and you'd see their name drop off the server, moving everyone up 1 spot in the queue. Super effective for users that had not setup an avatar indicating they were new to the system and would fall for anything once.
This was also common on IRC to get script kiddies to kick themselves.
It is perhaps more appropriate to say the button frequently does nothing because you frequently lack the proper permissions... https://youtu.be/ZUvGfuLlZus
In my day, they told new people that Alt-F4 made all kinds of programs run faster, unlock cheat codes, etc. Especially the online games. You always knew the adventurers when you saw "has disconnected from game."
I definitely remember seeing scrolling-is-faster-if-you-wiggle-the-mouse on Linux too, back in the day, and being surprised that a bug (? misfeature?) like that would show up on such different stacks.
Back in the day it wasn't a bug, but rather more of a cheat to make your system feel faster than it really was: if the system actually gave the UI a fair share of CPU cycles, the system would feel incredibly sluggish. Conversely, if it gave the UI the lions share of CPU, nothing would ever get done in the background. So it compromised and gave the UI preferential treatment when the user was active (i.e. when there was recent mouse/keyboard activity), and a more fair allocation when they weren't so other things could get done.
One thing that also worked was to open and close the CD-ROM tray. It felt like HDD was waiting for something that open-close action on the CD-ROM drive would trigger some reaction.
We were doing some processing on a database and updating the progress bar every record. We processed the UI messages at that point as well so any click on Cancel could get through.
As customer databases grew, the processing began to exhibit this behaviour.
If I remember well, we fixed it by only updating the progress bar every 1%. It may have been more complicated than that though, I had moved on to another job when the fix was done.
So in today's world... why do so many PCs emit a slight sound when moving the mouse. I know that there are high frequencies involved and periphery is one of the worst perpetrators of electromagnetic interference, but I still find that strange. And what exactly is emitting the sound here?
Generally it's cheap/poorly designed audio amplifier circuits. Even though modern PC audio is mostly digital, the final stage (getting sound out the speaker) is still analog. If the motherboard designer isn't careful about how they place/isolate/ground the analog audio circuitry, it can pick up some of the PC's stray high frequency noise which gets worse the more you turn up the volume since now the noise gets amplified too.
A work around if you have a motherboard that is particularly bad about this is to use the digital audio output (S/PDIF via an optical or RCA jack) to connect an external amplifier or you could stream it via software. This tends to only be an option if the machine is stationary and not terribly realistic for people with a laptop on the go.
You're assuming a precision in their post that I wasn't (i.e. that it's actually coming from the PCB, rather than 'the collection of parts called a PC sitting in front of me'... which would include the speakers for most people)
> You're assuming a precision in their post that I wasn't (i.e. that it's actually coming from the PCB, rather than 'the collection of parts called a PC sitting in front of me'... which would include the speakers for most people)
For what it's worth, this _is_ hacker news. I concede not everyone is tech savvy but I tend to respond to comments as if they are.
i used to have an obsessive habit of right-clicking the desktop and selecting refresh. took me ages to exorcise that out of me when i switched to a linux. i remember not liking that it didn't have that option.
I remember that with Windows 98SE, when it got stuck most of the times you can make it come back to life again by opening/closing the CD tray a lot of times...
Wow, I always moved the cursor over the progress bar as I believed it made the installation go faster, but I never had actual proof. I guess I wasn't the only one.
200 comments
[ 14.8 ms ] story [ 513 ms ] threadTold my IT friend who was loading my machine and he said "you're confused; I've installed hundreds of times and never seen that". So I turned his mouse upside down and waited. Voila! It hung.
Guess I owe my dad an apology now.
- Open Office won't print on Tuesdays: https://bugs.launchpad.net/ubuntu/+source/cupsys/+bug/255161...
- Can't send email more than 500 miles: http://web.mit.edu/jemorris/humor/500-miles
----
An odd feature of our campus network at the time was that it was 100% switched. An outgoing packet wouldn't incur a router delay until hitting the POP and reaching a router on the far side. So time to connect to a lightly-loaded remote host on a nearby network would actually largely be governed by the speed of light distance to the destination rather than by incidental router delays.
Feeling slightly giddy, I typed into my shell:
$ units 1311 units, 63 prefixes
You have: 3 millilightseconds You want: miles * 558.84719 / 0.0017893979
----
But surely for Sendmail to register a "connect" with a remote SMTP server would require at least one (or many?) round trips to the remote server, so one-way speed of light time doesn't seem like it would really be relevant. Am I missing something?
"The story is slightly altered in order to protect the guilty, elide over irrelevant and boring details, and generally make the whole thing more entertaining."
If memory serves he goes into further detail about the alterations and some common objections to the story in his FAQ:
https://www.ibiblio.org/harris/500milemail-faq.html
Makes sense, I can share this story to people without any computer knowledge, but something explaining how connections are established would be wholly incomprehensible to them.
MS Word was one of the few ubiquitous tools that would compress images, and certainly one of the few that people could be counted on to know. MS Paint didn't support PNG until Win98, and even then wouldn't do it by default.
If you didn't go via Word, chances are you'd be emailing a 900kB BMP at a time when people used 28.8k modems to access Hotmail accounts with 2MB caps.
All these years I've been wrong!
This is a problem for NTP developers - finding real serial ports on modern hardware
4 channels realtime audio + 5 osc's on a 286 out the PC speaker. Phenomenal. Sounded like shit until I got a Sound Blaster, though....
If I moved the mouse the HDD would spin furiously but once the mouse stopped it would resume trickling the writes/reads again.
But I remember the times when that blog didn't look like a webdesign internship project in progress. And there were interesting comments…
https://devblogs.microsoft.com/oldnewthing/?p=36423
“One danger of the MsgWaitForMultipleObjects function is calling it when there are already messages waiting to be processed, because MsgWaitForMultipleObjects returns only when there is a new event in the queue.“
I too witnessed the 'windows is running slow when installing' bug. I often would use the mouse cursor to 'mark' the position of the loading bar (we really are spoiled for speed these days). That way when I would walk-away from an install I could see if the progress meter moved while I was away. More often then not the progress bar would still be where it was when I had left. By moving the mouse activity would return and the installation would continue.
I always assumed it was the graphics that were not being updated. A small bug with the install would keep running but the lack of input interrupts caused the display to get 'stuck'. (That would explain the sudden 'jump' in progress bar movement as soon as I wiggled the mouse.)
But what newbies will bever know the heck of: dip switch settings for IRQ for modems.
Thats what literally got me into computers...
In order to dial up BBSs and play tthe Pit and dl warez.
—-
Ive told this story before, but in about 1992? Or so - i got grounded for a month because i had been calling in long distance to a bbs in san jose to play the pit - and racked up a long distance bill of $926 - my dad was livid.
He yelled at me and said “why are you wasting all this time with computers! Its never going to do anything for you!”
Years later after i became successful with yee olde computerz! He apologized to me and said “im sorry i yelled at you for that time you cost me all that money in long distance charges.”
Were you also calling into PCLink?
I used to have a challenge with my best friend at the time:
We used to call 411 and challenge to whom could keep the 411 operator on the phone longest.
I had this problem until I discovered a bug in a Major BBS door game (TradeWars 2002) that let me have unlimited BBS credits. No more charges on my moms phone bill and even was able to trade those for other things in real life. Early bitcoin in a way. Looking back on it, my need to get online overrode my ethics regarding either my moms bank account or the sysops running the BBS. Oh well.
And it was a summer month long binge on PCLink and BBSs...
(I later convinced my highschool to install a CAD network on which we installed a BBS Called Heaven and Hell and ran a warez site from there....
Fun times.
EDIT: Oh -- and it was run on an EverexStep Cube machine... I think it was a 386?
At which point you lit up your Havana Muy Gordo with a $1000 bill and said, "Don't sweat it?"
. .
[1] somehow just before college I got a used USR Courier HST. Then I sent it in with what was probably all of my hard earned beer money for upgrade to a Courier v.Everything... I still have that one, found it while moving https://v.gd/gF83mM)
And dip switches to set hard drives to primary/secondary. Get that wrong and your machine didn’t boot.
This is just me, oh my gosh. I thought I was the only one who did that. But now I come to think about it, it can't be true.
It has been a really long time since I used that technique last time...
Last time it was for the linux dropbox updater, last week.
I am also a fan of using another window so I can use the mouse and still have a marker to monitor progress.
Nobody ever complains if the process suddenly speeds up because progress was made before the timeout, as long as your initial estimate wasn't absurd (looks at Windows Explorer). Even a naive progress bar counting down the 60s timeout is more informative and satisfying to watch than an endless spinner.
Done in 30s ... I mean 15min ... ah, 10s ... 1hr 7min ...
Oh, come _on_ ...
It was so bad I ended up discovering Teracopy which was decent at estimation, and far faster at copying. Was a must-have until I migrated away from Windows.
1. Explorer attempts to do a file enumeration prior to copying, which sometimes could waste a lot of time.
2. It seems tools like Teracopy use buffering aggressively, which can speed up the copying significantly based on my experience on Windows XP with slow HDDs.
Are there any other points worth noting?
The other thing that I liked is it's non-blocking - you can continue doing copies while one is in progress, if it's to the same destination it gets added to the queue in progress. If different destination it goes in a new queue that waits for the first to finish.
I've seen dual progress bars: one for "overall progress" (each one of five tasks fills this bar 20%) and one for the current task (maybe downloading, maybe unpacking, maybe copying, maybe waiting for hardware to reply...)
I've been known to use Post-its and the frame of my monitor as a marker. Both are much easier with how prevalent dual-monitors are these days.
Most software doesn't feel any faster compared to Windows 95 (see Wirth's law). Also most shitware does not display a loading bar anymore, instead you get some spinning stuff that's just an animation.
In fairness, that's because users constantly complained about loading bars not being accurate (they'd freeze, change speeds, stop right at the end etc.), but having a "true" loading bar that proceeds smoothly basically requires solving the Halting Problem. So out it went.
But a few minutes later you'd be back to swap in floppy number 18
> The effect was quite pronounced; large applications that could take an hour to install could be reduced to 15 minutes with suitable mouse input.
It's not just Notepad :-) I do this often, when I have to mark a lot of things.
Of course neither of these would demonstrate the effect they were talking about.
Thank you for the tip.
Isn't it funny that many of us learned these sames ways of interacting with computers without being explicitly taught. If this were on the Internet, I would say it's a way to gauge whether you're a robot, but otherwise, it's just a measure of my impatience. Maybe it's just an acquired skill from growing up playing video games.
To this day, when waiting for some long or compute-intensive operation, I tend to instinctively move the mouse around. I guess this may be why.
Ironically, even though I grew up on Windows, I don't remember any actual case of "moving the mouse speeds thing up" on this OS - I only remember the infamous Linux cases (mouse move regenerates entropy, unblocking processes that got stuck when generating a random number call). But there must have been something, and I must have experienced it early enough in my childhood.
(Like a caged leopard or mad scientist pacing back and forth.)
I could feel how responsive the connection and emacs were over time by the delay between typing and seeing the cursor move. Both the network and emacs contributed to the feeling:
There was the overall "weather" of the network: sometimes sunny and fast, sometimes sprinkled with light delays, and sometimes stormy congestion. Then there were occasional incidents that came and went, like network hiccoughs and emacs paging and grinding. And then there was the overall load of the system, which gave you the baseline delay (which gave it a very tactile day -vs- night feeling, since you got more of the machine to yourself during the night when it felt snappy, but it felt sluggish during the day).
It really felt like either the network, emacs, or both would fall asleep if you didn't keep them warm and lavish them with attention.
A VAX 11/780 running Gosling Emacs over a dialup had a very different feel than a PDP-10 running ITS Emacs over the arpanet. The busy VAX was bursty and had a lot of bumpy paging -- you had to keep your buffers warm or they would all get paged out and it would take a long time to wake back up, but there was no network delay from the direct dialup. While the PDP-10 ran smoothly like a well lubricated steam locomotive, sometimes slowing down when busy, but hovering around same speed instead of bursting, and the delay was mostly the feel of arpanet congestion and imps dozing off.
(Or so I imagined. I had a lot of time to sit and think while waiting for the cursor to move again, and the mind wanders and wonders what's happening...)
TOPS-20 had a wonderful ^T keyboard interrupt that you could type to instantly show the system load and time. (But of course you couldn't use that in emacs, which puts the tty into raw mode.)
Somebody at the university implemented ^T to 4.2 BSD on the cs department's busy VAX 11/780, by modifying the tty driver. But initially, there was no limit to how often you could type it, and calculating the current system load wasn't a trivial operation.
So on a fast terminal, if you held down and auto-repeated ^T, it would bring the entire system to its knees, and you could watch the load go up and up and up as you caused it to! Very satisfying indeed.
Eventually they put in a one-per-second limit on ^T.
Huh. I got into that habit recently, because over the past year, I've been frequently working on the go, by SSH-ing to my home desktop and using Emacs terminal frame (emacsclient -t)[0]. I do regular "weather checks" with ^A and ^E - because the hardware has its weather, SSH has its weather, and the link I'm on has its own weather too (particularly when using an LTE hotspot, though I've noticed even when being in the same LAN, the response time is not always consistent).
What's old is new again :).
--
[0] - With terminal emulators supporting 256 colors, it looks very similar to the GUI Emacs. This mode of working is really quite good, and lets me use my underpowered sidearm 2-in-1 tablet/netbook to do things that would ordinarily require powerful hardware.
After a million or so keystrokes and feedback delays, your brain can't help but build a model of what it means.
> Huh. I got into that habit recently, because over the past year, I've been frequently working on the go, by SSH-ing to my home desktop and using Emacs terminal frame (emacsclient -t)[0]. I do regular "weather checks" with ^A and ^E - because the hardware has its weather, SSH has its weather, and the link I'm on has its own weather too (particularly when using an LTE hotspot, though I've noticed even when being in the same LAN, the response time is not always consistent).
You may find mosh [0] to be useful, as it buffers input client side to remove input lag.
[0]: https://mosh.org/
You can test it by running `ed`:
Running `stty -a` lists all of the characters that have special meaning when the TTY driver handles input this way, before the program sees it.macOS has this too!
This happened if you kept the mouse just inside the window and moved it about 10-20px up and down in/out pf the window in the direction of the selection.
It was a way for me to scroll faster than with the wheel or cursors on web pages if you selected some text and then kept the selection on the end of the screen and moved the mouse wildly in the edge of the screen.
As I was younger then, there was probably a better solution to do this but I was not aware of it.
Not sure what the current status quo is.
But scheduling happens far more often than this tick rate, too, so it's only preemption for busy threads and controls the timing windows for things like DVFS.
One of the older kids who hung out there would tell us newer kids that we could speed up loading by repeatedly pressing the up arrow key on the keyboard.
Of course us new kids didn't realize that the loading speed was completely determined by the cassette tape speed, which the keyboard couldn't possibly affect.
But at least it gave us something to do while waiting, and the older kids something to laugh at.
This was also common on IRC to get script kiddies to kick themselves.
We were doing some processing on a database and updating the progress bar every record. We processed the UI messages at that point as well so any click on Cancel could get through.
As customer databases grew, the processing began to exhibit this behaviour.
If I remember well, we fixed it by only updating the progress bar every 1%. It may have been more complicated than that though, I had moved on to another job when the fix was done.
A work around if you have a motherboard that is particularly bad about this is to use the digital audio output (S/PDIF via an optical or RCA jack) to connect an external amplifier or you could stream it via software. This tends to only be an option if the machine is stationary and not terribly realistic for people with a laptop on the go.
For what it's worth, this _is_ hacker news. I concede not everyone is tech savvy but I tend to respond to comments as if they are.
> https://en.wikipedia.org/wiki/Electromagnetically_excited_ac...