Post B6d1JbkCcbTYt7ukQi by ignaloidas@not.acu.lt
(DIR) More posts by ignaloidas@not.acu.lt
(DIR) Post #B6cwxI3sikibekDoES by wolf480pl@mstdn.io
0 likes, 0 repeats
A while ago I saw someone (forgot who) say that Linux is a set of building blocks that you have to build an operating system out of yourself, as if that was a bad thing.But for me, that's the best part about the Linux ecosystem.For example, see how pppd won't write to /etc/resolv.conf or integrate directly with systemd-networkd. Instead it will pass the discovered DNS server addresses to an ip-up script, where you can pass them to whatever you use to manage DNS servers.
(DIR) Post #B6cxxtCEkqQMmWymZc by wolf480pl@mstdn.io
1 likes, 0 repeats
Even if you're not writing those scripts because your distro's maintainer wrote them, you can read them (much more easily than finding the source code of a particular components), so they give you a glimpse into how things are tied together.This kind of approach - loose binding between software components through various hooks and scripts - used to be very widespread in Linux distros.It's sad to see things integrating directly with systemd and other DBus APIs instead these days.
(DIR) Post #B6cyhFgbz5YvZ2okK0 by ignaloidas@not.acu.lt
0 likes, 0 repeats
@wolf480pl@mstdn.io the problem for me is that Linux doesn't really provide the interfaces into which to build that stuff into - stuff like DNS in practice ends up kinda left up to libc to deal with, which in the ends gets standardized through practice and you can't change that without rewriting half of the world.
(DIR) Post #B6cyhFtjCK3QDixDlY by ignaloidas@not.acu.lt
0 likes, 0 repeats
@wolf480pl@mstdn.io this is partly why I actually welcome systemd doing a bunch of this stuff - they actually have interfaces that can be replaced without replacing half of the world.
(DIR) Post #B6cyhG40a6HGjblQn2 by wolf480pl@mstdn.io
0 likes, 0 repeats
@ignaloidas wait a secare we talking about configuring DNS or about resolving hostnames?If we're talking about configuring DNS, I don't see how it can get any easier to replace than openresolv...
(DIR) Post #B6czS1KDCGm2dMdo1o by ignaloidas@not.acu.lt
0 likes, 0 repeats
@wolf480pl@mstdn.io I see it as the same thing tbh? You can't really resolve without dealing/knowing about the configuration, and you're not really configuring without controlling how resolution is performed.
(DIR) Post #B6czS1XKPVGXI2mHTM by wolf480pl@mstdn.io
0 likes, 0 repeats
@ignaloidasthat's kinda like saying that adding routes is the same as opening a socket...
(DIR) Post #B6czW4MLrAcpCgZYi8 by wolf480pl@mstdn.io
0 likes, 0 repeats
@ignaloidaslike yes, there is a component that needs to implement both of those things, but they can be two separate interfaces
(DIR) Post #B6d1JbkCcbTYt7ukQi by ignaloidas@not.acu.lt
0 likes, 0 repeats
@wolf480pl@mstdn.io Not really? There is only one way to open a socket, linux provides a well defined interface for that, and with adding routes you configure what happens when that interface is used.There is no well defined interface for resolving DNS, and I can freely write a program that will resolve DNS without any regards to any kind of configuration. Thus, I cannot comprehensively configure DNS resolution on Linux.
(DIR) Post #B6d1JbxfoWFdYuDVQW by wolf480pl@mstdn.io
0 likes, 0 repeats
@ignaloidas there is a standard for resolving hostnames: gethostbyname/getaddrinfobut okay, sometimes you explicitly want something from DNS instead of just "any hostname resolution service", or you want something from DNS that isn't a hostnamethen you use /etc/resolv.conf + RFC 1035I admit it is a bit of a mess, but IMO it's not as bad as you made it sound.
(DIR) Post #B6d36B7yTCc0Twl1hA by ignaloidas@not.acu.lt
0 likes, 0 repeats
@wolf480pl@mstdn.io gethostbyname/getaddrinfo are tied to libc, not to linux, and I see zero reason why linux should be tied to libcresolv.conf gives little control over finer details unless I have a local DNS server that actually does all of the resolution, which fucking sucksI get that this might sound totally crazy, but what I really want is to standardize the OS interfaces, to extremely high abstraction levels (I want a HTTP syscall interface for example), and not get stuck in 90s levels of what a OS should abstract. The fact that DNS is realistically still something that the kernel has 0 clue about is just dumb in my mind.
(DIR) Post #B6d36BLRf7O59j3mgy by wolf480pl@mstdn.io
0 likes, 0 repeats
@ignaloidasIt does sound totally crazy.
(DIR) Post #B6d5IT2Ttx3nPtAxHs by wolf480pl@mstdn.io
0 likes, 0 repeats
@ignaloidaslike, half of the reason many protocols are built on top of HTTP is that the OS is not aware of it and doesn't get in the way(the other half is that the other OS - the web browser - only allows HTTP... do you plan to have CORS checks as part of the OS?)Fair point on not wanting libc tho.
(DIR) Post #B6d7IFXgHXm1SunEKu by rozenglass@fedi.dreamscape.link
0 likes, 0 repeats
@wolf480pl@mstdn.io Indeed. Sadly, wanting simple decentralized things that compose through generic interfaces is an acquired taste, and seems to be a relatively rare one at that. I think most people think in terms of "solutions", they have a problem or need, they want a single solution with easy instructions to follow, the more parts the solution is made of, more alternatives that exist, more exceptions and weird edge cases they have to understand, more steps of instructions they have to follow, it's all just more cognitive load they have to spend to solve their problem, and that is of course a "Very Bad Thing". The other mindset is very different, thinks in terms of skills and tools, giving such people an "integrated solution" with "step-by-step" instructions is a /loss/ in their minds, because in their own eyes, they just learned less, were kept in the dark, earned less skill, and seeded control to the generally suspect class of "Those Who Know". To have alternative tools is a positive thing, to learn the exceptions and the edge cases is pleasant, to experiment with combining the tools they earned in crafty creative ways is one of the most positive experiences they may have. Some may say that we all are both types of people, depending on the domains of interest, and there is perhaps truth to that, but I strongly feel that this difference is more essential, and is not just limited to their subjects of interest: the craftsman's mindset seems to have a natural /negative weight/ to having to deal with some life domains using the "solutions" mindset, they don't like things abstracted away from them; they would rather learn the tools and skills needed to heal themselves or their loved ones, to construct their homes, to build their cars, to design their own electronics, to grow their food, etc. They only reluctantly choose not to do that, due to the very regrettable lack of time and resources associated with being human, while the first "solution" type thinks of every tool they don't have to learn, and every skill they don't have to practice, as a good win; given the choice, they would rather abstract most things away. If infinite time and resource were given to type-2, they would learn every tool earn every skill, and open every black-box, but if the same happened to type-1 They will want to not have to deal with any problems, or learn anything, beyond some limited set of personally significant interests, perhaps, and would rather everything be in neat little black-boxes, never ever needing to be opened.
(DIR) Post #B6d9g0DZ6pzMnOq1Lc by wolf480pl@mstdn.io
0 likes, 0 repeats
@rozenglass I think there's another angle:You can think of your software as a component, with a defined spec, that's supposed to be used in an unlimited number of usecases without you (the author) having to know or care about them.Or you can think of yourself as the integrator, building a user-facing product and responsible for it working end-to-end.You'd think that distros would be the integrators, and upstreams would make components.However, it's not always the case1/
(DIR) Post #B6d9ubX1AsHgZntpoW by wolf480pl@mstdn.io
0 likes, 0 repeats
@rozenglass Because in the last 10-15 years, upstreams have begun thinking like brands making products. So they try to take the role of an integrator, taking responsibility for something working end-to-end, and getting angry when a distro changes things.And if the upstream feels responsible for their software's integration with the rest of the OS, we get the solution thinking you described - minimizing the space of possibilities, so that they can test everything.
(DIR) Post #B6dCEnHBPxbqhZFQJc by wolf480pl@mstdn.io
0 likes, 0 repeats
@rozenglass oh, by the way"loose coupling"is an engineering principle deemed so fundamental that it's rote-taught to Java programmers along with design patternsof course applying it to every module inside a program is a rookie mistake, but that doesn't mean it should never be done...
(DIR) Post #B6dRbwnNgpa0CLo4Rc by light@noc.social
0 likes, 0 repeats
@wolf480plI would really love a private (and secure) OS that I didn't _have_ to tinker with to make it work.I mean, it's nice to be _able_ to tinker with it, but I don't want to _have_ to.
(DIR) Post #B6esVFTYjLTk1lWd2O by ignaloidas@not.acu.lt
0 likes, 0 repeats
@wolf480pl@mstdn.io I think it's mostly because it's in the browsers rather than anything to do with the OS - from Linux side, it doesn't know whether you're using HTTP or SSH (unless you use TLS acceleration I guess). Arguably, it's more about the various middleware that does get in the way, and blocks everything but HTTP.Or that it's included in a whole bunch of standard libraries (except C(++) lol)Having it in the OS would reduce the effective code duplication, reduce interoperability issues, and allow greater control over to who and what programs communicate. E.g. I could see having an enterprise policy that besides a small set of trusted programs, only allows communication through HTTP, and inside HTTP, can check to who/what endpoints the communication is performed, and block them on some conditions. This is equivalent to the middlewares that a whole bunch of companies are running, but doesn't require extra hardware, can be communicated to the user more clearly, and doesn't require breaking TLS through adding extra root certs or whatever.
(DIR) Post #B6esVFeu3AYKawpgie by wolf480pl@mstdn.io
0 likes, 0 repeats
@ignaloidasok so I was a bit fuzzy on the reasoning for everything-over-http and then I remembered thay it was actually for everything-over-UDP:- TCP was implemented in OSes- WebRTC and HTTP3 wanted a different transport (SCTP+DTLS and QUIC, respectively)- you can't easily deploy a new transport protocol to all the OSes- therefore, they layered it on top of UDP1/
(DIR) Post #B6esY7KVTQ0BdEeudk by wolf480pl@mstdn.io
0 likes, 0 repeats
@ignaloidasnow imagine this:- you implement HTTP as part of the OS- WHATWG wants HTTP4- they can't easily deploy a new HTTP version to your OS- therefore, they layer it on top of HTTP CONNECT or sth
(DIR) Post #B6evUWp5WhyulUh5Ps by ignaloidas@not.acu.lt
0 likes, 0 repeats
@wolf480pl@mstdn.io Just implement it into the OS? The UDP thing happened because you realistically can't pass anything but TCP or UDP over "internet" because there's a whole bunch of infrastructure that only knows those two and would have to be replaced for a new thing.And like, a single OS update to add a new HTTP version seems way simpler than upgrading every single HTTP library.
(DIR) Post #B6evUXBQBfqVsl8vE8 by wolf480pl@mstdn.io
0 likes, 0 repeats
@ignaloidas"you need to buy a new smartphone to get HTTP3"
(DIR) Post #B6ewDj3qs8grkh9RRY by ignaloidas@not.acu.lt
0 likes, 0 repeats
@wolf480pl@mstdn.io I mean it's basically that with iphonesAnd I don't think "vendors can abuse it" is an argument tbh - vendors will abuse everything.
(DIR) Post #B6ewDjI21Q26SfmlXs by wolf480pl@mstdn.io
0 likes, 0 repeats
@ignaloidasmy point is, abuse at current layer is better than abuse 1 layer up, because fewer useless layers is better