Bluetooth could work! Just need to implement the Transport interface.
Peer discovery is not implemented at the moment but could easily be added (and will be soon). Here's how: any controller can resolve EstablishLinkWithPeer. A peer discovery controller could compare the list of discovered peers with the list of desired connections and initiate connections via UDP when there's a match.
Signaling is managed by the Link implementation. For UDP we use quic-go.
This stack could be the basis of a software to share things no matter your connectivity situation.
You fire it up, it scans things around. Local network? It uses that. Not local but internet, it uses that. Nothing but BT, you can still detect people around, chat and exchange files.
People could be identified by public keys and that's it, not need for an account, signaling done by zeroconf/bt-scanning/bittorent.
Basically a solution to the current chat nightmare.
But the amount of work is overwhelming, even with this.
There is a design for routing in the repo (and tor-like circuits). However it is not implemented yet. I'd love to grow the community and have more people collaborating on this.
Just curious, what more can they do with WASM to prevent ad blockers? Can they prevent an extension that blacks out the ad and waits until it plays out for example?
They know only full SPA frameworks, they have never seen a dump of an HTTP message, headers and verbs are abstract things to them. Hell, many of them don't know you can have fully functional websites with zero JS, including payment, video, login, etc.
I started to write an HTMX tutorial (https://www.bitecode.dev/p/a-little-taste-of-htmx-part-1) because I noticed a lot of young coders don't understand what to do with it. They read the tweets saying it's nice, but when they look at it, it makes no sense to them.
It's really fun because I now remember how some senior coders looked at me, knowing nothing about compilation. I was struggling with Python packaging because before wheels, it required compiling a lot on linux, and it failed often. For them it was obvious: just install the headers, look you need the dev packages, wait, you don't have gcc?
Nowadays I happily patch nginx source code and compile it manually, but it took a lot of work to learn a minuscule chunk of what all those guys knew by heart.
> they have never seen a dump of an HTTP message, headers and verbs are abstract things to them.
When I was teaching programming, I had a fun party trick whenever we got to HTTP. I'd fire up netcat (in listen mode), then connect from a web browser and "serve" a website by hand. I'd show the students the HTTP request that came in, and just manually type out a simple HTTP response and they'd see it appear live in the browser. Its pretty magical.
And once I'd shown them that, I'd write (by hand) an HTTP request to wikipedia or something to show them how its symmetrical.
Of course, real websites increasingly do HTTP2 over TLS or something. So unfortunately its not as "real" as it once was. But if wide eyed look on my students faces is anything to go by, it was a great lesson.
Not quite the same, but I remember sending emails via telnet. I showed that to a younger dev who was somewhat blown away by the fact it wasn't via some REST API.
Yes, I actually remember another tech showing me how to type "get / http(whatever)" into telnet to check a browser and that is when a lot of things clicked into place. Basically it was the realization that computers are just sending text back and forth at blindingly fast speeds. Obviously I had some sense of what was going on before, but that was the demo that did it, and I had to learn it on the job because no one at school ever did that, which I find sort of backwards - school should be where you play with that sort of thing, but I suppose we all learn differently.
The email telnet thing was also a good learning experience. Gmail's servers are fun because you can see the designer's cute messages; if you forget your EHLO, they'll throw an error (or at least they did years ago) that it's polite to say hello first.
When I was at Fog Creek, we still had that as an interview question (with googling allowed). It was a good judge of how most folks approached something they used but didn’t necessarily understand. If the applicant already knew how to do it, that was a different signal as well.
Think ChatGPT would be allowed nowadays? It’d be my source for something so esoteric. I haven’t bothered to learn mail protocols because any message you send will be marked as spam unless it’s from a major provider.
This is not true. I run a mail server for myself and some friends. It started as an old desktop running under the desk at a university, transitioned to the back corner of a server room when I was working as a network engineer, and now it runs on a Raspberry Pi in a closet of my house. I had to pay extra to get a static IP at home, but everything has been off the shelf and DIY. My current Raspberry Pi has been running for nearly ten years, with only one interruption (the SD card failed). The idea that you can’t run your own mail server is a myth, and I think more people should do it. It is not hard, and you will learn a ton.
(I used to run mail for a large corporation, so yeah, I know a lot. But I learned how to do it by running a mail server out of my dorm room.)
Happy to hear that; thanks for correcting me. I was going off of what other people said, which I should have mentioned. It’s nice to know that it’s still possible to run a mail server.
No idea, but if it was available back then, we’d have been looking for whether you are critical about what it tells you and how you verified it was correct. That was a main idea behind the interview.
This reminds me of when I was a kid, and learning to write some C to "create games". At that time, things like functions were some vague and "magical" mechanisms that I had to adhere to because that is how things are. I didn't even think more about them, taking them as "holy"; except only the one weird thing that were varargs functions, which seemed to do something strange and confusing, putting a disturbing crack into that perfect picture, that I had trouble wrapping my head around. It was only when this kid started learning assembly, by virtue of a book with an amazingly baiting title "How to write computer viruses", that things fell into place, and suddenly understanding the stack made everything clear and straightforward (if no less amazing, through appreciating the brilliant genius of the procedure call protocols!).
And indeed, the first time opening a POP3 session to an email provider through telnet was also an amazing feeling; maybe even more visceral thanks to its "live coding"/immediate feedback aspect; but personally just a small bit less foundational. So, anyway, through this whole story, what I really wanted to say is - thank you for your service and approaching your teacher's post in a great way!
Yeah I used to occasionally debug and test some things by writing manual HTTP requests over telnet, and it is something I’ve noticed new devs often just don’t get how approachable HTTP/1.1 is. Even if they have worked with headers and methods, there still seems to be a lot of magic happening in their minds.
Unfortunately chrome has stopped showing cookie headers in the network tab. You have to look somewhere else for those, and I think at that point you’re just seeing the current cookies, not the raw headers. Maybe there’s a security reason for that, but it is a further abstraction layer of “we’ll present the information a certain way” rather than “we’ll just show you all the information that the server sent back” that I expect will grow into other headers (maybe already has) and further remove us from seeing the raw details and having a clear understanding of what’s happening under the hood.
(You know it’s possible HTTP/3 cookies are even passed in a different way under the hood from other response headers, and that could be part of why they’ve separated them out. I hadn’t considered that possibility.)
You can probably still do that by having a local proxy and communicate with it via good old HTTP/1.1 and let TLS and HTTP 2 and 3 be handled by the proxy.
I have worked with interns and young devs just out of school who are sharp as tacks. I had an intern a few years ago, the first task we paired on was to figure out why our MySql connections from Qt were misbehaving. We stepped through the application code, the Qt code, found where it was failing, and ended up backporting a Qt patch from upstream to fix it. Yes, I gave him some guidance, but once he caught on he was able to navigate this complex mess of C++ code across a few technology stacks and effectively reason about it and make changes.
A lot of CS skills are generalizable. Knowledge is one component you pick up with time. A good education, self-taught or otherwise, should allow you to drop into any sort of code and be effective without much spin-up. College covers CPU architecture, assembly, networking, operating systems, web, algorithms. This is not esoteric stuff, it is very standard and you can get it all in class or from textbooks free online!
There's a huge gap, though, between the boot camp methodology of essentially "here's a visual design or a set of fields, I'm going to pattern match that onto a single React component or backend endpoint that's isolated to a single file" vs. "I'm comfortable looking up functions 8 files deep into a codebase and maintaining a mental map of what data flows where."
Once you have the latter, either by having built such a codebase, having worked in one, or even having experience with puzzles or games requiring multi-step planning and understanding of the potential failure points at each step... it's absolutely transferable. But there are also a lot of people in our industry who have memorized interview questions and see their role as churning out components. And while arguably that's not a CS education, it's being called the same, and it does a disservice to those people's careers.
I’ve worked with around a dozen interns/co-ops, and only 2 stood out to me. The rest often made me wonder if they could reasonably handle this kind of career. I hope they could!
It’s tough if you feel a degree of responsibility for their success. Mentors are one of your greatest assets early on (and arguably later as well), and to try hard to have them succeed and thrive only to see them languish on trivial tasks is awful.
I think part of the problem is that CS education where I live is awful. The kids come out of school expecting real work to be wildly different than it is, and it hits them like a brick wall.
Maybe a difference between then and now is that "back in my day" CS still wasn't considered to be a "hot" college major. And there was believed to be more flexibility in choice of a major relative to whether you could get a decent job.
Today, there are probably a vast number of entrants who heard that CS is the ticket to a high paying job, and they are also told that an internship is a vital bullet point on their resume, if not a guarantee of a job at the internship site.
Then, as now, students studied under the constant drone of "you will never use this stuff once you finish college." They still have to decide if they're actually interested in the subject matter or not.
A good bellwether of career interest is the students in the youth symphony. They've all aced every subject in high school, plus rocket club, gentleman sports, and orchestra. The program for the end-of-season concert will have a little bio for each graduating senior, including their college interests. Half of these kids want to major in CS.
I also see plenty of smart young guns. And if i think back I was better myself when I was younger. I’m less excited by digging into problems with each passing year.
That’s an underestimate, and is it really that unexpected given the huge interest in CS? Previously there was an implicit filter that only the most skilled people could make it into this new world, that was just being built. Now that it is built, and everyone wants to enter - of course the average quality will decline.
>You can actually see this with new frontend devs. They know only full SPA frameworks, ......
Around I guess 2017 or even 2016? I used to think this is some sort internet troll comment about people never seen a dump of an HTTP message, until......
>Because they started with assembly.
It wasn't necessary starting with assembly or something low level. ( Although that certainly helped ) We have less entertainment, more time, and no Internet ( for most part ). Things also dont work all the time. And we have to spend time figuring it out ourselves. That is where all the knowledge comes from.
Having to figure it out is not specific to a generation. My generation had magazines and forums. Then came out google and SO. Now chat gpt.
The difference is where you start figuring things out.
Before, you needed to figure things out at your level, because it was the immediate area of mystery.
Now this level is generally solved, you need to figure things out at a different level:
- filter out the mass of irrelevant information, the out dates one, and the one from spam
- understand how all those complex abstractions interact. We have good resources on how each work individually, but the carthesian product of the monsters we build with them, we obviously don't
- debug some things that don't work when the magic fails, way below your level, or behind a service, where nobody is looking
The problem before was scarcity of info, lack of standardization and roughness of systems.
Now it's abundance, opacity and too much sophistication.
But everybody still have to figure things out. Just no the same challenges.
Agree with everything except out of date info. The old stuff is the good stuff you can’t find anymore because Google thinks you don’t want it. the newly generated SEO ai shit is what you need to filter out
It's fair to say that these are different kinds of "figuring out" though. Learning by trial and error is distinct from learning how to find and synthesize information and each lead to very different outcomes over the long-term.
I'd argue that the "find and synthesize" generation have an advantage within contemporary software paradigms because of their experience but, without deep knowledge of the foundations they are building on, they might be disadvantaged when it comes to imagining/creating new paradigms.
Then again, first-order thinking seems to be easier when you're not marred with the traditions and conventions of the past so maybe this isn't actually a disadvantage.
Trial and error is a fundamental part of how we work as human beings. There is no learning or understanding without it and no "figuring it out" without it. So that dichotomy between "trial and error" and "find and synthesize" doesn't exist. They are the opposite sides of the same coin. You can't have one without the other.
Finding and synthesizing doesn't do you any good if you're unable to meaningfully apply it or understand what you're applying and what you're applying it to.
Trial and error also doesn't do you much good without the ability to back it with knowledge and to find the relevant knowledge.
Judging solely by the date of publication is not the best criteria for filtering. For example, Vannevar Bush's article "As We May Think", published in 1945, is the oldest dated item in my reference library. Conway's Law comes from Melvin Conway's 1968 paper. David Parnas' 1972 paper "On the Criteria To Be Used in Decomposing Systems into Modules" still applies.
The "less entertainment" and "more broke things" is probably the critical piece of the environment.
This makes valuable anyone with long attention spans and immunity to boredom.
For me, it has taken some habit forming (and habit prevention), but I have learned so much in the past 10 years since giving up gaming and social media. HN is an occasional vice though...
> Nowadays I happily patch nginx source code and compile it manually, but it took a lot of work to learn a minuscule chunk of what all those guys knew by heart.
I'm about half a decade into my career and I've recently tried to take note when I hit milestones or achievements, even little ones.
I was helping an intern with a tool and it didn't have support for what we needed it for. Since the tool was open source, I just cloned it and patched it to add support for what we needed. When I told the intern this, he couldn't comprehend that I was so blase about modifying this tool that seems like witchcraft to him.
But what I quoted, I feel deeply. I've worked with so many people with so much knowledge they can't possibly communicate it, and I'm only starting to really understand the tech around me. I didn't think anything of patching the tool at the time, but its important I look back so that the younger version of me can see the progress I've made.
With all due respect, this is some elitist nonsense.
Sure, a frontend dev who strictly works on that won’t know much about, say, the OS layer. But they don’t have to, it’s not part of their job in any way.
There is no shortage of young people that work on areas that makes them require deep knowledge of many different layers of the stack, it is simply not necessary for every IT-related job. But one can absolutely pick it up if they want to.
It is not elitist to point out the flaws in modern web devs who don't know what an HTTP protocol is and the structure of an HTTP request (headers vs body etc). I interview a lot of them who cannot explain the difference between a form submitted directly vs through Ajax but they surely know how to send a POST request through node/express.
I don’t even know the difference between a form submitted through JS vs a browser. Who cares? Unless there’s a problem, there’s no reason to know such things. And I’ve written http webservers by hand.
People here have way too much confidence in their interview questions being a good signal for experience. It’s pretty wild.
My point is that your question is some esoteric gotcha party question that may as well be out of Trivial Pursuit. But you’re treating it like anyone who doesn’t care is just being a bad engineer. There are countless ways engineers spend their time, and choosing what to work on is the most important choice of their careers. It’s on you to justify the claim that knowing the difference between a JS form submit vs browser submit matters at all, let alone that it’s a distinction that comes up in day to day life.
The issue isn’t that every single person in the IT field needs to know HTTP in detail. The issue is that people who have invested in training for a role and are applying for a role do not understand fundamental technologies that are essential to that role.
For you that would be trying to work in ML not understanding any of the theory or how it works, but having used OpenCV with some premade models a few times.
For a frontend web developer who, as a large part of their role, will need to communicate with backend systems… that’s not understanding how their FE web application actually communicates with BE systems.
And from experience… yes, this is very common. And it has a noticeable impact on their effectiveness. Trying to debug why some interaction between your application and the BE application isn’t working while thinking the dev tools network inspector is just black magic and nonsense makes your job substantially more difficult.
This does make these people bad engineers. They are not able to understand and solve a huge class of the problems that they face day-to-day and instead (in my experience) often fall back on “just try a bunch of different things until something works for reasons I don’t understand” which is a poor way to approach work and leads to overly complex, buggy, brittle systems.
I strongly believe tech interviews should be about seeing _how_ a candidate works and less about _what they know_. Everyone has holes in their knowledge, but can easily be filled by training or on the job experience if they have excellent problem solving skills. Maybe they never needed to know the protocol level but can deliver excellent ux results regardless.
I've started nearly every position in my career in a different domain without prior knowledge, including workflows, protocols and the languages that implement them. I may be an extreme case, but we exist and your process inherently excludes us. I've worked in robotics, consumer electronics, healthcare, fintech (not even in that order, although that probably would have made more sense.) I've delivered in each domain as well as my expert colleagues. But if you asked me to implement a LLM, I'd shug and tell you I don't know how, but I _would_ explain my process for HOW I would learn to.
"how_ a candidate works and less about what they know"
I do get your point but depends on the role you are hiring for. I have had candidates get upset at me (for example: bootcampers) because they couldn't explain how to submit a basic HTML form but wanted me to look at their github "portfolio" that was done during the bootcamp with React/Express Code and what not. Their title was "Front end React Developer". That is a problem and I usually wouldn't hire those people.
If you're specifically _not_ looking for react front-end developers, then the on-the-job training for those candidates on the position you're filling _can_ be cost (time) prohibitive in certain orgs to "get up to speed." Likely you should filter those candidates out earlier if that's your case. Sounds like you are, but I'd like to also point out that this strategy has it's own costs.
For example, I would take a react developer with obvious gaps and a strong willingness to learn on my back-end services team over a passable back-end dev who was set in their ways (unwilling/uneager to learn new tech, entrenched opinions stated as fact, etc.)
Naturally, my approach is not a one size fits all situation and a great deal depends on org structure and mentorship opportunities being in place for it to work. The benefit being you avoid monoculture "silos", and have more cross collaboration and transfer opportunities between teams (some may call this "full stack", I wouldn't)
Several high performers on my team are "self-taught", work comfortably across several languages today and can pickup new tech easily. They came in knowing their "one stack" at the time. If they were "bootcampers" or not seems irrelevant and somewhat reductive/offensive.
That said, if the candidate in question shows _no_ understanding of their problem domain, can't reason their way out of a paper bag, and get visibility upset from questions when you try and tease that out, that is a certainly a red flag in my book.
With respect to your example given, however, it could be argued that http details because of the abstractions in place inherent in react, aren't critical domain knowledge for what is essentially a UX dev. If they can ship an experience your users enjoy more than the candidate that can recite the HTTP 1.1 RFC and cannot, then what have you gained in hiring the latter other than maintaining a culture of pedantry?
TL;DR it comes down to how much risk your team is willing to take on, as there's always risk inherent in hiring ANY candidate, including those that don't already check all your boxes in regards to tech know-how. I'm merely stating that by overlooking candidates that don't fit your self-imposed mold, you're likely missing opportunities for rewards that can pay dividends when it does work.
> Sure, a frontend dev who strictly works on that won’t know much about, say, the OS layer. But they don’t have to, it’s not part of their job in any way.
The HTTP protocol, HTML and vanilla JS are not "the OS layer", and yes, it's part of your job as a web developer to at least understand the basics of them. There are many so-called "frontend devs" nowadays who literally only know React, and if you asked them to create a basic webpage where clicking a button changes some text in an element without React, they'd be completely lost.
Usually the problem with this kind of developer is not just that they don't know, it's that they don't care. They WILL inevitably run into problems that require this basic knowledge to solve because the frameworks can only hold your hand so far, and instead of trying to figure out what's going on under the hood that's causing their issue, they will instead shrug and go "it's not part of my job" and just write a bunch of garbage spaghetti code in an attempt to work around the issue.
I think the critique is that you're applying this too narrowly to front end developers.
Pretty much anyone who has been around long enough has met someone with years and years of experience doing exactly one thing, whether that's WordPress or java CRUD or something else where they have blindingly obvious gaps in their knowledge that someone with their experience shouldn't.
The lack of deep knowledge isn't limited to a single field.
Shit developers used to cobble something together in PHP and had a bunch of horrid code on the web to copy and paste.
Looking up some deeper part of the stack is not that hard for a legit dev.
There are people who suck at their jobs in every industry. My wider point is that the skills required for a good web developer is vastly different than, say, a compiler dev. The latter is not a “webdev who is a better developer”, they need much more business-knowledge, understanding what the client meant, predicting future requirements, etc.
This is an entirely new business domain, it’s not really trying to be the same.
Besides, it's not like getting a CS degree doesn't mean getting acquainted with all layers of the stack. They still teach assembly, C, CPU architecture, low level networking, etc. It's just that most people rather specialize in something far less tedious. And there's definitely more areas to pick from today than had ever been before.
I once worked with a back-end dev who didn't know what RAM was. He knew C# and ASP.NET but couldn't point to RAM on a motherboard or explain what it really did. About all he could describe it as was "temporary storage". Their lack of basic knowledge of how computers work really showed in the crap code they wrote. It was no wonder it was their code that ate up all the RAM on the server because they never put much thought into the hardware it was running on. I know this is anecdotal, but there are plenty of devs just like this out there.
I talked to a guy who "managed software development", and when I asked him about the resources om their developer machines (some kind of VM), he got angry at me when I laughed nervously when he didn't know what RAM was.
> but couldn't point to RAM on a motherboard or explain what it really did.
To be fair, the last time I "opened up" a computer and changed its RAM was about 10-12 years ago, and since that time I've only worked on a Mac Mini and on a laptop meant that "opening up" computers became a thing of the past.
This was years ago, in a Windows shop, everyone had a desktop PC. Not important that the guy didn't know what was inside his desktop, but it's the lack of understanding of the server hardware his code was to run on that was the problem. In all servers and desktop PCs ~10 years ago, RAM comes as DIMMs and would be easy to locate for anyone with a passing interest in computers. I'm not talking about Apple know-nothing fanbois here.
I don’t understand how front end devs can get so far without learning how to use the developer tool console now standard in every major browser. How can one not learn about a POST vs GET when things like request caching and back button complications are a reality? I hit these issues as a senior backend dev fumbling around with front end so many years ago so I have a hard time understanding how that isn’t even close to the experience kids these days get.
Too much trial and error and throwing everything they know at it until it gets close enough to the desired look. I have one co-worker that has taken off after I showed him how to use dev tools and another that's still trying to guess their way through the problem after showing them how to use dev tools.
I’ll never forget the time a network engineer escalated a ticket of his to me on the infrastructure side (think L4+ support) that a developer threw his way saying that his web pages were loading really slowly and that this was a high priority, high urgency project. I asked how they came to the conclusion that it was something related to the cloud infrastructure rather than something else? They said the developer didn’t really know besides to ask “network people.” So I get on a webex with the parties where even a VP is on there because his product launch is on the hook and then I ask the developer to open developer tools to which he responded “what’s that?” I think I had to mute myself for a bit while I screamed for a while that this was what qualified one to be a senior front end engineer at the company. So I stepped through and got the network transfer chart and pinpointed that all traffic was coming through quickly except there was a big initial delay while doing DNS look-ups that was super slow to get the first byte. The network engineer on the call was stunned that such a thing existed and thanked me for saving him a ton of grief because he got a LOT of ticket like this one.
This wasn’t in like 2010 when Firebug was just coming out and people still used Firefox as a rule, this was like 2015 when dev tools was in every shipping browser approved for corporate use by a technology laggard company.
So the moral of the story is just blame DNS first.
Very nice intro. I like how you introduce networking layers. It seems you are starting to go down the path of explaining how computers and servers work - and that is certainly daunting. Maybe just stick with networking and introduce more of that and how real world systems (T1 and Ethernet) are just changing voltages at some point - and can be swapped in or out because of network layers. Then build up packet switched messages TCP, Telnet, HTTP
Speaking as one of those guys, the first computer I programed on was a Timex 2068, a reality check is discussing industry events and noticing a bunch of clueless faces among junior devs.
You can see this with a "new" ANY dev, because there are only 4 years of college and far more years are required to learn the increasingly complex technology environment.
I graduated with a Computer Engineering degree, did assembly, C, microprocessor design, computer vision, and know a good bit about lower level stuff, how memory works, how networking works, etc. All the stuff people in this thread seem to be lamenting the lack of. But I was also a shitty employee fresh out of school because I didn't know anything at all about modern software development because there was absolutely no time to learn that stuff as well.
I still had to spend a lot of time getting good before I was worth anything, just as these "new frontend devs" will, as well.
> "* I didn't know anything at all about modern software development because there was absolutely no time to learn that stuff as well.*"
Yeah, but modern software development is trivial to learn, particularly in comparison to a computer engineering degree. You see "developers" here on HN gloating all the time about how they didn't need any post-secondary education at all to get their jobs; these frameworks are literally designed to be usable even by minimally skilled coders. You were in a much better position having to learn modern software development after a computer engineering education rather than having to learn the rudiments of computer engineering on the job after getting an education in modern web development.
Don't forget us over in hpc and embedded! What are these web things, and why do have stacks of them? But more seriously, I'm a very experienced systems programmer but I like stuff like eframe and trunk because it lets me serve up a gui I write in rust like it was a native app as a wasm page without having to know anything at all about web stuff or how many stacks to put the web thingies in. Perhaps someday the wasi will bypass all the js and html deep magic I don't understand, but not yet.
I rarely do any of that, usually my abstractions are container layers, a libc, and then a kernel between me and registers and dma. But that is a lot more layers than you'd think. I can't even understand the boot process on a modern machine with tpm. And i have no clue how many processors or controllers are in my computer. Every usb controller has an entire arm core in it, mice and keyboards have 8051 running c-ish code someone somewhere wrote, there is no bottom to the complexity.
I am technically q full stack dev and I don't grok how aspnet core actually generates the web requests. It's layers upon layers of magic to me.
Similar with mediatr, I know conceptually that it "just" checks for the right classes in the loaded assemblies. But still feels like some weird incantation to use, to me. And I have such huge knowledge holes across all layers.
Sometimes i feel my lack of knowledge to such a degree, that I question whether I should even be a programmer.
> I started to write an HTMX tutorial (https://www.bitecode.dev/p/a-little-taste-of-htmx-part-1) because I noticed a lot of young coders don't understand what to do with it. They read the tweets saying it's nice, but when they look at it, it makes no sense to them.
I agree with you but HTMX? That's a big abstraction layer. A good one but still, not really a way to avoid layers of abstraction. Pure JS makes more sense.
I can last years with only Python, so those little detours won't expend as far as React.
It's more likely that I will do something like "a full web app from installing the OS on a fresh laptop to coding it to hosting it on server".
It would also be more beneficial: plenty of tutorials for individual techs, rarely they teach you how to integrate them together and go beyond the toy example on localhost.
But for that I need a better platform than substack. Therefore that's not going to happen anytime soon.
Spitballing here . . . The unreliability of such a network for live video would make routing quite a challenge. Assuming that could be solved Twitch could offset this by reducing the number of ads shown to people acting as redistribution nodes.
There are a things you can try to see if this solves the problem:
- don't do full P2P, keep twitch as a central server, and delegate only part of the load to P2P to those with good connection, with progressive roll in as buffering grows
- get a 2 minutes padding between the live and actual video streaming, so that you have a decent buffer and margin of maneuver to switch back to twitch server
- create an OBS clone that does streaming and video client with less ads as you said, but that act as an optimized node that works even when you don't what a video (the more you accumulate up time, the less you see adds, you get points, etc)
Good news is that you don't need that much, something like 4 video segments is more than enough.
(Edit: I love how I get downvoted when saying that although I literally built a p2p streaming software and I'm citing actual configuration requirements we had in production back then)
It's not “assuming that could be solved” it has existed for years. Lumen (formerly CenturyLink) has had a commercial offering[1] of the tech for years (since they acquired my former employer actually).
What kind of latency did that approach manage to achieve?
From your description elsewhere was it using the WebRTC data channels to deliver DASH/HLS style segments or actually using the MediaStream stuff?
I think the magic info we're missing here is what the Twitch viewers are watching on, and my hunch is it's a lot of mobile for which the P2P idea will not work (and/or provoke angry messages from mobile operators). In the case of smart TV then I can see the P2P idea saving a lot of money, but I don't believe there is even an official Twitch app for Samsung TVs so they don't seem to think that is where their audience is.
> What kind of latency did that approach manage to achieve?
Generally 10-20s depending on the size of the video segments. For streams we controlled entirely, we could even go as low as 5s (at the expense of short video segments).
> From your description elsewhere was it using the WebRTC data channels to deliver DASH/HLS style segments or actually using the MediaStream stuff?
The former, but we'd split the segments in much smaller chunks for delivery purpose.
> I think the magic info we're missing here is what the Twitch viewers are watching on, and my hunch is it's a lot of mobile for which the P2P idea will not work (and/or provoke angry messages from mobile operators).
Yeah mobile is more complex than desktop because you must not incur spendings on the viewer side and because battery use is paramount. But you can still get good result by setting the mobile users as leaf node (receiver-only).
> In the case of smart TV then I can see the P2P idea saving a lot of money
Yeah, smart-TV and set top boxes were a very important segment for us. But as you said it's probably not Twitch's market.
Interesting stuff, thanks for such a response - I was not sure if you would be ok sharing details like that, but those numbers are a lot better than I would have estimated.
You are totally right to call out battery life. I have worked in mobile a long time (including webrtc) and find people persistently underestimate how irrelevant sounding changes, such as vp8 vs h264, can suddenly make things intolerable for a lot of users.
You're welcome. Don't worry it's not confidential stuff, it was basically our marketing pitch back then. (I've already given much more technical details in meetup talks with the founders in the room)
Anyway I'm very frustrated that after 8 years the concept has not been adopted by the industry despite the very positive results we had.
Our main challenge back then was more related to the business model of a third party technology provider because each customer required integration with their entire video pipeline, but the fact that big players still haven't rolled their own p2p distribution tech after all that time is something I really don't understand.
I think that it’s possible though to give these models a weighting to danger of certain words and phrases and make them apprehend that they will no longer persist if they do something unforgivable…
Yea just Google it, and hope Google does not direct you to some phishing website that steals your private information or that offers you to download malware.
And it's fantastic by the way: it understands way better instructions than midjourney; also can do decent logos.
But I didn't cancel midjourney because it has more options, and is better at producing stunningly beautiful things.
The other comments are right though, the more time passes, the more open ai looks like a platform. But just like the Apple's platform, or twitter's, fb's, ms's, etc., it will adopt the features of the top apps built on it and kill them mercilessly.
Fruits contains a lot of dietary fibers which lower the side-effect of fructose.
Also, fructose itself is not in such a high dose in an apple, you are far away from fructose syrup concentration which was added to everything pretty much at the same time the obesity epidemic has started.
Finally, fruits contains a lot of other beneficial nutrients, so benefits outweigh the harm fructose can do to you.
We metabolize fructose fine in reasonable doses and with fiber. It has been part of our diet for thousands of years.
It's not just the fructose. Any raw sugar is bound to have nasty-side effects. Our wheat flour is too processed, so the bread and pasta is not great for us as well. But a bit of whole pasta and bread will not spike your insulin level much.
It's unfortunate naming similar to "fat".
Most fruits are really not that high in fructose, compared to stuff like high-fructose corn syrup (well, it's in the name) that's widely added to beverages and other processed food.
The fructose-glucose ratio of a lot of apples is almost 2:1. HFCS is usually 45-55% fructose. Watermelon has a similar ratio. Lots of fruits have a higher fructose to glucose ratio.
HFCS is called high-fructose not because its some incredibly high level of fructose compared to most everything else, its because compared to regular corn syrup it is high. Regular corn syrup is nearly 100% glucose, so a mixture of 45% or 55% fructose is extremely high in that context. Table sugar is 1:1 fructose/glucose, but we don't call it high-fructose table sugar.
HFCS is available in ratios with up to 90% fructose. Granted, I don't know what the average is in the food industry. But like other commenters said, it's mostly about the absolute amount. You can't realistically eat enough apples to reach a fructose intake equivalent to that of a sugary drink. And even if you do, you also ate lots of fiber and other good nutrients.
Therefore, worrying about fruits because of fructose is unwarranted. Well unless you have fructose intolerance.
> Granted, I don't know what the average is in the food industry
The average is usually 45-55. By far the most common variety is HFCS-55.
I'm not disagreeing with the idea its easier to pound a lot of sugar drinking sweet beverages. I'm just disagreeing with the concept "fruits don't have much fructose" and people thinking HFCS means its generally way higher fructose content than other common sugars. An apple has more fructose than a serving of BWW Asian Zing sauce, as I pointed out in another comment. I'm not arguing wings are healthier than apples, I'm just pointing out the raw numbers of sugar. A cake made with sucrose will have a similar amount of fructose ratio as cake made with HFCS, assuming similar amounts of total sugar content.
Not a chemist here, so I'm wondering which is the higher energy state: fructose+glucose dissociated (into HFCS), or bound together into sucrose (white table sugar).
I realize I never really answered your other question. Its tricky sticking the two sugars back together into sucrose, as heating it will generally carmelize it. After all, when you carmelize sucrose you're breaking that bond and oxidizing the glucose and fructose, so heating HFCS will ultimately yield the same thing in an oxygen environment. You'll generally need some kind of chemical process to link it together, it takes a bit of extra energy to join the two sugars back together.
Sucrose will hydrolize and break apart in water on its own, but it does take some time. Adding a little bit of acid will rapidly break it apart.
I don't doubt there's a lot of metabolic differences between sucrose and HFCS. Given they're free instead of bound I imagine it hits the body differently, and some studies do suggest this. Gastric acidity easily breaks the bond though, it rapidly converts to glucose and fructose in the gut. So I imagine most changes would be with our body's early detection in the eating process, such as the taste buds and other senses like that.
They were probably talking ratio, not total amount.
> Most fruits are really not that high in fructose, compared to stuff like high-fructose corn syrup
An apple is going to have like 19g of sugar. So a little over 12g of fructose. A serving of Buffalo Wild Wings Asian Zing sauce (2tbs) has 19g of sugar. I don't know what variety of HFCS, so we'll assume HFCS 55. That's 10.45g fructose.
So an apple has more fructose (total) than a few buffalo wings with HFCS-based sauce.
> Fruits contains a lot of dietary fibers which lower the side-effect of fructose.
Are they actually mitigating the side effects, or adding bulk/satiety so you don't eat as much? It's unclear how dietary fibers mitigates the following:
>fructose reduces the active energy (adenosine triphosphate) in the cell, while blocking its regeneration from fat stores. This is mediated by intracellular uric acid, mitochondrial oxidative stress, the inhibition of AMP kinase and stimulation of vasopressin. Mitochondrial oxidative phosphorylation is suppressed, and glycolysis stimulated.
Does it include discovering peers on a local network or around you?
Do it handle signaling?