For distro-packaged FOSS, binary compatibility isn't really a problem. Distributions like Debian already resolve dependencies by building from source and keeping a coherent set of libraries. Security fixes and updates propagate naturally.
Binary compatibility solutions mostly target cases where rebuilding isn't possible, typically closed source software.
Freezing and bundling software dependencies ultimately creates dependency hell rather than avoiding it.
It however shifts a lot of the complexity of building the application to the distro maintainer, or a software maintainer has to prioritize for which distribution they choose to build and maintain a package, because supporting them all is a nightmare and an ever shifting moving target. And it's not just a distribution problem, it's even a distribution version/release problem.
Look at the hoops you sometimes have to jump through or hacks you have to apply to make something work on Nix, just because there is no standardization or build processes assume library locations etc. And if you then raise an issue with the software maintainer - the response is often "but we don't support Nix". And if they're not Nix/Nixos users, can you blame them?
If you've ever had to compile a modern/recent software package for an old distro (I've had to do this for old RH distro's on servers which due to regulations could not be upgraded) - you're in a world of pain. And both distro and software maintainers will say "not my problem, we don't support this" - and I fully understand their stance on that, because it is far from straight forward, and only serves a limited audience.
That is very true. But because it is open source, one can request for packaging, contribute a package, use a third-party repository, or build it from source when needed.
> The most concerning limitation in the German market is the unavailability of native Glass Fiber modems, that can accept as input a Glass Fiber connection: at the moment, providers install their own Glass Fiber modem.
Im actually quite okay with that. Why should I have to pay for specialized hardware that won't be usable if I move and the new apartment uses DSL or docsis.
Give me an rj45 (or sfp for some fiber connections) and let me put whatever Router I want behind it.
You say "why should I have to pay", but they really haven't said or suggested anything about how they'd rather you paid for anything. They're talking about having an option to supply one's own device, not about requiring so.
The common rationale behind this I'm aware of is that an ONT device is technically a computer with persistence, hosting arbitrary code and data that you cannot (or at least not supposed to) audit or alter, despite being on your premises, operated on your cost (electricity, cooling, storage), and specifically deployed for your use. These properties hold for SFP modules too in general, not just SFP ONTs (they're all computers with persistence).
The catch is that this is further true for all of these kinds of modems.
The counter-catch is that despite that, for DSL specifically, you could absolutely bring your own modem, hw and sw both.
The counter-counter-catch is that with DSL, you were not connecting to a shared media, but point-to-point. This is unlike DOCSIS and GPON, where a misconfigured endpoint can disrupt service for other people, and possibly damage their or the provider's devices and lines.
Very much indeed, a 'rogue ONT' can screw another nearly 63 users' acess in my area. Oversubscription is very noticeable, but just not problematic. 10G FTTH delivering 60~70% of the bandwidth is enough I guess. And latencies or jitter aren't a thing either.
The "glass fiber modem" is an inherent part of the GPON network. These are complicated. The "P" stands for "passive". Yours and and up to 127 other houses are all on the same "light domain" i.e. the downstream is passively split, and the upstream is passively combined, in optical boxes that don't even have electrical parts.
This needs crazy accurate timing for the upstream. The head end needs to know the exact delay to your particular box to give it a "grant" to transmit at exactly the right time so transmit bandwidth is not wasted by idle time or multiple boxes transmitting at the same time and corrupting each other.
You don't want brand X modems with dodgy configurations in this. Of course as a consumer you'd want "as little modem as possible" i.e. just give me an ethernet port running DHCP or PPPOE and let me do the rest.
They are complicated, but standardised and commoditised. Ubiquiti, for example, sells an ONT (fibre modem) in a SFP form factor for US$39 [1], or a little standalone unit with an Ethernet port for US$49 [2].
For comparison: you can bring your own DOCSIS modem to a cable network, even though all the houses on the street are connected to the same cable and you could jam it, or send a voltage spike to break everyone's modem.
Not very familiar with DOCSIS and cable; the story I'm getting from my nearest friendly LLM is that while you could bring your cable modem, it'd have to be a pre-approved model, and that the firmware and configuration would be under ISP control, unlike with DSL modems. Is that wrong?
By law the demarcation is a passive one; the provider is not allowed to mandate you operate ANY of their active hardware. If they want to sell you internet only via e.g. RJ45 Ethernet they better consider asking your landlord to rent them space and power and Cat.5(+) wiring access to put a switch/router, because by law they can't dump that on you the residential apartment renting customer.
You may either rent/buy a device from your ISP, or you may bring your own, at your discretion. ISPs are required to accept all devices, of course if your device kills the network segment, they will kill your connectivity. But they can't refuse to let you connect.
You get taken to court and sentenced to pay the damages? Same thing that happens with the TV cable that runs through the whole street. Or the cars parked openly along the road. If you damage it, you pay for it.
Controlling your hardware without consent that they legally can't ask for would be illegal hacking.
They do however have the right to mandate certain configuration parameters just how they are allowed to mandate you connect something that isn't a noise generator to e.g. a cable TV outlet. Well, being able to limit you to connect devices that conform to some spec.
Why don’t you take a moment to explain to the class why you think web crawling means you can’t cache anything?
It seems to me that the very first thing I’d try to solve if I were writing a tool for an LLM to search the web, would be caching.
An LLM should have to go through a proxy to fetch any URL. That proxy should be caching results. The cache should be stored on the LLM’s company’s servers. It should not be independently hitting the same endpoint repeatedly any time it wants to fetch the same URL for its users.
Is it expensive to cache everything the LLM fetches? You betcha. Can they afford to spend of the billions they have for capex to buy some fucking hard drives? Absolutely. If archive.org can do it via funding from donations, a trillion dollar AI company should have no problem.
Emphasis on the freedom, especially the freedom to use by anyone for any purpose.
If it took some people in the FOSS space this long that it also includes people, companies or purposes they disagree with, then I don't know what to tell them.
You are correct but in the context of free software, the FSF has been explicit about this ("The freedom to run the program as you wish, for any purpose"). Publishing software under a FOSS license imply that you agree with this definition of freedom.
Have you actually read one a Free/Open-Source license? Like for example the MIT[1] license:
Permission is hereby granted, free of charge, to any person obtaining a copy of this software [...] to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software [...]
Or the FSF's definition[2] of Free Software
The freedom to run the program as you wish, for any purpose (freedom 0).
Or the OSI's definition[3] of open source.
5. No Discrimination Against Persons or Groups
6. No Discrimination Against Fields of Endeavor
It's almost as if this concept is at the very core of FOSS.
Yes. Much as there's "MIT free", there's also "AGPL free", and many "MIT free" people consider the AGPL "non-" or less free due to restrictions, while "AGPL free" people consider it more free by demanding its derivatives also be free.
While "use for any purpose" has been included, I think considering purpose is a natural extension of this concept. Suppose there were some software project that aimed to practically eliminate the ability for users to share and use free or open software as it is today. Is it more free to allow such a project to be unrestricted from using other software, even if that project would lead to the destruction of free software otherwise?
That's like saying "I have the freedom to kill you".
Saying that you can create something, then you reserve the 'freedom' to limit what everyone else does for it really doesn't fall under the word freedom at all.
The interpretation is simple and the complete opposite of "I have the freedom to kill you".
The software creator (human or AI) must give the user of its software the same freedoms it has received.
If it has received the freedom to view the original, readable, source code, then users should have the freedom to view the original, readable, source code.
If it has received the freedom to modify the source code, then users should have the freedom to modify the source code.
Etc.
It's not hard to follow for people who want to do the moral thing.
It's VERY hard to follow for people who want to make money (and ideally lots of it, very quickly).
I think this is cause most developers just end up using steam's APIs for these things and since steam will be most of their sales they don't bother.
I have seen games using epic's solution in their steam distribution.
i do wonder how hard it would be to integrate multiple of these APIs so that the end user could invite anyone from any platform, though i imagine you'll still need some sort of middle man / lobby server...
Either way, I'm not a fan of having to generate lobby codes every time I want to play baldurs gate 3 with my friends who have it on steam
The API is pretty straightforward. It's mostly about resolving SteamIDs and talking to the matchmaking server. Last time I used it, once you have all the player and server data, you pretty much just send UPD packets through another Steam API call. Though I think you use SteamIDs instead of IP addresses.
Unless you've gone super deep into the Steam API, it shouldn't be too hard to plug in a different framework.
We need someone to write a compatibility layer for those APIs, so it can be used across various "multiplayer-providers" and distribution platforms. Call it Sroton. Or maybe someone could email Gabe and ask if he could just straight up open source it and let others implement it too.
Yeah, it can quickly lead to analysis paralysis.
I've set up three laptops with a Linux on them for non-tech friends and family members and deliberately went with distros that "just work" (Debian and Fedora specifically).
In general I'd recommend sticking to the simple options and not going into niches unless you/the user actually wants or needs to.
Most sensible Compiler flags aren't enabled by default... I keep a list of arguments for gcc to make things better, but even then you'll also wanna use a static analysis tool like clang-tidy
Sure, I put quickly put them into a small markdown file.
At my job we have a cmake interface target that handles these (along with some version checks and project specific stuff), but I can't publish that of course. I might put these into a cmake file at some point, not sure.
reply