Nemo157

I'm running Arch linux, I just installed kmscon and enabled the kmsconvt@tty2.service systemd service to have kmscon take over the second VT. It includes its own login manager that replaces getty. I then also login to the linux console on VT 3 and manually launch X from there (with just chromium in my .xinitrc).

kmscon has better handling for colors, fonts, etc. than the linux console; that's the only real reason I'm using it. On my laptop's builtin display I have no delay switching between any of the linux console/kmscon/X; when I plug in an external monitor I do get ~1-2 second delay switching from the linux console/kmscon -> X, no delay the other way.

There does appear to be some bug with switching from X -> kmscon, it just shows a black screen, but I've gotten used to switching X (VT 3) -> linux console (VT 1) -> kmscon (VT 2) which seems to work around that. There's also another bug where the Ctrl key seems to get stuck down in kmscon when switching to it sometimes, has only happened ~4 times in the last 8 months and I can fix it by just running `systemctl restart kmsconvt@tty2` and attaching to my tmux session again.

Since I'm not doing any frontend changes I don't ever really need to look at both my terminal and browser at the same time so haven't taken the time into seeing if I can have different VT displaying on different monitors. I prefer the portability of a laptop over having the most productive single location setup.

Latency was not at all a consideration, it was purely an exercise in how minimal a setup I could have. I spent a couple of weeks without having X installed and using command line browsers when I needed to, but using GitLab and JIRA through command line browsers was a real pain (and if I recall correctly some stuff was impossible).

A screenshot is difficult since it's multiple VTs and I don't think kmscon has any kind of builtin screenshot support. Just imagine a full-screen terminal with tmux, you hit Ctrl-Alt-F2, now it's a full screen browser; that's basically it.

One other thing I do have setup to make life a little easier are some little aliases syncing the X clipboard and tmux paste buffer so I can copy-paste between X and my terminal. And I have DISPLAY setup in the terminal so things like xdg-open and urlview can open stuff in my web browser.

I do :)

Specifically I run kmscon on one virtual terminal + tmux for scrolling/tabs, then an X server running chromium on another. I'm not a web dev, but I am continuously having to switch between the two for tracking merge requests, ticket status, testing via our frontends etc.

It's not bad, but kmscon is pretty much abandoned at this point, and I don't know of anyway to have a setup like this run nicely on multiple monitors. It was meant to be just an experiment at an über-minimal setup, I was planning to switch back to my previous i3 + st based setup after a month or so, but now it's been most of a year and I'm still using it for some reason.

I think the big thing I really enjoy about this setup is the complete lack of window management. Even the minimal window management I had to do with i3 (1-2 terminals running tmux + 1-2 browser instances) is gone. It feels like that's removed a small unnoticed stress point from my work day. If I ever get round to setting up a window manager again I think I'm going to try and keep it limited to 1 terminal + 1 browser instance and rely entirely on their internal tab support.

It doesn't sound like it's the 'serverless' hosting that is their issue, rather that they have no direct control over the endpoint that their difficult to upgrade client software is hitting. They actually fix it in future versions of the client software by putting controllable serverless endpoints in front of the firebase endpoints they're hitting, so if something like this occurs again they could just change their endpoint to not hit the third-party resource that is costing them so much money.

I was looking for a way a week ago and couldn't find it, but maybe it's just hidden really well.

> Fans won’t have to travel the globe or miss out [...] - http://thewavevr.com

> This item is currently unavailable in your region - http://store.steampowered.com/app/453000/

Really great internationalisation there. I'm guessing they're having the standard problem of not being able to get worldwide licenses for the builtin music.

A large part of the body language component is reproducible today with hand trackers + head orientation. In terms of facial cues there have been some interesting demos with gaze tracking being reproduced onto the visual avatar.

Use something like https://github.com/lbovet/typson to generate a JSON schema for your interfaces, then use a JSON schema validator before casting the API response to your interface.

I haven't touched TS since ~1.3, but this was all working well back then at least.

That does seem to be the case for me (at least on Safari 9.1); the real cursor disappears, but no fake cursor appears.

As I understand it from RFC 5077, when a client sends a session id + session ticket, a conforming server will only ever send back exactly the session id the client sent, or no session id. If the client sends a 31 byte session id, and gets back a 32 byte session id, it knows the server must be sending back some extra data (which may or may not contain any information).

If the first 31 bytes are not the same, then the server is likely generating a new session id, which is a bug but probably not leaking any information.

If the first 31 bytes are the same, then either the server is padding the session id with zeros (which, while buggy, would not be an information leak) or the server is sending back some uncleared memory. These cases could be checked by seeing if the padding is zero (which would have at least a 0.4% false negative rate with just the one byte) but the zgrab test in the article doesn't bother distinguishing them and just assumes any extra data may be an information leak.

EDIT: Re-reading RFC 5077 again, I'm not certain that the server is prohibited from sending back a new session id. If it is allowed to then the second paragraph above doesn't indicate a bug, just a rejection of the session ticket.

I very often need to change the volume while speaking to someone, I'm not certain but I think the play/pause button acts as a mute button while in a conversation as well.

IP-over-DNS: http://code.kryo.se/iodine/

Sometimes you've proven some invariant in some other way, so you know that unwrapping is guaranteed to not panic. Although in those cases I prefer to use .expect("this will not fail because of blah") instead in the spirit of self-documenting code.

I hate most implementations of those more than fixed bars, I regularly scroll slightly too far when I take a second longer to read a line than I was expecting and need to scroll back to see what I missed; then out of nowhere a massive header pops down and covers both what I was trying to read and the next 3 lines so I have to scroll back even further and any flow state is completely interrupted.

Safari on iPhone is one of the few implementations that actually works well, playing round with it a bit now it looks like it has quite a few heuristics to determine when to expand again. I guess most people don't care enough to actually spend the time adding more than just "show on drag down".

> And particularly with modern screen shapes, vertical space is at much more of a premium than horizontal space.

What? Modern 10:16 screens give more lines than 3:4. 900x1440 gets like 70 lines with 100 columns at a decent font size, better than around 60 lines with 110 columns with 960x1280.

Which is valid since this processing time will be included in whatever application the user is using to access the website.

Similarly in Safari on OS X if you force-quit or uncleanly shutdown your Mac it will restore private windows when you restart it...

Karl Schroeder's most recent novel Lockstep[1] is also somewhat related, just set within a smaller scale than most of the books mentioned so far.

[1]: https://www.goodreads.com/book/show/17910135-lockstep

Seems they don't want anyone using PIA to access their blog... Tried reconnecting and got denied again, had to switch endpoint country to actually get access.

> Error 1008 Access denied. The owner of this website (engineering.riotgames.com) has banned your IP address (108.61.57.217).

> Error 1008 Access denied. The owner of this website (engineering.riotgames.com) has banned your IP address (108.61.13.45).

I prefer JSON text sequence (https://tools.ietf.org/html/rfc7464). Self healing in the event of any corruption/parser bugs is nice, JSON lines seems like it will have issues finding a valid object start if your data ever contains new lines and you have some issue parsing one of the objects.

For smaller projects that's fine, but if you have a lot of outstanding pull requests under discussion that's a lot of continual rebasing as they each get merged. (What if the two fee fixes in the article were done at the same time and reviewed by different project maintainers?)

The Kindle Paperwhite has a very blue tinted light. I'm not sure about other lighted eBooks, but I dislike that they specifically called out light emitting vs reflective surfaces. As far as I'm aware the colour of the light makes a much bigger difference to melatonin production than the source of the light.

EDIT: Looking at the actual paper they were definitely aware of this with measurements of the colour spectrums of different tablets, unfortunately not including the Paperwhite. Disappointing journalism skewing the story as normal.