lrizzo
Joined 16 years ago
Karma
401
Submissions
51
Member since
Jan 6
Recent submissions
Comment · 3 months ago
same as in real life?
Comment · 5 years ago
I think there are two different use cases:
- 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
Comment · 6 years ago
Almost 10 years ago I wrote sttp
http://info.iet.unipi.it/~luigi/sttp/
plain javascript + markdown variation, allows receivers to sync with the presenter using AJAX (that was the name, at the time ?) long polls.
20 years ago I extended Magicpoint to send (and receive) content and commands over RTP
30 years ago... I still used a overhead projector.
I realize it's been 10 year since I last worked on the subject, and this days I use a mix of high tech and low tech solutions
Comment · 6 years ago
>> "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 ...
http://info.iet.unipi.it/~luigi/wb/
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.
Comment · 6 years ago
I believe it is either "force portrait" or "autorotate", there is no "force landscape".
Comment · 6 years ago
I have two links related to tiled window management:
The links are for WM configurations that let you move or resize windows keeping the corners on a configurable grid:
[1] https://github.com/luigirizzo/lrtile-chrome (chrome extension) Ctrl+Shift+Arrow move the current window, Ctrl+Search+Arrows resize it
This works for all Chrome windows so it platform independent.
(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.
Comment · 6 years ago
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.
Comment · 9 years ago
To be precise zfec uses Vandermonde codes and it is derived from my old fec library from 1996-97. See http://info.iet.unipi.it/~luigi/research.html#fec (in 90's web style).
Comment · 9 years ago
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.