The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
Speaking of elevators, I've always wanted to ask if repeated button pushes get precedence. It would explain why when I'm standing there and the button is already lit, others feel the need to press it again, sometimes repeatedly. Do they know something I don't?
Many years ago, I was working on a timesharing minimachine (16 bits CPU, half a megabyte of RAM) serving 20 simultanous users, so the CPU was quite heavily loaded. Even a moderate size student program took minutes to compile.
Some guys (students, of course) discovered that when you hit a key on the keyboard, the OS would raise the priority of that user process for a brief period. This was to give good interactive response. If the process was still in the running state after a couple of seconds, it was probably doing some lengthy processing, such as a compilation, and given lower priority that those processes in an active user dialog.
What these students discovered: Priority was raised on keyboard interrups even when the process was not waiting for keyboard input. If they had a lengthy compilation, they could rest a finger on the space bar for a continous stream of keyboard interrupt, so that their compilation was done at "interactive" priority, pushing the jobs of the 19 other users aside, in effect taking all of the capacity of the CPU. This worked as long as you were the only one knowing this trick. Of course it leaked out, and soon all 20 users ran their compilations competing for the CPU at interactive priority, no different from when they had been competing a "background" priority earlier. But if there were one user actually trying to get some interactive work done, it was almost impossible, with heavy compilations running at the same high priority.
We reported this problem to the vendor, and in the next release of the OS, the priority was raised only if the process was actually waiting for keyboard input, not when it was busy compiling.
The students frequently commented that the OS textbook was wrong: It stated that timesharing makes it appear as if you have the entire machine to yourself (that was a common claim in OS textbook of that age). The students argued that truth is exactly the opposite: It makes you realize that you do not have the machine to yourself! The situation with you as the only one trying to edit a source file with 19 compile jobs artificially raised to the same priority is an extreme example of that.
For the elevator: Pressing again will certainly not speed up the motors pulling the carriage. If it were to have any effect, it would be because the control logic said something like: "Sure, I was on my way up to pick up that person on floor 12, but those guys down at floor 2 are nagging me so much that I'll turn around and leave that 12th floor guy to himself for a while and rather take care of those naggers".
I have never seen, or hear of, any elevator with such a behaviour. There are reasons why textbooks call one disk scheduling method the "elevator algorithm": Your arm movement (or elevator carriage) sticks to the same direction of movement as before, processing any request to the positions it passes by, until there are no more requests in that direction. Then it turns around and processes all the request up to the opposite outermost requested position. The disk arm (or elevator carriage) swings back and forth like a pendlum, serving any request to the positions it passes (those are request that arrived since last time this position was passed).
A difference from the pendlum is that the disk arm / elevator carriage does not necessarily go to the very end of their range. If there are no requests beyond floor 12, the elevator turns around there. If, a split second after the elevator has turned around, someone at floor 14 pushes the button, they will have to wait until the carriage has gone all the way to the bottom and returning back up, serving requests both on the way down and the way up. No elevator will on its way from floor 12 to 11 stop and say "We better return to pick up this 14th floor guy before we go down".
The only cases where I have experienced an elevator on the way to my destination floor stopping to go the other way is when some elevator serviceman uses his special override key to force the carriage to a specific floor. That sets the entire elevator algorithm aside, forcing one single destination floor, dropping all other requests. That is an exceptional situation. In normal operation, an elevator runs the elevator algorithm, which will not be disabled by repeated keypresses.
Surely elevators don't use state machines? The basics could be done with a state machine, but what about if multiple floors are selected from multiple people in the lift? What if I go from 2 to 20 and someone on 15 presses up? What if they press down? It's surely too complex?
Reading input devices like a mouse, keyboard, joystick - without a fancy event based framework is a good example.
Given that the hardware only gives you the state of pressed/not-pressed events like click, tap, double-click, etc. require and abstract state machine on top of the state of the physical buttons, and best of all most beginner programmers are going to understand the examples without needing any other domain knowledge.
Way back in the stone-age, I a state machine and a timer interrupt to implement a Serial port on a micro controller. Due to the efficiency of the state machine, I was able to handle 9600 baud in the background while the software handled its main task, probably driving a printer. I think that was state driven as well.
It’s amazing what you could do in lees than 4K ROM and 120 byes of Ram, including stack.
One of the big advantage of some state machine implementation is they take very little RAM.
"Time flies like an arrow. Fruit flies like a banana."
I was under the impression that Microsoft had listened to the pitchfork wielding masses and stopped the practice of rebooting your machine without warning. I honestly had.
I was in the middle of debugging some really messy TypeScript. Lots of windows open, Visual Studio debugging Chrome, Chrome debug tools, breakpoints everywhere, nothing really working properly in the debugger because I'm using vue and webpack and the .map files don't work, but it was all there. I had found the spot it was broken and was stepping through carefully.
I left the computer to take a break. An hour no more. There had been a notification about a Windows update and I'd lazily hit the "bother me later" button.
And so I come back an hour later to a freshly rebooted computer.
Are you effing kidding me?? I cannot even vaguely understand the mentality of this. Maybe if the machine was idle for 10 hrs. Maybe if I'd been warned 3 times with ever increasing levels of direness. Maybe if there was truly a security issue that was going to threaten my cat or something.
But to just reboot and lose an hour of sleuthing and setup?
A feature that is abso ing-lutely worthless, since you can't set the Active Hours to what you want. They limit it to a 12 hour period, there's only one interval, and there are further constraints on the start and end times.
In other words, it's their ing computer and they'll reboot it if they ing want to, so off.
1) You're some sort of weirdo who completely wraps up everything you were doing on your computer leaving zero lose ends before going away but is too lazy to turn it off.
2) Every piece of software you're using supports background auto-save of data and state to recover after a reboot.
I'm not sure which of those is most preposterous.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, weighing all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies.
-- Sarah Hoyt
You're some sort of weirdo who completely wraps up everything you were doing on your computer leaving zero lose ends
That's me. When I'm done for the day, nothing's running except the normal background stuff. Some of this is so that I don't have to worry about my automated nightly backup having to deal with access conflicts. The other part of it is from bitter lessons learned from applications and/or their data being corrupted from an unwanted restart.
I wish I could afford to be that tidy and close things off at the end of a day.
I can be working on many different things on any given day (and typically have to task-switch multiple times in a single day), so I would leave projects opened for weeks if I could. But reality settles in and always finds a way to prevent me from doing that.
It would only get worse if I actually started using the "multiple desktops" feature that Windows 10 finally got a few versions back. My desktop is typically a mess of windows piled high on top of each other. What helps in my case is that I run many VMs, each of which being dedicated to very specific subsets of tasks (meaning, I have a VM doing nothing but being a DC, a WSUS VM, a SQL VM, a development VM, etc...I'm done assigning completely different roles to the same OS instance). And that's me just being a home user.