I have come to a similar realization recently - its what I call "Take it home OSS" - i.e. fork freely, modify it to your liking using AI coding agents, and stop waiting for upstream permissions. We seem to be gravitating towards a future where there is not much need to submit PRs or issues, except for critical bugs or security fixes. It's as if OSS is raw material, and your fork is your product.
Recently I've been air-dropped into such a legacy project at work in order to save a cybersecurity-focused release date. Millions of lines of open-source code checked in a decade ago prior to the Subversion-to-Git migration, then patched everywhere to the point where diffs for the CVEs don't apply and we're not even sure what upstream versions best describe the forks.
By the end, the project manager begged me to turn off my flamethrower, as I was ripping it all out for a clean west manifest to tagged versions and stacks of patches. "Take it home OSS" is like take-out food: if you don't do your chores and leave it out for months or years on the kitchen counter, the next person to enter the apartment is going to puke.
But our modern embedded firmware projects all use Zephyr and west, so I just created a west manifest, stole parts of the scripts/ folder from the Zephyr repository to have a working "west patch" command and went to town. If I had more time to work on it, I'd have gotten "west build", "west flash" and "west debug" working too (probably with bespoke implementations) and removed the cargo cult shell scripts.
You can use west without Zephyr, it's just that by itself it only provides "west init" and "west update".
I have mixed feelings about west in general, but I like it enough that I'd probably look at doing something like that in the future too for harmony-sake with our existing Zephyr projects.
This is very shortsighted and it’s like polishing gun to shoot your foot with it.
If it’s "take it home OSS" and "there is not much need to submit PRs or issues" then why would anybody submit PRs and issues for "for critical bugs or security fixes"? If they have fix and it works for them, they’re fine, afterall.
And while we’re at it, why would anybody share anything? It’s just too much hassle. People will either complain or don’t bother at all.
I think that after few years, when LLM coding would be an old boring thing everybody’s used to and people will learn few hard lessons because of not sharing, we’ll come to some new form of software collaboration because it’s more effective than thinking me and LLM are better than me and LLM and thousands or millions people and LLMs.
Before LLMs, it was cheaper in the long run; by upstreaming your patches you don't have to rebase them continually and sometimes the community will maintain the code for you. OTOH sometimes you might need to work on the code again though as other parts of the project evolve if the project is likely to throw out unmaintained code; this is especially true in the Linux kernel where internal APIs change constantly, but upstream maintenance is probably cheaper than continually backporting security fixes to your stable/LTS/SLTS or completely dead versions.
With LLMs the costs might be different but will still exist.
Another self-serving reason is so that you can upgrade in the future without having to worry about continually pulling your own private patch set forward.
I think people do that because they are closely involved with the code/plumbing. If they spend a week fixing a bug, they feel the weight of the changes that they made with every line that they wrote. If they just fixed the issue in passing and moved on to the next thing, I don't know if they would feel the same weight to contribute back.
More often than not, LLMs fixes an issue as a downstream user. So there's even less pressure to fix the issue. Because if library A does not work on Windows, it would just use mash together library B and C and something from itself to fix the work around it.
Sure there will, as long as people continue to publish their work including the various forks. The community dynamic will change as will the workflows surrounding dependencies but the core principle will remain.
Vulnerability detection might prove to be an issue though. If we suddenly have a proliferation of large quantities of duplicate code in disparate projects detection and coordinated disclosure become much more difficult.
This has always been the case, and is really the main practical advantage of open source. Contributing code back is an act of community service which people do not always have time for. The main issue is that over time, other people will contribute back their own acts of community service, which may be bug fixes or features that you want to take advantage of. As upstream and your own fork diverge, it will take more and more work to update your patches. So if you intend to follow upstream, it benefits you to send your patches back.
I am a bit late to this thread, nevertheless, I wanted to put my thoughts down as well.
Horizon Worlds and the Metaverse were both pitched as a "social" platform. And this in itself is where I believe they went wrong. It fundamentally differs from my limited experience with VR and its potential. I see VR as an "anti-social" platform rather than a "social" one - and I say this in a good way.
When I put on a VR headset, its as if I am shunning my current world. The experiences I find valuable in VR are the ones that elevate that feeling - imagine watching a basketball game courtside, or watching NASCAR while floating right above the track, or watching a live concert happening halfway across the world, or VR tourism (visiting different places anytime you want, from some breathtaking angles - my most memorable experience of this was a video on Angel Falls https://www.youtube.com/watch?v=L_tqK4eqelA), or even the classics like playing VR games and watching movies. I believe that they should have doubled down on providing a much richer "anti-social" experience.
You should give VRChat a try, the predecessor and more successful version of Horizon Worlds. Everything you described can arguably be done in VRChat WHILE not destroying the social aspect of it! It's really neato and VR is not even required, much less mandatory (but highly encouraged).
On my paid account, I was able to verify this. I was also able to get a CPU-bound workload running on all cores. Interestingly, it was not able to fully saturate them, though - despite trying for 20-odd minutes. I asked it to test with stress-ng, but it looks like it had no outbound connectivity to install the tool: https://chatgpt.com/share/69a5c698-28bc-8005-96b6-9c089b0cc5...
Anyways, that's a lot of compute. Not quite sure why its necessary for a plus account. Would love to get some thoughts on this?
Happy Public Domain Day, everyone! Such a great project.
A bit tangential here, but I am really looking forward to 2035 for the public domain. A ton of culturally significant works seem to enter then - And Then There Were None, Gone with the Wind, The Wizard of Oz, Mr. Smith Goes to Washington, Batman (Detective Comics #27), Superman #1, Marvel Comics #1, and Tintin’s King Ottokar’s Sceptre.
Hi! Author here. I agree that I should have explicitly stated the word "priority queues" since it is an ADT people can directly relate to. I will add it in. However, it is simply not true that I did not describe how a priority queue-based solution works.
I have described it in the "Timer Modules" section:
> A natural iteration of this approach is to store timers in an ordered list (also known as timer queues). In this scheme, instead of storing the time interval, an absolute timestamp is stored. The timer identifier and its corresponding timestamp that expires the earliest is stored at the head of the queue. Similarly, the second earliest timer is stored after the earliest, and so on, in ascending order. After every unit, only the head of the queue is compared with the current timestamp. If the timer has expired, we dequeue the list and compare the next element. We repeat this until all the expired timers have been dequeued, and we run their expiry processing routines.
And then, I go on to talk about its runtime.
Truth be told, this is a chapter for my book on data structures and algorithms that I think are interesting and obscure enough that not many people talk about them. Its goal is not widespread practicality, but rather a fun deep dive into some topics.
When my friends and I were undergrads (3rd year, I believe), we had an absolute blast exploring this exact topic - the intersection of Bloom Filters and client side searching. So much so that it became part of our undergrad thesis.
It all started when Stavros's blog was circulated on Hacker News! The way we approached the search part was by using "Spectral Bloom Filters" - https://theory.stanford.edu/~matias/papers/sbf-sigmod-03.pdf - which is based on a paper by Saar Cohen and Yossi Matias from the early 2000s - its basically an iteration on the counting bloom filters. We used the minimal selection and minimal increase algorithm from the paper for insertion and ranking of results.
I love what Norvig said. I can relate to it. As far as data structures are concerned, I think it's worth playing smart with your tests - focus on the "invariants" and ensure their integrity.
A classic example of invariant I can think of is the min-heap - node N is less than or equal to the value of its children - the heap property.
Five years from now, you might forget the operations and the nuanced design principles, but the invariants might stay well in your memory.
> The Perseverance rover has explored and sampled igneous and sedimentary rocks within Jezero Crater to characterize early Martian geological processes and habitability and search for potential biosignatures ..... the organic-carbon-bearing mudstones in the Bright Angel formation contain submillimetre-scale nodules and millimetre-scale reaction fronts enriched in ferrous iron phosphate and sulfide minerals, likely vivianite and greigite, respectively.
> Organic matter was detected in the Bright Angel area mudstone targets Cheyava Falls, Walhalla Glades and Apollo Temple by the SHERLOC instrument ..... A striking feature observed in the Cheyava Falls target (and the corresponding Sapphire Canyon core sample), is distinct spots (informally referred to as ‘leopard spots’ by the Mars 2020 Science Team) that have circular to crenulated dark-toned rims and lighter-toned cores
> PIXL XRF analyses of reaction front rims reveal they are enriched in Fe, P and Zn relative to the mudstone they occur in ..... In the reaction front cores, a phase enriched in S-, Fe-, Ni- and Zn was detected
> Given the potential challenges to the null hypothesis, we consider here an alternative biological pathway for the formation of authigenic nodules and reaction fronts. On Earth, vivianite nodules are known to form in fresh water ..... and marine ..... settings as a by-product of low-temperature microbially mediated Fe-reduction reactions.
> In summary, our analysis leads us to conclude that the Bright Angel formation contains textures, chemical and mineral characteristics, and organic signatures that warrant consideration as ‘potential biosignatures’ that is, “a feature that is consistent with biological processes and that, when encountered, challenges the researcher to attribute it either to inanimate or to biological processes, compelling them to gather more data before reaching a conclusion as to the presence or absence of life .....
> The Planetary Instrument for X-ray Lithochemistry (PIXL) is an X-ray fluorescence (XRF) spectrometer mounted on the arm of the National Aeronautics and Space Administration’s (NASA) Mars 2020 Perseverance rover (Allwood et al., 2020; Allwood et al., 2021). PIXL delivers a sub-millimeter focused, raster scannable X-ray beam, capable of determining the fine-scale distribution of elements in martian rock and regolith targets. PIXL was conceived following the work by Allwood et al. (2009) that demonstrated how micro-XRF elemental mapping could reveal the fine-textured chemistry of layered rock structures of ~3,450-million-year-old Archean stromatolitic fossils. Their work not only pushed back the accepted earliest possible window for the beginning of life on Earth, but also demonstrated that significant science return might be possible through XRF mapping. PIXL was proposed, selected, and developed to carry out petrologic exploration that provide the paleoenvironmental context required in the search for biosignatures on Mars, analogous to Allwood et al.’s earlier work.
I like your analysis, but, personally, I am struggling with "Absence of data/other possibilities is pointing us to conclusion"
It should (IMO) be reported as, we just don't know (yet), there's some really fascinating things that we cannot explain in any other way, yet, but that doesn't actually mean that we know for sure.
What's not to understand - it's precisely the argument theists have put forward for millenia
"We couldn't find anything to show it wasn't a god, so it must be a god"
Calling one group "smart" doesn't change the process or the outcome - the absence of data is not data, it's just that we couldn't yet find the full explanation.
One day we might, it might actually be life, but we don't have that right now, so, actual science demands that we withhold any wild speculation.
No, because theism is missing the first premise. The equivalent would be:
- We have observably seen and reproduced god bringing someone back from the dead
- We can find no other explanation for this thing coming back from the dead
- It was likely god who brought this thing back from the dead, but we want more data
The first premise has never happened, there is not any equivalence...
Actually (It's too late to edit) we do have this curious thing
Aliens - we claim/recognise that statistically the size of the (at least observable, if not entire) universe and number of habitable planets with all the right ingredients for life that there must be life out there... somewhere
But we don't have an ounce of evidence (neither for nor against)
God(s) - we don't have any evidence one way or the other, atheists just say "It's impossible", theists say "It's the only answer", but, as already mentioned, there isn't any actual evidence that can lead us to a conclusion. (This will be misread as an argument for god(s), but it isn't. And even if it were, there's still a massive step between that and the Abrahamic God being the dude)
Which takes me right back to where this started. The supposition that the features of mars are signatures of life, we don't know at this point, all we actually know is... we haven't found anything else that we can say they are.
reply