If you're interested in seeing a use case of the APIs, there was a really cool talk at Demuxed last year where some folks built a compositor using this plus canvas[0]
HN user
Everlag
There is an art to the creation and maintenance of suspense.
Engineer at Cloudflare doing video things.
Email is at github.com/Everlag/
ExcessiveLag on twitter
topcolor: dfcdfc
[Disclaimer: opinions expressed in comments are my own and do not necessarily reflect my employer's stance or non-stance on any specific issue.]
nebula[0] may be interesting; you can allow list connectivity for specific groups, all burned into the cert used to join the network. It uses some NAT hole punching orchestration to accomplish connectivity between hosts without opening ports.
The main painful thing I've found has been cert management. PKI, as usual, is not a solved problem.
I've managed to do some fun stuff using salt + nebula on the hobby side.
That's such a different approach than I've grown used to, but different platforms encourage different flows.
I've been using bitbucket (not the shiny nice new bitbucket) at work for years and its PR search is so abysmally bad that anything in the PR message but not in the commit message may as well not exist once its merged. `git log` is forever, bitbucket search is /dev/null
I'm curious what other affordances or lack of affordances encourage what git behavior.
Honestly, RTMP is a workhorse that powers most live video ingest today; its not bad, its just mostly frozen in time. Some issues that came immediately to mind are:
- It was developed to support flash; if anyone is sending metadata about the data streams are probably serializing flash objects, which is truly an experience when writing go.
- The supported codecs are limited and the spec provides no generic way to extend it. If you want h264 and aac, RTMP is great. If you want any codec developed after that, you need to either reach for another protocol or use a non-standard extension to RTMP whose support across different providers is flaky.
- Its TCP under the hood and that locks you to a fixed reliability/performance tradeoff.
- The 'spec' is a document released by Adobe which is not particularly great, falling pretty far short of what we'd expect out of the IETF or similar. Its overly detailed in some areas and woefully under detailed in others.
- RTMP isn't particularly tune-able; if you want to tradeoff latency for quality or similar, you're exploring the dark depths of the protocol.
None of these are damning but, as an aggregate, they go a long way to encouraging new protocols to be developed which avoid these issues.
> What problems do you have with "maintaining an RTMP stack" does any of these newer protocols alleviate? What do you mean exactly by RTMP stack so I can be sure I understand you correctly?
Maintaining an RTMP stack, at least for me, means making sure your implementation of underspecified RTMP works with other, third party implementations of underspecified RTMP. Some implementations are great(ffmpeg and OBS) whereas some will send you timestamps that oscillate between the correct time and 3 billion seconds in the future; or, they'll send you exactly 3 packets at the start of the connection with timestamps far off in the future. More subtly, some providers want you to send a packet when you're closing the connection and others just want to go away and get angry if you send them a 'goodbye' packet.The current state of media ingest protocols is actually getting interesting. For quite some time its been a situation of 'everyone supports RTMP so you support RTMP' plus 'vendor X does not support $FANCY_NEW_PROTOCOL but they do support RTMP'.
Now we've got this fun competition between various protocols at different stages of their lifecycle. Some are SRT where one vendor is pushing them quite hard and support is flakily available but not everywhere. Others, like WHIP, are much earlier in their lifecycle.
Most new protocols support carrying more codecs without gross hacks and generally are much nicer than an early 2000s protocol which hasn't really ever had a canonical specification; beating RTMP is a somewhat low bar. Each one also has their own shiny ribbons like using QUIC/webtransport or very-low latency.
The next few years will be interesting to see which gets adoption and which get dropped at the wayside. Could be any of the current contenders; I'm just hoping I can stop maintaining an RTMP stack sometime before 2040 without suffering from extreme fragmentation.
I would be surprised and saddened if `?` as described in the blog was added to go. Error wrapping is critical for operating a service and staying sane; an operator encouraging `if err != nil { return nil, err }` is a step backwards.
Consider this situation(it may sound familiar): you get paged at 4am for 500s from a service, check the logs, see 'file does not exist'. go doesn't attach stacktraces to errors by default. go doesn't enforce that you wrap errors with human context by default. How do you debug this? Pray you have metrics or extra logging enabled by log level that can give some degree of observability.
This error could have been 'opening config: file does not exist' or 'initializing storage: opening WAL: file does not exist' or even just decorated with a stacktrace. Any of those are immediately actionable.
Now, if go decided to make error wrapping a first class citizen with a fancy '?' operator, I'd be excited. However, I doubt that will happen because go is definitely not rust-like in its design.
Heads up for anyone reading this on chrome, the examples may not render with a `Cannot read property '_gl' of null` exception; firefox worked fine when I tried it.
Stream currently supports VOD delivered over HLS/DASH. We'd like to explore live in the future.
My team agrees with you :)
https://developers.cloudflare.com/stream/
Happy to take any critique y'all may have.
If you want to avoid the 'this chrome extension has been sold to a malicious actor' fiasco that hit me with the Great Suspender yesterday, you can load this as an unpacked extension.
Grab the zip from github, unzip it, and point chrome to it as an 'unpacked extension'. Works perfectly and takes 2 minutes.
The github is here https://github.com/tom-james-watson/old-reddit-redirect
You lose automatic update but that's a feature in this case.
Aye, this is the 'Cryptograph Doom Principle'[0].
To very lossily summarize: always authenticate before looking at the message.
Its a handy rule of thumb when you're making choices like how to validate a message.
https://moxie.org/2011/12/13/the-cryptographic-doom-principl....
This labels itself small but, honestly, it feels too small. Why would I introduce a dependency that I can implement in 5 minutes from first principles?
The entire implementation essentially lives in atom.ts[0]. Its a class that has an array member and a for loop. It does handle async code for you but, I don't know, I'm not convinced.
I would love to know the intended audience for this package, since its seemingly not me.
[0] https://github.com/lucialand/luciex/blob/main/packages/core/...
If you want to do fun things with ffmpeg as a cli, most roads end at filter_complex[0]. You can get some truly impressive results at the cost of maintaining really intricate commands. There's also added value when onboarding a new teammate and seeing their eyes open when they find some of the commands you maintain...
Once you grok filter_complex, it becomes a lot easier to understand how people get very complex results out of ffmpeg.
Of less renown but worthy of a mention is the tee[1] muxer. It lets you take the same resulting input and pass it to different destinations. Incredibly handy, ie, for outputting DASH, HLS, and a regular ol mp4 from the same command WITHOUT having to redo the scaling or anything else that was in the filter_complex.
[0] https://ffmpeg.org/ffmpeg-filters.html#Filtergraph-syntax-1
[1] https://ffmpeg.org/ffmpeg-formats.html#Examples-12 (links to examples which is where you should start, scroll up to see docs)
I am curious how many people mock their SQL queries and how they decide to mock vs not mock at that level.
From the perspective of the services I'm knee deep in at the moment, SQL feels like the wrong layer to mock at. Instead, when we do want to mock, we usually pass around mocked out data access objects. That way we work at the application layer of `GetN` rather than `SELECT a, b, c FROM N`.
It feels like a lot of the value of the tests we write that do execute sql is a result of them actually running it. Granted, it is slower than mocking, requires synchronous rather than parallel tests, and we need to wipe the impacted tables for every test. However, the value we get is that we know that a query actually has the intended semantic.
I'm obligated to mention xmage: http://xmage.de/
Think cockatrice that trades ergonomics for a rules engine. Much easier to play when the game just 'works'. It even has loop detection for when you go infinite with triggers.
One thing to note is the community run servers are plagued with performance hitches at peak time. If you play regularly on xmage with friends, I'd recommend making an image on your preferred VPS provider and spinning up an instance when y'all want to play.
The first book has context that I'd say is required to fully enjoy the third book. So, second->first->third->...
Most the downside of the first book is the quality of the writing; it was written before author really nailed the formula. If you like the second book, the first book will be fine because you get fed more nuggets of information about the broader setting.
Most good rules always have an exception, Malazan[0] is a fun set of exceptions to these.
If you're not familiar, Malazan is a series of high fantasy novels and they're quite good. Well, they're excellent apart from the first book which is usually what kills the series for people. Just start on the second book if you're interested in trying out the series.
Malazan started as a setting from some campaigns and grew from there, so this feels pretty appropriate to bring up.
- It has an absurd number of characters. On your first read you will lose track of who Widdershins is. Hell, between books you'll probably forget who Bottle is. This is a listed of named characters[1].
- A bunch of events that happen in earlier books don't make sense at that point. The setting slowly unveils its magic system and world between each books. By the tenth book, most things that were confusing are justified.
- Character motivation is usually upfront except for a few characters that define the majority of the plot's direction. Those characters are complete blackboxes. Some of those are viewpoint characters that become non-viewpoint characters.
- Jokes are sometimes appropriate in even the worst situations because its appropriate to that set of characters.
[0]https://en.wikipedia.org/wiki/Malazan_Book_of_the_Fallen [1]https://en.wikipedia.org/wiki/List_of_Malazan_Book_of_the_Fa...
Is the value proposition here the CSS performance benefits of shadow DOM without needing shadow DOM? If so, its surprising there's no direct comparison in the link.
I could actually see this being pretty compelling for easy performance wins. Its much easier to adopt a single CSS property versus a different model for DOM interaction. The churn in the spec and various implementations didn't help shadow DOM adoption at all.
Its 2020 and I've been using shadow DOM(plus web components) for 6 years in side projects. When the stack has native support its great; it runs fast and is a pleasure to develop. The downside is you have to be willing to swallow polyfills that degrade performance when you don't have native support.
If 2020 isn't the year of shadow DOM, maybe 2022 can be the year of shadow DOM polyfills that don't ruin performance.
I've been there, I've got a bunch of entries that summarize to 'Bleh day'. For me, though it may differ for others, those entries are useful. They let me notice that something is off and help me figure out if there's a pattern.
I completely agree with taftster in a sibling comment.
The referenced idea of a 'human log' is great[0]. I started doing something similar 4 years ago and it eventually evolved from per-project notes into a full diary. Being able to search for 'August 24 2016' and know exactly what I did that day is quite powerful.
I encourage anyone to take 10 minutes(or 30...) at the end of the day to write up what they've done. Just a text file with minimal formatting has scaled to 2.6MB of hand-typed text. Though, after a bit, I've tended to shard out specific long-running topics into their own files.
Without looking at the code, it looks like its using a steering algorithm[0] to move a series of 'boids'(each individual stroke) along the path you define. A boid is controlled by a number of forces, as in the physics sense. By varying starting conditions for each boid, you get the dispersion that is seen on all figures but straight lines.
If you take a look at the options(hamburger menu in the top left) you'll see a bunch of options. For example, 'maxForce' is the maximum magnitude of force that can be exerted on a boid for a period of time; this is noticeable if you draw two large 'C's, one with maxForce at min and one at max. I'd recommend cranking up 'boidSize' if you want to get a clearer idea of what's an individual boid is doing.
Steering behaviors are used in a lot in games. For example, A* will give you a great path that looks terribly robotic. Using a steering behavior, perhaps 'seek' towards each path node then 'arrive' at the end of the path, you get significantly more organic movement.
For those looking, here's the full anandtech review that also came out today. [0]
@dang maybe change the link as the review is a superset of the announcement.
[0] https://www.anandtech.com/show/12670/the-samsung-970-evo-ssd...
From diving in, it looks like the contract backing a smart wallet implementation had a vulnerability/bug/design flaw allowing an arbitrary actor to kill it[0]. It looks like these contracts are treated as a shared library so the contract being killed means any wallet depending on it is bricked.
The solution here seems to be a hard fork of Ethereum to allow revival of that problem contract. This seems unpalatable as, well, avoiding extensive human intervention is a key idea in cryptocoins.
Disclaimer: I got off the cryptocoin train awhile back so if I've mistaken anything, please point it out.
For those not following the consumer SSD market closely, this is a bit of an upset. Previously, Samsung was king and basically unchallenged on price/performance for mainstream and high performance loads. Now we've got Western Digital, previously seen as a spinning rust king with an SSD side business, coming in and making an extremely competitive offering. While they're not strictly better, they're the best the market has seen from outside Korea or Intel.
If you want to quickly get the long-short of the review, check out the 'Destroyer' benchmark[0] and the price/gb chart[1]. Though I recommend reading the entire thing, anandtech reviews are a treat.
[0] https://www.anandtech.com/show/12543/the-western-digital-wd-... [1] https://www.anandtech.com/show/12543/the-western-digital-wd-...
This is a well known edge case of Merkle trees; my undergrad security course covered this as an aside and it is prominent on the wikipedia page.[0]
For those not familiar with the specific implementation issue, this post should be a fun read.
I don't know what's more concerning, that pymerkletools advertises itself for use with Bitcoin or that none of the contributors read the wiki page :|
[0] https://en.wikipedia.org/wiki/Merkle_tree#Second_preimage_at...
As someone at the end of their undergrad, I have to agree that group based projects trend towards being unpleasant. The article describes the distribution of work harming full understanding of the content when all people contribute, however that's usually the best case.
Most students are oversubscribed with four or five classes. There tends to always be some portion of a group which contributes trivially or simply doesn't. When you've got a group of five, one is typically unreachable, apathetic, or just exhausted. Pairs are a gamble, a bad partner being a massive workload. When you're the person who's carrying the group, you usually end up grokking everything in the project because you touched all of it. However, since you touched all of it, you're exhausted and likely pissed.
What I've found works is individual work sample projects, particularly those timeboxed to 'hopefully a lab period but you have a week'. The GPGPU course at my school has labs which are 'fill in the blanks' for cuda code. As the course goes on, those blanks get progressively more complex and make you flex your core understanding of the course. For more theory driven courses, the standard set of assignments works nicely.
As an aside, group projects seem to be partially motivated by the TAs and profs trying to deal with larger class sizes. Taking a senior level graphics class with 30 people lets you write 4 gnarly opengl projects which the TA marks in depth; a software engineering course with 200 people, a weekly deliverable, and 5 TAs? Dividing that by 5 is more realistic.
(For context I go to a school not known for their undergrad CS program; experiences may differ in other institutions)
(Context: I'm here late into the conversation and after the title was changed)
When you consider github.com/foo/bar you see that foo has established a reputation by developing code for third party use. Can foo break upstream builds that rely on HEAD? Absolutely. However, given that foo has a reputation for high quality content is it likely for them, barring an exceptional event, to insert malicious code? Probably not.
The issue I have with github allowing username reuse in a broader context is that the reputation from a trusted user is transferred to a third party. That third party could be neutral, well meaning, or malicious. All the same, they should not be able to take the reputation developed by that user. In this example, if foo decides to become a bespoke tailor and deletes their github, someone should not be able to use their reputation.
In the context of go using urls as canonical locations for code, is it smelly? Oh yeah. Does that mean that username reuse isn't a problem? No. A lot of people here are pointing at either go developers or github. You can blame both and eventually get a robust solution from both.
If you're looking for a quicker summary of what's happening, there's a write up on r/cyberpunk[0] that was posted 3 days ago. There's a very specific flavor to the subreddit and the comments on that write up that might be satisfying for those that appreciate cyberpunk.
If it wasn't immediately evident, this is very NSFW.
From the perspective of a CUDA beginner, this doesn't seem simpler than writing CUDA with C(not C++, just C). If you're going to pick up CUDA, starting with C means you get the best tooling support and community docs. Not to mention that managing pointers and explicit types in C will genuinely help your understanding of how CPU-GPU works.
If you already know Clojure, this is probably the best chance to extend something you already love using. If you don't, you're probably better off learning either CUDA or Clojure rather than both at the same time. Debugging CUDA errors are already painful, I wouldn't add a new host language on top of that.
For context, I'm currently taking my school's GPGPU course. We've just started actually writing non-trivial code.
I just finished up a senior Computer Architecture class last term and a flavor of this was a popular question for past exams.
For a more fun answer than an exam, consider that the real estate on a CPU is typically dominated by two things, cache and out-of-order speculation hardware(predictors and such). Then, turning off speculative execution would be like turning off a third of your CPU. As to the actual performance impact, it'd be massive. There's a reason why no modern processor is in-order.