F-droid doesn't simply distribute build apps. It requires the source to be open and will build the apps itself. This does not guarantee there will be no bad actors trying to slip in malicious code. I do believe they also do initial audits before an app is allowed in their repos. It also often takes a while for an app update to show up in F-droid, I am not sure if that is due to auditing updates or something else though.
Cool, but I fail to see how it is relevant in the context of the article? You clearly have the knowledge, expertise and discipline to incorporate LLM in a workflow that, taking your word for it, delivers a very good result.
That makes you a) more unique than you realize b) not all that relevant in the context of the article.
a) Because a lot of people tend to lean towards use that absolutely leads to atrophying of skills and knowledge. b) well the article does explain the criteria it used fairly well and your project would not show up there. Well, also because your project isn't an android app.
An appliance Linux distribution without dependencies is way more complex than a typical android app and there is little prior art to train on.
Android apps on the other hand, LLMs have enough training data to rapidly generate whatever you can think of with much less time required for an experienced engineer to refine it into a quality result.
I am mostly pushing back on the notion of dismissing software as low quality just because the author used LLMs.
It is frankly amazing we can point an LLM at a proprietary ad-ridden app and get to an ad-free open source and privacy respecting clone in a weekend now.
> I am mostly pushing back on the notion of dismissing software as low quality just because the author used LLMs.
Its not that hard to imagine that apps made with heavily LLM involvement suffer in quality. The article already goes into it a bit. I get the strong feeling that you are failing to approach this from anything else than your own perspective and how you use LLMs. Which, given the setup you are describing is already far from the norm.
Zooming out a bit further I think we can generally break up LLM usage in roughly two distinct ways of using LLMs. Or maybe more accurately there are two sides of a spectrum with a lot of area in between them:
1. Let LLMs do the majority of the heavy lifting and generate the output. Providing an LLM with some basic info, what you are looking for and let the LLM do most of the work for you.
2. Using LLMs as a tool external to the process where you are still doing most of the work.
The first way of using LLMs using agentic workflows, code harnesses, etc *can* produce good quality. As long as there is still a human in the mix who a) has the prerequisite knowledge to validate what the LLMs have generated b) takes their due diligence at key points in the process to actually make sure input is of high enough quality and validates the output.
You have decades of knowledge and experience you are now applying to rigidly structure how these LLMs work.
Which, yes again, I believe gives you personally pretty good results, no doubt about that. But, many people do not have that experience to begin with.
And even for those that do, using the first method comes with a risk that boils down to simple psychology, our minds are wired to take the easy approach wherever they can. Which turns the first way of using LLMS from a efficient way of using them to a lazy way of using them.
In my personal experience a lot of people who start using LLMs sort of drift to the lazy approach very easily. Because it is very convenient and easy to slowly hand over more thinking to an LLM. The latter I have seen happen all too often around me. An alarming increase of lazy non critical use of LLM tools by people who should know better. People who might have been a bit slower before but delivered excellent results now have started delivering trash. Code spanning dozens of line trying to solve something that should only take one line. Code that completely ignores and conventions or design paradigms put in place. Code that goes directly against security practices. Suddenly downgraded dependency versions (because the models training data doesn't include the latest version).
As I said, I see this as a spectrum and the more someone leans towards the first use case combined with "lazy usage" the more signs there will be in a repository that this is the case. The amount of commits, the release cadence and various other things. Which, again, the article also makes a case for and is again why your repository is irrelevant to the whole discussion. Why? Because your repository doesn't show these signs.
Fair and nuanced. Nothing I disagree with here. I think I mostly just dislike the default hate and assumptions on everyone that uses LLMs, including often me. Some of us are using these tools thoughtfully.
LLMs help experienced engineers write quality code faster and it helps amateurs write shit code faster. Problem is there are simply way more of the latter. Even so I detest engineering being judged by the tools used, instead of the work itself being judged on its own merits because there are exceptions to every rule. I would like to teach people to use these tools responsibly, instead of sending a message that use of these tools is automatically thoughtless slop.
Like, most people I know that use Vim write much higher quality code on average than the people that use VSCode as tool preferences often reflect experience, but not always! It would still be unfair to write off someone's code sight unseen because they used VSCode as there are always exceptions to the rule.
> Do you suppose it's just that it's aping humans who say too much without saying anything
Considering how much of the input must me nonsense SEO bullshit articles and blogs that only serve to promote a person or company that might be a factor.
I also often have wondered if it is also targeting those same people. Certainly with tools like deep research options (not just Anthropic's offering) the result report seems to be aimed at management, aiming to look impressive while talking around the results.
> How does being docker compose based make it inaccessible?
Because it requires people to also have knowledge about the ins and outs of docker and docker compose. If we are talking about web applications it is yet another layer that has been added over the years. It used to be that you could fairly easily host most things on a old fashioned lamp host (I am talking decades ago) and all you had to know was basic file transferring.
Of course, this was on shared webhosts in a time when VPSes were not really a thing yet or affordable. But, even on a VPS setting up a LAMP stack is relatively straightforward.
Once you add modern dockerized application to that mix you are now still looking at some sort of ingress to do the reverse proxy bit. So while it likely will not be Apache or nginx there will be some sort of layer there in addition to now having to setup docker properly (rootless and all that) and then also making sure your docker compose setup is in order.
It is not difficult *once you know how to* but it is another layer of knowledge and experience people need to acquire. That does make it less accessible for novices.
> you could fairly easily host most things on a old fashioned lamp host (I am talking decades ago) and all you had to know was basic file transferring
Setting up and maintaining a server is easier today than it was decades ago, A LAMP at this time meant a lot of manual setup, IaC wasn't a thing, reproducibility wasn't a goal, versioning was confidential, documentation was scarce and often outdated, out of the box security was lower, ties to the OS were higher. Managing virtual hosts was clunky, updating OS/PHP was risky. I would not go back for anything.
> having to setup docker properly (rootless and all that)
Rootless being the proper way to setup Docker is a highly controversial take. You will mostly get added complexity and a false sentiment of security from it.
> A LAMP at this time meant a lot of manual setup, IaC wasn't a thing,
I'm sorry but this is just nonsense. LAMP is called that because it was a very standardized thing. Pop in a Debian CD and select a ready made profile for it. There were even ready made installers for Windows and Mac if you weren't on an Internet native operating system.
A lot more people got by using custom bash scripts, but cfengine exited in the 90s. It's still not honest to say things were more manual. Take a look at /r/homelab or somewhere selfhosters hang out today and look at the Compose or self hosted K8s stacks people set up today. That's orders of magnitude more manual work than just popping in a CD and selecting LAMP.
Yes, those are not the same thing. Yes, a self hosted stack today consists of so much more than running PHP in a web server. But for self hosters, the amount of work required has objectively gone through the roof. That's a problem if your goal is data sovereignty.
> op in a Debian CD and select a ready made profile for it.
At the time in question here tasksel wasn't a thing, I think merely a concept. It made its way in Debian installer around 20005 IIRC, right along "one-click installs" from hosting services mentioned in the other reply. The whole decade before that, indeed manual set up was needed.
> at /r/homelab or somewhere selfhosters hang out today [...] That's orders of magnitude more manual work
There is two kinds of self-hosters, those who aim at reproducibility and those who don't. The latter is more fun, the former gets quickly mandatory when you _rely_ on your homelab.
> Setting up and maintaining a server is easier today than it was decades ago, A LAMP at this time meant a lot of manual setup, IaC wasn't a thing, reproducibility wasn't a goal, versioning was confidential, documentation was scarce and often outdated, out of the box security was lower, ties to the OS were higher. Managing virtual hosts was clunky, updating OS/PHP was risky. I would not go back for anything.
You are speeding past my point by a mile or two. With a shared webhost you get a ready lamp stack. In the late 90s early 2000s you could fairly easily get a wide array of software running that way. All you had to do is create a database in the hosters control panel, upload the package and you'd be on your way. Later in the 2000s one click installers came along for popular packages making it even easier. In fact, they are still around these days making it extremely easy to install a wide array of lamp based applications to these days.
There are very few options these days to get started as easily these days with modern non lamp tech stacks. The only thing I am familiar with (other than the product presented to us in this post) is pikapods, [which only offers a limited selection of available applications](https://www.pikapods.com/apps). There are a few others, also catalog based, though they more seem to focus on deploying on other platforms for you. Other than that you start to quickly move to more complex hosting solutions aimed at business and scaling. Or platforms that are cloud platforms with all the added complexity to navigate and figure out before you can deploy docker containers. Not to mention ridiculous situation that a few of the ones I know about have pivoted to being "agentic compute providers" whatever that means and certainly will confuse a novice.
Which means that the "practical" advice given is often to "just" set up a VPS. And yes, many VPS providers will provide an image with docker enabled, but that is just the start.
> Rootless being the proper way to setup Docker is a highly controversial take. You will mostly get added complexity and a false sentiment of security from it.
That, in fact, is another layer of complexity people will then have to figure out. Most information I am aware of these days does claim that it is better to run containers rootless or at the very least make sure the user in the container is non root. The fact that we are both convinced of the opposite tells you how confusing it must be for a novice.
The overall point I am trying to make isn't even about the exact details. It is that for hosting something these days there is much more required surrounding knowledge required before you can get started in most cases.
Docker doesn’t do that on my Fedora machine, nor on my arch machine. Did I set some setting somewhere that I forgot about? I’m also running rootless docker and podman so that might explain.
> a STEM field if they care enough and aren't the sort who are just doing the bare minimum to get the sheepskin.
That's the thing though, part of it is about caring. Part of it is being exposed to other things in order to realize there is more out there. I honestly think that STEM field education would benefit from including Liberal Art related courses exactly because of that. Basically as a way to broaden students world view and the way they might interact in it.
The same is probably true the other way around as well btw.
> CI run pulls from npm, PyPI, Docker Hub, a distro mirror and a handful of third-party, none under your control, none with an SLA to you.
To be honest, they shouldn't do so directly. For the obvious reason you stated, they don't have a SLA to you or your company. But also because it is a shitty thing to do as a company. Companies should have their own proxies and mirrors for any repository they pull from. Both to be in control of the dependencies you as a company rely on and to not unnecessarily put load on free third party repositories.
Had not heard of your solution. More often than not I come across Harbor, Nexus or things like GCPs internal stuff.
Maybe I'm out of touch, but I think control over dependencies is underrated. It's not just about freezing and pinning. There should be better tooling to support the whole dependency evolution pipeline. For example updates should be reviewed/ingested/integrated/validated based on local policy not based on source release schedule.
This is why some projects will vendor their dependencies - changes within the dependency itself will also be reviewed, and it's easier to locally maintain patches to those dependencies until the patches can be upstreamed.
The problem is, there's a difference between doing that for a handful of C or Go libraries, versus trying to vendor thousands of NPM libraries and all of their interdependencies. So it's very ecosystem dependent.
Agreed. Your self-managed vendoring example is quite near one end of the continuum. I'm suggesting that there might be space for better tooling from there all the way to the NPM end. For example, automated and/or collaborative triage and review of change sets so that you don't see the changes you don't care about, but can easily review and integrate critical fixes.
Different country probably, here QA is still often part of the team. More often than not as part of a team with a title like "test automation engineer".
Just going to recycle this comment I made in reply to an almost identical comment as yours. I don't think you folks realize how big space actually is.
The speed of light is 1079 252 848 km/h, the fastest space craft ever made was the Parker Solar probe (using a sling shot) clocking in at 692 000 km/h. So at that speed it would take, 1559 years to travel one light year.
This planet sits at a distance of 48 light years, so it would 74 832 years to get there. Just for good measure, when it gets there it would also take 48 years for us to know that since radio travels at the speed of light.
Note, that the speed of the spacecraft I mentioned was the peak speed. Space is big, really big.
Science fiction has entertained and inspired millions of people and we should all be grateful for that but it has also distorted what people think space really is.
When you consider the scale of space it becomes pretty understandable why the Milky Way isn't teeming with civilizations sending large amounts of mass all over the galaxy. A realization one comes to despite the facts that it has taken humans a blink of an eye (on a galactic timescale) to go from tools to rockets and the Milky way is billions of years older than the entire history of the Earth.
On a scale of probable -> less probable, you have:
Self-organizing chemicals -> replication -> evolution -> multi-cellular life -> creatures that move around -> intelligent life -> use of tools -> basic technology like wheels, steam engine -> industrialization -> advanced tech -> automation -> space faring -> capable of interstellar travel -> capable of intergalactic travel. Powered by energy sources of increasing complexity/sophistication & scale.
This whole evolution requires a stable environment. Dinosaur-killing asteroid & it's back to square 1. Also (for example) how would intelligent life on a waterworld (which basically excludes electronics as we know it) become space-faring?
So it's not unlogical to expect that microbial life could be 'everywhere', tool-using intelligent creatures are rare, and interstellar-capable civilizations are so few & far between that (on average) they're just too distant in space or time.
Doesn't matter who visits who if neither party can cross the ocean in between.
I blame Star Wars, kinda. Watching it with my kid, I can't help but notice that everywhere they travel in space -- even by accident -- they end up by a planet that can support human life in terms of temperature, atmosphere, and gravity. Mandalore (the Mandalorian home planet, natch) has a moon that doesn't only support life; it also has the exact same gravity as Mandalore!
Sentient life in hospitable environments is as unavoidable in the Star Wars universe as it is absent in ours.
Project Hail Mary does a pretty good job, although probably doesn't come across in the film. SF that doesn't even bother using wormholes or some other FTL travel (e.g. warp speed) is quite annoying, though.
I mean, even there they pretty use the Astrophage as a plot device to fill in the huge gap in technology needed to cover those distances. They make it clear that they would have no chance to cover those distances without the Astrophage, but it is very convenient.
If I understand correctly, time spent within this interstellar ship reference frame would be significantly less than 75k years. And at 1c speed, 48 years on Earth would be ~2 years of "flight" for the passengers, correct me if I'm wrong.
You are not wrong, but it still wouldn't make a whole lot of difference. First of all with any technology we currently have, including hypothetical proposals, we can't even get close to 1c. The best we can do, and this assumes purely hypothetical unproven ideas, is accelerate to a fraction of the speed of light. Acceleration itself will take up a significant amount of time and even then we are nowhere near the speed of light. Project Orion would in theory be able to do 3% to 10% of the speed of light. That's about the only proposed propulsion we actually have the technology for in the sense that we might be able to build it this decade.
So let's be optimistic and assume we can reach 10% of c (unlikely), that is 10 years for one light year, meaning that it takes about five centuries. Practically speaking 10% of c is unlikely, it takes about a month to accelerate to those speeds you'd need an insane amount of mass in the form of bombs to explode to just get up to speed. Which is why 3% is more "realistic". Oh, did I mention that there is no realistic way to slow down either? In theory it is just detonating the same amount of bombs in front of the craft, but in order to take that mass on your journey you'd need a lot more mass to get up to speed and the numbers get silly rather quickly.
So "realistically" at 3% of c we are talking about roughly 1500 years to just speed past our target.
Also, the original remark was about sending probes, not humans. But at 3% or 10% of c time dilation isn't much of a factor either so you'd need a generational craft if you want to send people.
Man, that’s not how intelligence works. Eventually if a civilization doesn’t blow itself up, it will achieve anything, and it’s not incremental steps. Speed has never been incremental steps. in 1810 you would’ve been thinking about faster horses or some shit like that. Def not rockets. OP said hundreds of years. In hundreds of years from now our rulers will definitely have that kind of tech, whatever tech it is.
Often technology is approaching an asymptotic limit that it will not go beyond. Know about a hand waving will change the laws of physics. There's every reason to believe that the speed of light is a maximum that we will never be able to choose because it requires infinite energy. While it is true we don't know everything, and there are certainly parts of it we don't know, the things we do know will have to obey and predict the things that we currently do know to be true. The laws of relativity, although annoying, are very good at describing things. If anything replaces relativity, it's going to replace it while still predicting exactly the same things that relatively does that we have verified. That doesn't leave much room for a theory that might and faster travel.
If we’re talking about human technology available in a few hundred years, don’t discount far more exotic options. I’ve heard people talk of theoretical terrestrial lasers pushing on tiny probes. With an absolutely gigantic laser and magical material at the back of the probe that won’t instantly vaporize there’s enough energy to get something the size of a smartphone up to a reasonable proportion of the speed of light.
I can’t prescribe this theoretical technology to the problem. But I also think it’s unreasonable to set the limit using known technology and then discount the idea altogether. We have no idea what will be possible in 300 years.
Note that you can't use these lasers to slow down the probe, which will dramatically limit the things the probe can do at the destination. I'm not even sure what kind of interesting things a probe the size of a smartphone could do, let alone phone home.
> you can't use these lasers to slow down the probe
You can, but you need a couple of solar sails. You beam the laser at the sails to accelerate, then at the halfway point one of the sails detaches and becomes a reflector, which lights up the now flipped probe and remaining sail to decelerate them.
send an unending chain of them and you solve the transmission problem _and_ they don't have to slow down as you'll always have another on the way past whatever you're targeting
How many times the Earth's materials would we consume doing that? And wouldn't it block ma lazor from reaching the previous probes and accelerating them?
Exactly. Imagine what would be possible after a billion year of technological evolution, heck even just 100'000 years. We already know that space time metric engineering is theoretically possible within our current understanding of physics, we don't have either the technology or access to energy density necessary to do it. And that's only within our limited understanding of how the universe works.
If you have a billion year long civilization, it would probably be easier to genetically/medically engineer humans to live forever, so that a 75,000 year space voyage doesn’t seem so long. Easier than near-lightspeed space travel at any rate.
The general idea is to deliberately shape the geometry of spacetime to allow for effects such as faster-than-light travel (relative to another region of spacetime).
Einstein's field equations link geometry to matter and energy:
G_μν = 8πG/c⁴ · T_μν
Left side describes how spacetime curves (the metric tensor). Right side represents what's causing the curvature (the stress-energy tensor): mass, energy, momentum. The usual approach is: you specify T_μν (what matter is where) and solve for the resulting curvature. Metric engineering takes the backward approach. You pick the geometry you want first: e.g a bubble that carries its contents faster than light relative to the outside universe. Then you work out what T_μν would have to be to produce that geometry: what distribution of energy and stress the equations demand.
The classic example of spacetime metric engineering is the Alcubierre drive.
The limitation with this is that the required T_μν has negative energy density in some regions (the bubble walls) which violate some assumptions about how "reasonable" matter behaves. But Quantum Field theory allows such local regions of negative densities and we have created such regions in labs experimentally already (Casimir effect). We "just" don't know how to sustain the effect at bigger (atomic) distances.
At the distances involved even the beam from a gigantic laser will be spread out enough not to vaporise anything — you won't need a magic material, just a very large, thin, and highly reflective solar sail.
The comment you replied to doesn't appear to be misunderstanding the size of the galaxy, they mention acceleration to near the speed of light so they're probably thinking 100 years to get there and another 48 to receive signals back. The missing part is the propulsion system capable of doing that.
> the fastest space craft ever made was the Parker Solar probe (using a sling shot) clocking in at 692 000 km/h…
After 44 days of acceleration. On a multi-millennia mission we’re talking a velocity likely 300x what the Parker Solar Probe achieved (while falling into the Sun).
> I want to know what future technologies could accelerate an object to a significant fraction of the speed of light.
With all due respect, this has been extensively debated online and is extremely easy to look up.
> Could those breakthroughs be achieved in the next 2 or 3 centuries?
Any predictions on future scientific breakthroughs are wishful thinking. Even directions that seem promising at some point can end up being dead ends and we simply don't know what we will or will not achieve.
With current technologies, even hypothetical ones we can't get there in a time period that is under a few centuries at best and over a millennium at worse. Even for the centuries figure we'd require technologies we haven't been able to crack yet.
I was being a little optimistic with theoretical designs that could happen within our lifetimes (nuclear pulse at 10% c gets ~500), but yes absolutely true that with current tech it's tens of thousands even with the rosiest of estimates
add in a bunch of complication for "oh wait, you need to stop too"
More here:
- https://f-droid.org/en/docs/Inclusion_Policy/
- https://f-droid.org/en/docs/Security_Model/
reply