In Stockholm (where I lived), the recommendation was to work from home if possible. My workplace had had >95% of staff working from home from the beginning of march. Most of my friends here, except for those in healthcare or education, faced the exact same situation. So, institutions did keep people at home if possible, and companies did too.
Politicians tend to be shortsighted (reelection, next term). That's partly why not enough has happened (or will happen, under this political paradigm) when it comes to the environmental issues our habitat is facing.
I used, and selfhosted, TT-RSS for a long time but eventually gave up due to it braking at almost every update. I was furious.
So I found and tried FreshRSS. I have been using it for years now, without a single hitch. I always chose apps that run SQLite over full fledged DBs these days. So much easier to manage, migrate etc.
Inter is almost as good as Apple's SF, and with a much more permissive license. It's my default when designing apps for the web.
I used to default to "system font stack", but that was always because SF is such a great font. Defaulting to Ubuntu font on Ubuntu is... unfortunate. Luckily, Inter is fantastic, and it can be fantastic on every OS.
I almost went with MediaWiki, but ended up with DokuWiki. The fresh install of MediaWiki is 154 MB (!) and it's not exactly lightweight. DokuWiki is 10.9 MB and all content is saved in plain text files. Very attractive.
However, backlinks are not possible without hacks. A wiki without backlinks is kind of lame and I could very well use my good old plain text files.
What do you mean by backlinks are not possible? Do you mean in DokuWiki? Each page has a "What links here" button that shows backlinks - that feature is builtin.
https://tiddlyroam.org/ is another alternative, but Tiddly* kind of feels like a dead end. The big upside is the lack of dependencies (just a file), but when the wiki grows you soon have a 70 MB html file that kills your browser. I know there's the node.js version too, but then I might as well use MediaWiki (even more portable).
Why are people overcomplicating web video so much?
With the HTML5 video tag it's not much more complicated than serving an an <img>. You still "need" two formats, I know that sucks (but av1 will hopefully become the solution). A small to medium sized blog can just upload the files to shared hosting (or even archive.org if space is sparse). No JS, no CDN needed.
If you want your content to be accessible for most people you also need to transcode your video to several resolutions. This coupled with an adaptive bitrate player [0][1] will allow clients to choose the resolution they can afford (so that people with different bandwidth can access your content)
When dealing with more than 10s or 100s concurrent viewers the required bandwidth on your server will be high and putting a CDN in front may be required.
It depends on your market. If you're aiming for people at home in Seoul, yeah that's probably alright. Their connection should be great and stable. If you're aiming at people transiting in Mumbai and watching stuff on their phone in the local train, 720p won't do.
I was referring to (small and medium sized) personal blogs and websites (like the one in this post), i.e. not a digital commodity on a market. If you're out there to make money I realize you have to be more fancy with what you put out there.
Great question, it's actually not quite that simple. HTML5 was indeed supposed to bring trivial video to the browser, and it almost did.
If you want a good video streaming experience for all your viewers, you need something called Adaptive Bitrate (ABR). Some protocols that you may have heard of the implement ABR include HTTP Live Streaming (HLS) and MPEG Dynamic Adaptive streaming over HTTP (DASH).
ABR allows the stream to adapt to the bandwidth capabilities of the viewer. If you don't do this, some users will experience buffering, and some will have to sacrifice on quality.
Unfortunately most browsers don't support an ABR format natively, so you need to use Media Source Extensions, and a more complex player to support these protocols in a browser.
Well, I don't know about you, but sometimes I'm on a 3G network. Yes, I could wait to get home. But some people also have really terribly bad providers offering them very little bandwidth.
So, by doing this, you make sure your content can reach more people. Which, to me, seems to be the whole point of making and putting it online in the first place
Of course, but there are instances of the opposite. I encounter both from time to time. For example I want to show someone a video while having a drink, usually it doesn't have to be crisp 4K 60fps, just play the god damn thing before we lose interest. Other times I want to watch a video, I'm in the middle of nowhere anyway, I have time and data in the monthly cap, just not enough bandwidth.
User choice and smart defaults would go a long way.
Well, people do expect YT/NF level. And sadly we've trained everyone to expect that everything starts playing instantly.
So if your income depends on people not rage-quitting your page, you'll have to provide something that satisfies their "needs", or more appropriately "desires".
I'm not saying people shouldn't do more for user experience, but the cost-benefit seems to be bimodal. Do the minimum, or pay YT/NF/Vimeo (or CF or AWS Streaming, or get ready to bankroll your own).
It is by no means a clean or modern solution (I agree, go with Youtube etc or provide a transcoding js player), but about a couple decades ago many sites would simply link to several resolutions of a video, allowing the user to play either a low, medium or high res version as per their current data connection. So that is one option that sidesteps adaptive bitrate players as well as a large CDN.
As has been pointed out above, having some kinds of video downrated to be streamable on 2G isn't much different from not having the content at all. While 4K is rarely required, pushing out coding tutorials at any resolution below 1080p is nearly worthless, and pushing it out at 480p is worthless (Unless it's a retro C64 BASIC tutorial in which case rock on).
Work... Yes, you can watch a video fluently, but it takes (on Desktop, Firefox, with Throttling on "Good 2G") maybe ~2min to load the video page. However, you can start watching the video before the full page is even loaded.
You can probably implement a dumb version of this where transcode a few different versions with ffmpeg (which is amazing, but takes some tinkering), use browser API's to guess the right one as a default, and give the user control if they'd like to switch.
I'd still try HLS but this may be good enough for v1, depending on what you're building.
Around the 1:14 mark he goes into why you can't just use the html video tag. It was one of the best explanations I've heard around HLS and what it takes to stream video efficiently.
It's easy if you want to serve the video as it is but usually that's not what you want.
I have Plex (like a self hosted Netflix) on my home-server and some other people are also using it and on many different devices and connection speeds. It has to transcode the video on the fly and cache it depending on the client to have a good experience. You can't just serve 4k video to everyone.
