- measurement at thread level (top and the like) should report
instructions retired per unit of time, not %CPU.
We want to know how much work is being done.
The explanation on why so much/so little requires more information
(scheduler? cache misses? cpu throttling?)
- measurement at the CPU level (mpstat, etc) should report
both %CPU (as "time active" vs "wall clock time") and
active clock cycles per unit of time
(dividing by clock stretching factor if used, and
perhaps scaled to absolute max frequency and/or %CPU
if one wants a percentage).
%CPU tells us whether we are making full use of the available time,
and perhaps suggests to schedule threads differently if appropriate
Clock cycles tell us how much one CPU is affected by throttling
(manual, automatic, due to C-state exits, etc), and this is an orthogonal
indication on whether there is something at the system level that is
making the CPU underutilized
>> "With so many people and students around the world working from home, we really need some easy to deploy shared whiteboard solution. This is especially important for pre-college students who may not have access to high end hardware."
>Just add a new mode to videoconferencing, where both parties get a white screen and both can start drawing and the resulting image stays in sync on both clients? (I feel like this solution is so obvious, I'm about to fly out a window - what am I missing?)
Author here.
There have been a few proposals in this space for the past 25 years including hangouts extensions, using a virtual camera that just exports the screen (if people remember the old mbone tools wb and vic; I myself wrote an extension to replace the camera with a snapshot from a configurable region of the X screen), and my own shared whiteboard which gives parties a shared screen that they can edit modify replay ...
There are two main reasons (in my opinion) why this space has been neglected:
- almost nothing matches the convenience, speed and _resolution_ of writing and drawing with an actual pen.
Pads with sufficient resolution and decent lag are only appearing now, and they are fragile and expensive.
Graphic tablets are cheap but lack the visual feedback and looking at the output on the screen still has significant latency.
They are moderately usable, but takes time to get used to them, and you need a real 10+in screen to use them effectively.
Using a finger or a conductive pen on a phone screen is only good for small sketches, not for writing longer sentences or formulas.
- the main users of such products would be non commercial entities (pre-college schools, students) so there are no paying customers.
Even at college level lectures are increasingly based on slides prepared in advance. Businesses, of course, use slides or meet in person, and the whiteboard style of collaboration is generally done in person.
Social distancing now may actually create more use cases and perhaps returns (in terms of actual money or social appreciation) that stimulate software solutions to appear.
The Apollo13 problem still stands: even if we had good and cheap technology for writing, at this time it would be impossible to build and sell such products to customers, so we have to find solutions that use hardware already in possession of the users.
> "almost nothing matches the convenience, speed and _resolution_ of writing and drawing with an actual pen"
Absolutely agree, which is why I think attempting to reproduce that convenience on a digital system would be the wrong assumption to begin with. Pen and paper are special.
I think the issues you described in combination to the original solution I mentioned could be mitigated by dynamically increasing the image size. So instead of viewing the screen as your entire whiteboard, it grows as you add more drawings/notes to it. So for example, you have the phone and the white drawing board screen, you scribble f(x) = on the entire horizontal surface (thus circumventing the inherently low resolution issue of most touch-screens) and then the image width doubles and shifts your view to the newly created whitespace, and so on.
It's not a perfect solution, but I think it could and believe it would lead to the same desired results. It's a compromise between human convenience and adaptation to (pre-existing) physical machine restrictions.
On the topic of financing... maybe crowdfunding, then?
When my phone was updated to Android 9, that toggle became force-portrait. If I enable it now, it immediately turns back to portrait and disables rotation.
(I have a similar Javascript configuration for Spectacle, I can post it if there is interest. I believe the javascript is easily portable to other scriptable window managers.)
My rationale for developing lrtile is the following:
I like having window corners on a grid because it helps locating information.
However, in many tiled WMs, resizing one window causes resizing of nearby ones (very distracting) _and_ windows generally do not overlap (a severe limitation especially on small screen). Finally, shortcuts to place windows on half or a quarter of the screen are often built-in (in chrome, windows, spectacle default...) but very few WMs have larger, configurable grids suitable for large monitors (I use a 40" 4K screen).
lrtile addresses the above problems as follows:
- the grid is configurable;
- movement/resize only affect the current window, allowing overlap if user wants;
- commands are arrows + 1/2 modifiers, and try to be intuitive
- screen borders act as hard stops, also making behavior more intuitive.
In detail, I typically use a 6x6 grid on small screens (so I can have halves or thirds) and 12x10 or even bigger on large screens. Each window side must be at least two units, and resize extends or reduces one dimension at a time and by one unit.
My typical workflow is to make windows visible with a comfortable size and no overlap, and occasionally expand the window I care about (e.g. make the browser wider when a page does not render well; or expand the editor window vertically when I want to see a larger chunk of code), reverting back when done. The fact that move and resize commands are very similar to other cursor movements makes the operation very quick.
I have been using Spectacle for ages (with a custom javascript config, another post...).
The problem is, Spectacle uses a 32bit API that is scheduled to go away and I am afraid that at some point (or 10.15 already?) it will stop working.
Of all the problems you can have with this setting, brightness is not one of them.
I have been using 4k 40" tvs and monitors with OSX and FreeBSD/linux for over 2 years now and overall I am quite happy with the choice.
I wouldn't go much above 40", as it would involve too much head movement (while sitting at least, I find myself comfortably using only 2/3 of the height).
One annoying problem especially with older or low end TVs was definitely lag. Even after disabling all "picture enhancements" and setting the equivalent of gaming mode, many TVs in 2014-2015 had high lag, from the 120ms that even Samsung/LG were showing, up to the 300+ms of Seiki and Haier and other no-name TVs. That makes the monitor unusable even for text editing. From personal experience, 2016 Samsung at least are much better, but better try them before buying.
Next comes viewing angle and color -- cheap panels have a limited vertical viewing angle, and sometimes even limited color depth.
Then you have to fight with OS and applications. For some combinations of OSX and TVs, I had the OS applying non-removable overscan after identifying the screen as a TV. OSX also does antialiasing which results in blurred characters with small fonts in terminals. I haven't found a good bitmapped font to use.
Apps also have problems, e.g. chrome on OSX does not refresh well the bottom bar when you move windows between the 4k and the retina screen. Or, some video players fail to go full screen on 4k.
(OP/author here) I think you should have asked before changing the URL.
The original URL pointed to the correct repository and had up to date performance numbers. Now it only points to the paper which is has stale information on both. Any chance to restore the original ?
If we asked before changing every url, we'd do nothing else all day.
I've put it back to the one you want, though I'm skeptical it's a better choice. It seems so to you because you know the project inside-out, but the audience here does not. The best story is the one that explains what it is, optionally with a comment in the thread pointing to updated information.
- measurement at thread level (top and the like) should report instructions retired per unit of time, not %CPU. We want to know how much work is being done. The explanation on why so much/so little requires more information (scheduler? cache misses? cpu throttling?)
- measurement at the CPU level (mpstat, etc) should report both %CPU (as "time active" vs "wall clock time") and active clock cycles per unit of time (dividing by clock stretching factor if used, and perhaps scaled to absolute max frequency and/or %CPU if one wants a percentage).
%CPU tells us whether we are making full use of the available time, and perhaps suggests to schedule threads differently if appropriate
Clock cycles tell us how much one CPU is affected by throttling (manual, automatic, due to C-state exits, etc), and this is an orthogonal indication on whether there is something at the system level that is making the CPU underutilized